How to calculate the true cost of your IT ticket backlog

I once lost a budget request with a slide titled "Benefits of a modern help desk."

Seven bullets. Faster resolution, better visibility, happier employees, the usual set of help desk benefits you can find on any vendor's landing page. Our finance director listened politely and asked exactly one question: what happens if we don't do this?

I said something about employee satisfaction, and she moved on to the next agenda item. I did not get the money.

She was right to say no. I was asking her to buy an improvement I could describe but not price, replacing a status quo I had never priced either.

The following year I came back with a single number covering a single category of request, and got funded in about four minutes.

Direct handling cost is the easiest line and the smallest one

Start with the thing everyone already calls cost per ticket.

Take the loaded hourly cost of whoever handles it. Loaded means salary plus employer taxes, benefits, and that person's licences, which in most orgs lands between 1.25x and 1.4x base. A support engineer at $75,000 base is about $97,500 loaded, and against roughly 1,880 productive hours a year that is $52 an hour.

Then multiply by handling time. Not resolution time. Actual minutes of human attention.

Here is the part that gets left out. One ticket is almost never one touch. It is a first response, a clarifying question, a re-route to whoever actually owns the system, a wait, a second attempt, and sometimes a reopen three days later because the fix did not hold. Each of those is a fresh context switch, and a context switch costs more than the clock says.

So the real shape is:

Direct cost = loaded hourly rate × (first-touch minutes + Σ subsequent touch minutes) ÷ 60

Eighteen minutes on the first touch plus two more touches at twelve minutes each, at $52 an hour, gives about $36. A reopen adds twelve to twenty more. A cross-team re-route adds two, because the receiving team reads in from scratch.

Which means the interesting variable in your help desk workflow is touch count, not speed. I have watched teams cut average handling time by 20% and see no change in cost, because the tickets were being handled quickly three separate times.

The line almost nobody counts, and it is usually the biggest

Your ticket costs $36 to handle. What did it cost the company while it sat there?

That is the waiting cost, and I think it is the only line that reliably moves a budget conversation, because it is the only one denominated in the business rather than in IT.

Waiting cost = blocked person's loaded hourly rate × hours blocked × probability they are genuinely blocked

That third term is what keeps this defensible. People are resourceful. They work around you, or go get coffee, or do the other half of their job. Bill the company eight hours of lost salary for an eight-hour outage and any competent finance person will throw the model out, correctly.

So estimate it low.

A product manager at $120,000 base is roughly $156,000 loaded, or about $83 an hour. Her laptop will not connect to the VPN. The request sits for three and a half hours. She is not idle for all of it, so call the blocked probability 0.35, deliberately conservative.

3.5 × 0.35 × $83 = $102.

Against $36 of direct handling cost. The waiting cost is nearly three times the handling cost, on a boring ticket, using a probability estimate designed to weaken my own case.

Now run the same arithmetic on something that sat for three weeks.

Escalation is billed to a budget you cannot see

There is a cost here that does not show up in hours at all.

Consider a fleet of a few thousand mobile devices inherited from a single administrator who refused to document anything. He was the only person who understood how the enrollment records were structured, so every non-trivial question became an out-of-hours phone call to one human being. That org eventually distributed manage rights to departmental liaisons and trained the whole asset team so nobody was a single point of failure. Their verdict on the old setup stuck with me: having no shared documentation "prevented our users from getting a really good experience."

When a request reaches a senior engineer who should never have touched it, compute the hourly delta. A tier-one hour at $52 against a specialist hour at $95 is a defensible line, so include it.

The honest version of the escalation multiplier, though, is that you mostly pay it in retention. The senior person answering their fourth after-hours question this month is not filing a complaint. They are updating their CV. Replacing them costs six to twelve months of salary, and none of that shows up in your help desk metrics.

I have never once got a retention estimate past a finance team, so I stopped trying. Track the escalation rate instead: the share of tickets per category that touch someone above tier one, monthly. When it climbs you have a documentation or tooling problem, and both are cheaper than a resignation.

Rework, or what a wrong category actually costs

One K-12 district replaced their free-text "describe your problem" box with categorized buttons. Their reasoning was earned the hard way: free-text tickets got miscategorized and then sat in the wrong queue for weeks, partly because faculty could not agree on what counted as what. One person's broken screen protector is another person's broken screen.

Their other observation was blunter. Things sat unprocessed simply because people do not pay enough attention to queues.

Price that. A teacher with a genuinely broken screen, loaded at maybe $60 an hour, degraded rather than stopped, so a blocked probability of 0.15. Three weeks in the wrong queue is fifteen working days, about 120 hours.

120 × 0.15 × $60 = $1,080.

The same request routed correctly and closed in three hours: 3 × 0.15 × $60 = $27.

Yes, the ratio is just the time ratio, and that is the point. Handling cost was identical and the engineer equally competent. Nothing changed except which queue it landed in on day one. Multiply a thousand dollars by however many miscategorized tickets you process a year. Mine ran into the hundreds.

