Case Study
The Goal Wasn’t to Run Events. It Was to Build the Function.
How I turned roughly 40 annual events from undocumented activity into a measurable, repeatable operating function that could run without my day-to-day oversight.
The situation
When I took over Events, there was zero documentation and no real handoff.
Events were happening, but reporting and attribution were inconsistent. We could execute an event without having a reliable way to answer whether it was worth it.
We could not consistently see where events were working, where we were losing money, or what the result should change next time. Without that history, projections and budget decisions were built on a weak foundation.
The real problem
The obvious problem was how to run events better. That was not the whole problem.
Events were being treated as separate activities instead of one operating function. The investment decision, the plan, the people doing the work, the leads, the follow-up, the financial result, and the next budget decision did not live in one continuous system.
Running the next event was not the hard part. The hard part was building the operating layer that connected all of those decisions without pretending one person did all of the work.
The operating model
I built and ran the operating system through which the cross-functional work happened across roughly 40 annual events.
Each event started with a consistent evaluation: Should we invest? What would have to be true for it to be worth doing? From there, the work moved into a repeatable kickoff and planning cadence with explicit ownership, shared timelines, reusable templates, and a clear place for budgets, goals, assets, and decisions.
Lead capture, attribution, and follow-up were designed into the lifecycle. So were budget-versus-actual reporting, pipeline and deal measurement, revenue and payback visibility, post-event feedback, and 30-, 60-, and 90-day reviews.
The broader team still did the substantial work: marketing, logistics, creative, sales conversations and follow-up, finance reconciliation, business inputs, and post-event feedback. My role was to design, operate, and keep improving the system that connected it.
The learning loop
Measurement was not the end of the process. It became the beginning of the next decision.
The forecasting model originally leaned more heavily on projected opportunities. As real performance evidence accumulated, it moved toward a wins-based model informed by historical deal patterns and customer-value considerations. The model changed as the evidence got better.
The operating model existed before the tooling. As it matured, more of it moved into reusable documentation, reporting, automation, monitoring, and an internal operating layer. Software encoded parts of the model only after the work and decisions were understood well enough to deserve it.
- 01Evaluate — Should we invest in this event?
- 02Plan — What needs to happen, when, and who owns it?
- 03Execute — Run the work through a standard cross-functional cadence
- 04Capture — Connect leads and activity to the event
- 05Follow up — Route the downstream work
- 06Measure — Compare forecast, spend, pipeline, deals, revenue, return, and payback
- 07Learn — Use feedback and later performance to understand what happened
- 08Decide again — Use the evidence to inform the next forecast and budget decision
The transfer
The strongest result showed up after I left the function.
Two junior employees were able to run it with little to no oversight. The documentation, operating model, and systems were mature enough that the person who built them no longer had to remain the day-to-day operating layer.
A function is not mature because one capable person can keep it moving. It is mature when the work, decisions, definitions, measurement, and learning can survive without that person carrying all of it.