How to calculate cost per ticket (with a methodology you can defend)

Cost per ticket is the metric finance asks for and support teams most often compute wrong — usually by accident, occasionally on purpose. The formula is one division; the methodology is everything around it: what goes in the numerator, what counts as a resolved ticket, and which segments you report.

Done honestly, it is the number that justifies automation, staffing, and tooling decisions. Done sloppily, it is a number everyone quietly distrusts. Here is the defensible version.

Cost per ticket = fully-loaded support cost for a period ÷ tickets resolved in that period. Use resolved, not received — you are measuring the cost of doing the work, not of receiving it — and use a period long enough to smooth spikes; a quarter is a good default.

Fully-loaded means everything the support function costs, not just base salaries: compensation with benefits and payroll taxes, the share of each person’s time actually spent on support if they split roles, tooling (helpdesk seats, AI add-ons, monitoring), and a defensible slice of overhead — management time, onboarding, facilities if you allocate them elsewhere too.

The most common omission is partial-time responders: the engineers who spend a few hours a week on escalations appear in no support budget line, but their hours are often the most expensive in the whole system. If engineering interrupts are part of how tickets get resolved, price them in — that is frequently the number that makes the automation case by itself.

Four traps account for most bad cost-per-ticket figures. Counting received instead of resolved inflates the denominator with tickets nobody handled. Cherry-picking a quiet period flatters the number and sets a baseline you cannot repeat. Ignoring reopens counts one piece of work twice — a reopened ticket is the same resolution, still in progress. And mixing ticket types into one blended average hides everything interesting: a password reset and a production bug do not cost the same, and pretending they do makes the metric useless for decisions.

The reopen rule deserves emphasis because it interacts with automation: if an AI closes tickets that requesters reopen, an unadjusted cost-per-ticket makes the automation look better than it is. Net out reopens before celebrating.

A single blended number can tell you whether costs are trending, but it cannot tell you what to do. The decision-driving version is segmented: by category (access requests vs bugs vs how-do-I questions), by tier or handling path (self-service, AI-resolved, front-line, escalated), and by channel if your intake is split.

The segmentation is what reveals the automation opportunity: when you can see that 40% of volume is routine categories costing real money per ticket to hand-process, the case for deflecting and auto-resolving that band writes itself — and after rollout, the same segmentation is what proves the saving actually landed rather than shifting cost between buckets.

When comparing AI resolution cost to human cost, resist quoting the vendor’s unit price against your fully-loaded human number — that is an apples-to-oranges flattering to the AI. Load the AI side the same way: platform fees, connector and setup engineering, and the human time spent reviewing approvals and handling reopens from bad closes.

The comparison usually still favors automation for routine categories by a wide margin — the point of doing it honestly is that the number survives scrutiny in the budget meeting, which the marketing figure never does.