Build a cost per resolution model by summing fully loaded salaries, tooling, AI spend, quality assurance, and management time, then dividing by issues genuinely resolved rather than tickets closed. Segment by topic before drawing conclusions, because averages hide where the money goes.
Key takeaways
- Employer costs typically add twenty to thirty percent to salary.
- Divide by resolved issues, not closed tickets, or repeat contacts flatter the result.
- Segment by topic before acting. The average describes no real workload.
- This is the only number that compares hiring and automation on the same basis.
Support finance conversations usually happen without a defensible number. Here is a model you can build in an hour from data you already have, and defend in a budget meeting.
Everything below uses illustrative figures. Substitute your own.
The formula
Cost per resolution = total fully loaded support cost ÷ issues genuinely resolved
Both terms need care.
Building the numerator
Salaries with employer costs. Take base salary and add employer contributions, which typically run twenty to thirty percent depending on jurisdiction. Four agents at 45,000 becomes 225,000 fully loaded at twenty-five percent, or 18,750 monthly.
Management time. The proportion genuinely spent on support. A manager at 80,000 spending forty percent of their time is 2,667 monthly before employer costs, roughly 3,333 with them.
Engineering escalation time. This is the line most teams omit and it is frequently the third largest. If an engineer at 110,000 fully loaded spends a day a week on support escalations, that is roughly 1,833 monthly.
Tooling. Helpdesk licences, knowledge base, chat, analytics, surveys. Audit this annually, because stacks accumulate duplicates nobody reviewed.
AI and automation spend. Whatever you pay for automated resolution or agent assistance.
Quality and training. Review time, coaching, and onboarding for new hires.
On these illustrative figures a four-person team with a manager, engineering escalation, and reasonable tooling lands somewhere around 27,000 to 28,000 monthly. The specific number matters less than including all six lines.
Building the denominator
Issues genuinely resolved, not tickets closed.
Three adjustments:
Remove auto-closures. A ticket closed for inactivity is an administrative event. Counting it as resolved flatters the metric and hides the cases you most need to see.
Merge repeat contacts. If a customer contacts three times about one problem, that is one issue. This adjustment is the difference between a metric that rewards closing and one that rewards solving.
Include automated resolutions. If a system resolved a question without a human, that is a resolved issue and it belongs in the denominator. Otherwise automation will appear to make your cost per resolution worse.
The result and what to do with it
Total cost divided by resolved issues. On the illustrative figures above, 27,900 divided by 6,000 gives 4.65 per resolution.
That number on its own is not very useful. Segmented, it is.
Segment before concluding
Run the same calculation per topic using the queue analysis method. The variance between topics is where the actionable information lives.
A typical result: access questions at well under a pound each, integration setup at fifteen or twenty, refund conversations somewhere between. Those are different businesses inside one queue, and a single blended average describes none of them.
The gap between your cheapest and most expensive topic is your opportunity, and it is far more useful than comparing your average to a published benchmark that does not disclose its inclusions.
Comparing hiring against automation
This is what the model is for, and it is the only way to compare them honestly, because both change the same ratio.
Hiring raises the numerator by a fully loaded salary and raises the denominator by whatever that person resolves. Cost per resolution improves only if the new person resolves at above the current average, which new hires typically do not for several months.
Automation raises the numerator by the automation spend and raises the denominator by the issues it resolves. Because the marginal cost of the next automated answer is low and the volume is high, this usually moves the ratio faster, provided the topics are genuinely repetitive.
Model both at your actual numbers over twelve months, including the ramp period for a new hire. The answer is frequently not what either advocate expected.
The guardrail
Cost per resolution can be gamed by loosening what counts as resolved. Watch reopen rate alongside it, always.
If cost per resolution falls and reopen rate rises, you have not saved money. You have moved it into next month and added customer frustration on top. That combination is the single most important thing this model can tell you, and it is the reason to build it properly rather than approximately.
What changes if you deploy automation
Expect three things, and expect at least one of them to alarm someone:
- Total cost falls or flattens. This is the goal.
- Cost per resolution falls. Also the goal.
- Human cost per contact rises. This is arithmetic, not failure. Automation removes the shortest and cheapest contacts, so the remaining human mix is harder by definition.
Explaining the third one before it happens saves a difficult conversation later. It is the most common reason a working automation programme gets questioned.
Frequently asked questions
What should be included in cost per resolution?
Why divide by resolved issues rather than closed tickets?
How do I compare hiring against automation?
Should engineering escalation time be included?
Resolve, don't deflect.
See Fidiora resolve a ticket, capture a lead, and keep the bill predictable.