We've now seen the same post-launch scramble on enough projects to write it down: the product launches, adoption goes well, and six weeks later the client is trying to hire and train support staff under pressure because nobody put a number on expected ticket volume before launch.
Why this gets missed
Discovery conversations focus on what the product does. Support load depends on what the product does badly, or unclearly, or differently from what a user expects, and none of that is knowable with certainty before real users touch it. So it gets left out, understandably, and then arrives as a surprise that was actually predictable in shape if not in exact number.
What we now estimate, even roughly
- The three most likely confusion points, drawn from the parts of the product that are genuinely new to the user rather than a copy of something familiar.
- A rough ticket-per-active-user ratio from a comparable product, even a crude one, just to give the client a number to plan headcount against.
- Which issues need a person and which can be self-service, decided before launch rather than triaged live, because building a self-service answer after the tickets start arriving is always slower than planning for it.
A concrete case
On a marketplace launch, we flagged the returns flow as a likely support hotspot before launch because it touched money and had the most steps of any flow in the product. It was, in fact, the single largest category of ticket in month one, and the client had already budgeted a person's time for it rather than discovering the gap live.
Support load is a product decision made in advance or a staffing crisis made in arrears. It's rarely anything in between.
What this costs to do properly
An afternoon, roughly, spent walking the product looking specifically for points of likely confusion, plus a short conversation with the client about who handles what. It is a small addition to a scoping document and it has saved every client we've done it for a genuinely bad first month.
The number that matters most
Not total ticket volume, but ticket volume in the first two weeks, which is when a team is least prepared and a bad experience does the most damage to word of mouth.