AI Agent Cost Per Resolved Ticket: The Honest Version

The dashboard says the bot handled 4,000 conversations last month and cost very little. AI agent cost per resolved ticket is a different number, usually several times larger, because handled and resolved are not the same word. The gap between them is where support automation business cases quietly stop being true.

What belongs in the numerator?#

Three things, and most calculations include only the first. The model spend for every attempt including the failed ones, the human minutes spent finishing what the agent could not, and the cost of rework when a customer returns because the first answer did not actually solve their problem.

The second term is the one that dominates. A person handling a support ticket costs vastly more than a model call, so escalations drive the total even at a modest escalation rate. Any calculation that treats human time as free is not measuring cost per resolved ticket, it is measuring the API bill.

The third term is invisible in most reporting. A customer who accepts an answer, leaves, and contacts you again 2 days later was recorded as a success and then as a new ticket. The system counted one deflection and one fresh conversation, and the truth was one unresolved problem handled twice.

Most published figures include only the first term, which is why they are so much smaller than reality.

Rework is worse than a straight escalation, not equal to it. The second contact costs the human handling anyway, plus a customer who is now annoyed, plus the time they spent on an answer that did not work. Counting it as a new ticket makes the numbers look better precisely where they should look worse.

Where does the denominator go wrong?#

By counting conversations rather than resolutions. Every self-service tool can claim a large number of interactions, and a share of those were people who left without an answer, people who found the escalation button, and people who asked something trivial that no human would have seen anyway.

Deciding what counts as resolved has to happen before you measure it, because afterwards you will choose the definition that flatters the result and do it without noticing. The usable definition is behavioural: the customer did not contact you again about the same thing within a defined window.

Three of these rows move in the flattering direction by default, and none of them move back on their own.

Pick a re-contact window and apply it consistently. Anything between 3 and 7 days works, and the exact figure matters less than choosing it in advance and not changing it in a quarter where the result is disappointing.

What does the arithmetic actually look like?#

Set the cost of a human-handled ticket at 20 times one model attempt, which is conservative for most support organisations. Run all 100 tickets through the agent first, then finish the escapes with a person, and the total falls sharply as true resolution rises. What surprises people is the shape at the bottom.

At a true resolution rate of 0, you pay 100 units for attempts plus 2,000 for the humans who did all the work anyway, which is 2,100 against a purely human baseline of 2,000. That is 21 per ticket against 20, so automation that resolves nothing costs more than no automation, and it does so quietly, because the attempt cost is small and nobody adds it back.

Modeled: a human ticket costs 20 attempts. The 0 percent bar sits above the all-human baseline of 20.

The relationship is linear, which is worth stating because people expect a threshold effect and plan around one that does not exist. Every percentage point of true resolution is worth the same as every other, so moving from 20 to 30 saves exactly what moving from 70 to 80 saves. There is no cliff to get past and no plateau to stop at.

Break-even against handling everything by hand arrives at about 5 percent true resolution, which sounds like an absurdly low bar. It is, and systems still miss it, because the number being reported is deflection before rework is subtracted and the true figure is a good deal lower than the dashboard says.

How does it compare to a human-handled ticket?#

Favourably in most cases, and by a smaller margin than the pitch claims. The honest comparison sets total cost against the fully loaded cost of the humans who would otherwise have done it, including the ones still finishing escalations, and it holds the resolution definition constant on both sides.

Hold the mix constant too. An agent measured on the easy half of the queue and a human team measured on all of it are not comparable, and the difference flatters the agent by however much the hard half costs. If you segment for the comparison, segment both sides.

The comparison people actually run puts the model bill against a fully loaded human salary, which is not a comparison at all. One side carries every overhead and the other carries none, and the ratio it produces is memorable, quotable and wrong.

Each of these is real, recurring, and absent from the number that got the project approved.

When does automation stop being cheaper?#

When true resolution is low and the ticket mix is hard, which is the situation most teams start in rather than end in. A queue dominated by account-specific problems that need a lookup, a judgement and an exception is not a deflection problem, and putting a conversational layer in front of it adds a step without removing one.

Segment first. A blended queue figure hides both the category that works and the one losing money.

Ticket mix moves over time as well, and it moves against you. As the agent absorbs the easy questions, the remaining queue is progressively harder, so the escalation rate rises even when nothing about the agent has changed. A cost per resolved ticket that was accurate in month 1 drifts through no fault of the system.

The useful move is to segment before automating. Measure cost per resolved ticket by ticket category rather than across the whole queue, because a blended figure hides both the category where the agent is excellent and the one where it is actively costing money. Where a human takes over is the same decision viewed from the design side.