Most writing about artificial intelligence in customer support concerns the part the customer sees: the chatbot on the website, the automated first reply, the deflection of a question before it reaches a person. The larger and far less examined cost sits behind that, in the internal work of running a ticket once it has been logged. MetricNet's service-desk benchmarking, led by Jeff Rumburg, puts the average cost per ticket at about $15.56, with a range from $2.93 to $49.69 across the organizations it measures. That spread traces to how much human handling each ticket absorbs, and almost none of that handling is the conversation the customer remembers.
What the back office of support actually does
When a ticket arrives, whether from email, a portal, or a phone call written up after the fact, a person reads it and decides what it is. They classify it as a billing dispute, a shipment that never arrived, a login that fails, or a request to change an order. They route it to the queue or the individual who handles that category. They open the systems of record and assemble context: the customer's account, the order history, the open invoices, the prior tickets on the same issue. Only then do they draft a resolution, and if they cannot resolve it at their level, they escalate it to someone who can. This internal work is what we mean by the back office of support. It is the classifying, routing, context-gathering, drafting, and escalating that happens between the question arriving and the answer going out, and it is where the labor sits.
Why labor, not tooling, sets the number
MetricNet's research attributes 67 percent of service-desk costs to labor (salaries, benefits, incentive pay, and contractors), with technology, telecommunications, facilities, and other overhead making up the remainder. That ratio explains why the headline number is so hard to move with better tooling alone. A cheaper ticketing platform trims the small share, while the handling minutes are the large share. If most of what a ticket costs is the time a trained person spends reading it, finding the relevant account state, and writing back, then the question worth asking is which of those minutes require the person's judgment and which are mechanical retrieval and routing that a person happens to be doing.
The cost compounds on escalation
The single-ticket figure understates the problem because issues do not always resolve where they land. MetricNet's North American benchmarks put the fully loaded cost of a ticket at $22 when the level-1 service desk resolves it, $69 when level-2 desktop support resolves it, and $104 at level 3. The costs are cumulative: in the Metric of the Month column he writes for HDI, MetricNet's Jeff Rumburg notes that a ticket logged at level 1 and escalated to desktop support carries both tiers' resolution cost, so a customer who has to be handed off twice generates the cost of all three handlers, not the cheapest one. The same column draws the line precisely: first-contact resolution, whether an issue closes in the customer's first interaction, is a quality metric that drives customer satisfaction, while first-level resolution, whether it closes at the tier that received it, is a cost metric, and Rumburg concludes that maximizing first-level resolution is the equivalent of minimizing the total cost of ownership. Resolution rate determines how many separate contacts a single underlying issue generates, so a longer call that ends the matter is cheaper than a fast one that produces a callback. The first-level resolution rates in MetricNet's benchmarking database vary widely, from about 38 percent to about 98 percent, with the low end at desks that log tickets and dispatch anything complex and the high end at desks whose agents have the knowledge tools to close most of what arrives. The variable that moves cost is getting the ticket to the right place, with the right context, the first time.
Walking the redesigned internal workflow
The redesign mechanizes the retrieval and routing while keeping the human responsible for the customer. An agent reads the incoming ticket and classifies it against the categories the team already uses, the same taxonomy that drives the existing queues. It routes the ticket to the correct queue, and where a category is ambiguous it flags the ambiguity rather than guessing silently. It then assembles context from the systems of record (the account, the order, the invoice ledger, the prior tickets), much as the team writes back into systems that have no usable API when the data lives in an older platform. With that context in hand it drafts a resolution: the reply to the customer, the account note, the credit or correction the case calls for. A person reviews the draft, edits where the wording or the judgment needs a human, and sends it. The agent has done the classifying, the routing, and the assembly, which is the bulk of the minutes, while the person has spent their time on the decision and the relationship. This is the same shape as the worked example in the month-end close, where the agent does the chasing and matching and the controller rules on the exceptions.
Escalation only on genuine exceptions
The same discipline applies at the escalation boundary. Most tickets in a mature support operation are variants of a few hundred recurring situations, and those are exactly the ones where context assembly and a drafted reply land cleanly. The escalations that genuinely need a senior person are the long tail: the novel defect, the account in an unusual state, the dispute with no precedent in the prior tickets. The agent's job is to resolve the common cases at the first level and to escalate only the genuine exceptions, with the supporting detail already gathered so the senior handler does not start from a blank record. That is what bends the first-level resolution rate, the measure MetricNet treats as a proxy for the total cost of ownership. The economics of that residual tail, where the per-item handling stays expensive because the cases are rare and varied, are worth treating on their own terms.
A reasonable counter, answered
A reasonable counter is that support tickets are too varied and too consequential to route and draft mechanically, and that the cost of a wrong classification or a bad auto-draft, a refund issued in error or a customer told the wrong thing, exceeds the labor it saves. There is real force in this. Support is a relationship, and a confidently wrong reply does more damage than a slow one. The redesign answers it not by removing the person but by relocating them. The agent never sends to the customer on its own, the human reviews every draft before it goes out, and ambiguous classifications are surfaced rather than guessed. What gets removed is the reading, the lookup, and the routing that consume most of the minutes and none of the judgment. The classification of the ticket can be wrong; the resolution that reaches the customer is the one a person approved. The division in which the agent owns the mechanical majority and the person owns the customer and the exceptions is what an aligned engagement is built to hold, and it is why the redesign reduces cost without putting the relationship in the hands of a machine.