The happier version of the same mechanism: one district cut its annual inventory audit from close to three weeks to about a week, crediting input validation catching errors at the point of entry rather than after the fact. Two engineer-weeks a year, out of a validated form field.

Two corrections

The invisible-work correction. A five-person team supporting an entire campus logged just over 1,200 tickets in roughly a year. That is about 240 tickets per engineer per year, or one per person per working day.

Nobody in support does one thing a day. That figure measures how much work reached the ticket system, not how much work happened.

If a real share of your support arrives in direct messages, your denominator is too small, so every per-ticket number you compute is wrong in the same direction: too low. I resisted this correction for years because applying it made my own efficiency numbers look worse. Bad reason.

Precision is not the goal. Anything better than zero is. Pick two weeks, have each person tally interactions that never became a ticket, then divide total by ticketed. Every team I know that has counted landed between 1.3 and 2.2. Apply it to volume, not unit cost.

The avoidable-ticket rate. Sample 100 closed tickets at random, read them, and mark each: did this genuinely require human judgement?

Password resets, group membership requests, "which VPN profile do I need," licence assignments, a charger. Whatever fraction comes back avoidable is the number that justifies automation spend, because it is the only fraction where tooling removes the cost instead of moving it.

What deferred work costs when it all arrives on the same morning

Backlogs do not stay evenly distributed. They collect, then land.

One organization ran an identity migration with a careful self-service window and watched most of it get ignored. Roughly a thousand accounts had to be rebuilt by hand on cutover day, several minutes each, worked by six to ten people for a full day.

The labour is easy: eight people, eight hours, $52 an hour, about $3,300. Trivial. Nobody funds a project to avoid $3,300.

Then add the waiting cost. A thousand people, each unable to work properly for a couple of hours, at $83 loaded, at a conservative 0.5 blocked probability. That is $83,000 in a single day, and the visible cost was four percent of the total.

The same asymmetry shows up on the good side of the ledger. An organization that moved to zero-touch provisioning went from over two hours of IT hands-on prep per device plus more than an hour of end-user setup, down to zero IT hands-on time and about 30 minutes for the user. Per device: 2 × $52 plus 1 × $83 gives $187, against a new cost of 0.5 × $83, about $42. Call it $145 saved per machine.

Then they onboarded roughly 70 new hires simultaneously, which the old process could not have absorbed. 70 × $145 is about $10,000 in one hiring wave, and the constraint that really bit was 140 hours of IT hands-on work landing inside a single week. Three and a half weeks of one person's capacity, due Monday.

Sometimes the cost just sits in an invoice. A government IT org reconciling licences after an MDM consolidation found it was paying for roughly 4,000 device licences against about 3,500 active devices. Five hundred phantom entries, recovered purely by auditing zero-use reports. At even $8 per device per month that is $48,000 a year, and it had run for years. They now pull a weekly zero-use report plus a separate weekly hasn't-checked-in report, and use both to challenge departments monthly on whether they still need paid lines.

The formula, and the five inputs to go collect

Five inputs to collect before your next budget conversation:

1. Two loaded hourly rates from finance, in writing. One for support staff, one for the average person who files a ticket. Sourcing them from finance makes the model partly theirs, which changes the meeting.
2. Touch count for your top five categories. Median, not mean, plus the reopen rate for each.
3. Time in queue by category. Median and 90th percentile. The 90th is where the money is.
4. Your unticketed-to-ticketed ratio, from an honest two-week tally.
5. An avoidable rate from a hand-read sample of 100 closed tickets.

Now the part I feel strongest about. Do not present the total.

A whole-organization IT ticket backlog cost is easy to produce and easy to dismiss. It arrives as a large round number, the committee discounts it by 70% because it smells like advocacy arithmetic, and the meeting moves on. I have done this, and it fails.

The persuasive version is narrow, conservative, and about one category: onboarding requests, or VPN access, or laptop replacements. Pick one, use your own real numbers, use a blocked probability so low it is obviously unfair to yourself, and attach a costed fix.

The data being yours is what makes it land. One team won a full platform-change business case by pulling their own support-ticket history and showing fewer audio and driver issues on one platform than the other across their call-taker fleet. No vendor benchmark, no analyst report, just their own tickets, which nobody could plausibly dispute.

Your ticket history is the best evidence you own about how your company actually works, and most teams never mine it beyond a monthly volume chart.

The thing underneath all this

A backlog is a pricing failure long before it becomes a queue management failure.

Work sits because sitting is free to whoever could have prevented it and expensive to somebody nobody is measuring. The teacher, the product manager, the new hire waiting on a laptop, the senior engineer taking a fifth call at 9pm. They are all paying for a decision made somewhere else on the org chart.

Costing it moves the bill to where that decision gets made, which is the only place a bill has ever changed anybody's behaviour.

Do it once, honestly, for one category. There is a strange kind of fun in watching a number you built in a spreadsheet do the arguing for you.

---

Foqal builds conversational IT support for Slack and Microsoft Teams, with structured intake and reporting that make ticket costs visible instead of theoretical.