How Much Is a Support Ticket Actually Costing You?
A simple model for costing support tickets, estimating deflection from documentation, and working out what a help centre has to absorb to pay for itself.
Most teams have never costed a support ticket, and the ones that have usually did it by dividing the support team's salaries by the ticket count. That number is always too low, because it counts only the people whose job title says support. The engineer pulled in to check a log, the founder who answered at the weekend, the twenty minutes of context-switching either side - none of that appears, and on a small team it is most of the actual cost.
Here is a model that is still simple but stops flattering you.
The arithmetic
Four inputs. Use your own figures; the illustrative ones below are just to show the shape.
| Input | Illustrative |
|---|---|
| Fully loaded cost per hour of whoever answers first | £45 |
| Median handling time, including context switching | 18 minutes |
| Proportion needing escalation to engineering | 15% |
| Engineer time per escalation | 40 minutes |
| Fully loaded cost per hour of that engineer | £70 |
Direct cost per ticket is (18/60) x £45 = £13.50. Escalations add 0.15 x (40/60) x £70 = £7. So roughly £20 per ticket before anyone has thought about opportunity cost - and that is the generous reading, because it excludes the customer's time entirely.
At 200 tickets a month that is £4,000, which is the part everyone computes. The part that matters more is the marginal question: what does ticket number 201 cost, and what does it displace?
The number that actually decides things
Two hundred tickets a month at eighteen minutes is sixty hours - a third of a person, permanently. On a team of six, that third of a person is not a support hire. It is a feature that does not get built.
That is the real currency and it is why "just hire someone" is usually the wrong first move. Support headcount converts the problem from an interruption into a cost line, which is genuinely better, but it does nothing about the underlying volume. The volume is a product of how many people use you multiplied by how often they cannot work something out, and only the second term is addressable.
What documentation realistically deflects
This is where most vendor maths becomes fiction, so let me be careful.
Deflection is not measurable directly. You cannot observe the ticket that was not filed. What you can measure is displacement: whether tickets matching a topic fall after an article covering that topic goes live, relative to overall volume. That is a proxy, it is confounded by seasonality and growth, and it is the best available.
What the shape of ticket volume tells you is more useful than any headline rate. Support queues are heavily concentrated - a small number of question types generate most of the volume, and those types are exactly the ones documentation handles well, because they are repetitive, factual and predictable. The long tail of genuinely novel questions is not deflectable and never will be, and no amount of documentation touches it.
So the honest framing is not "documentation reduces tickets by X%". It is: identify your top five recurring question types, cover them properly, and expect meaningful movement in those five specifically. If those five are half your queue, the arithmetic is straightforward. If your queue is genuinely long-tail, documentation is the wrong lever and you have a product problem.
The model flatters itself in three places
The model above quietly assumes tickets are bad. Some are not. A question from a prospect mid-evaluation is a sales conversation wearing a support costume, and deflecting it into a help article can be worse than answering it - you have saved twenty pounds and removed a chance to build the relationship.
Second, cost per ticket falls as volume rises. Macros, better tooling and practice all help, so a company at 2,000 tickets a month has a much lower per-ticket cost than one at 200. Applying a small company's per-ticket figure to a large company's volume overstates the saving considerably.
Third, and most importantly: the argument I actually believe is not the cost one. It is that people who cannot find an answer mostly do not file a ticket - they leave. The deflection maths is the visible part of a larger effect that is much harder to measure and much more expensive.
Do this bit
Take last month's tickets, tag the top five recurring types, and count what share of volume they represent.
If it is over half, you have a documentation problem with a known price. If it is under a quarter, spend the money somewhere else.
About the Author
Simon Moxon has been building SaaS companies since 2009. He's scaled teams to 20+ people, hit £2m ARR, and learned most of the lessons the hard way. Now he's building SupportPages.io - help docs that write themselves when you ship code. He writes about what's changed in SaaS and what hasn't.