The 8 IT helpdesk metrics every IT manager should actually track

Our mean time to resolution dropped 31% in one quarter, and I was delighted about it for roughly six weeks.

Then I actually read some tickets. The team had started closing a ticket at the moment they had a working stopgap, then opening a fresh one for the real fix. Nobody told them to do that. Nobody was cheating. They had simply worked out, correctly, which number they were being judged on, and found the cheapest honest way to move it.

The work took exactly as long as before, and so did the waiting. My dashboard looked terrific.

Every IT helpdesk metric on this list can be gamed, and most of them get gamed by well-intentioned people who are just responding to what you decided to measure. So for each one, the useful question is not what it tells you. It is what it will tell you once your team has had two quarters to adapt to it.

The eight, and the specific way each one lies

1. Mean time to resolution.

MTTR tells you how long work takes from first human contact to a confirmed fix. Measure it in business hours, not wall clock, or every Friday afternoon ticket looks like a disaster.

How it lies: the mean hides the tail, and the tail is the only part anyone remembers. A single request that took nineteen days drags your average up a little and then gets forgotten by everybody except the person who waited nineteen days, who is currently telling three colleagues that IT is hopeless.

Report the median and the 90th percentile instead, segmented by category. Password resets and laptop replacements do not belong in the same number. If I could publish only one resolution figure, it would be the 90th percentile, because that is the one your reputation is actually built from.

2. First contact resolution.

The share of your volume that gets solved at first touch. It is the best single indicator of whether your documentation and your intake are any good.

How it lies: it rewards closing quickly rather than solving properly. And it competes directly with your reopen rate, because the fastest way to raise first contact resolution is to declare victory early.

Never look at it on its own. Ever. FCR paired with reopen rate is a real measurement; FCR alone is an invitation.

3. Ticket deflection rate.

Define it honestly: resolutions reached without a human, divided by total requests including the deflected ones. If your denominator only counts tickets that were filed, you are measuring nothing.

Here is the trap, and it is a bad one. Successful deflection and people giving up look identical in your support analytics. Both produce fewer tickets.

One team discovered their staff had been downloading whatever free tool they needed and hoping it was fine, because asking IT felt expensive. That behaviour would have shown up as excellent deflection. So pair deflection with something that detects workarounds: unsanctioned app installs, expense claims for software, or simply asking people in a survey whether they solved their last problem themselves or gave up on it.

4. Employee satisfaction.

Measure it with a two-click micro-survey attached to the ticket, plus something broader once a quarter. Per-ticket response rates above 25% are good, and you will not get there with a ten-question form.

How it lies: the people who answer are the delighted and the furious. The vast, mildly-inconvenienced middle never replies, so your ESAT is a bimodal distribution wearing an average as a disguise.

There is a subtler problem too. One team ran a device refresh that worked perfectly, technically speaking: drop-shipped hardware, self-configuring, nothing for anyone to install. People were anxious anyway, and what they talked about afterwards had nothing to do with whether the technology worked. Satisfaction measures the experience of being helped, and resolution quality is only one input into that. Write your survey question accordingly, or you will keep getting scores you cannot explain.

5. Cost per ticket.

Total loaded support cost divided by ticket volume. Useful for capacity planning and for comparing categories against each other.

How it lies: it improves when you route work into direct messages that never become tickets. Your numerator stays flat, your denominator shrinks, and your unit cost falls while your service gets worse and your busiest person becomes invisible. This is the metric most likely to reward the exact behaviour you are trying to stop.

The fix is to keep an honest correction factor. Count every support interaction for two weeks, including the hallway ones, divide by the ticketed count, and multiply your volume by that. Teams that bother usually find something between 1.3 and 2.2.

6. SLA compliance.

Leadership loves SLA compliance, because it is the one number on the list that looks like a contract: the percentage of tickets resolved inside their promised window.

How it lies: teams optimize for the clock rather than the outcome. Tickets get reclassified into a category with a longer window, paused for "awaiting customer" while somebody investigates, or closed and reopened to reset the timer. None of this is malice. It is what happens when a number has consequences and the underlying work has not changed.

There is also an honest limit worth admitting out loud. Vendor escalation through public developer forums has no SLA whatsoever, and response depends entirely on which engineer happens to see your post and whether they are allowed to talk about it. Practitioners who escalate platform bugs for a living describe the range as anywhere from boilerplate thanks to an engineer who tells you everything. So any SLA you publish on a vendor-dependent issue is a promise you do not control. I stopped publishing them, and the relief was immediate.

7. Reopen rate.

Tickets reopened within 14 days, divided by tickets closed. Track it per category and per person, and share it without drama.

I think this is the most honest number on the list, and it is the least gamed by a wide margin, because the only way to game it is to refuse to help someone who came back to you. Almost nobody does that. It is too visible and too obviously awful.

Read it against first contact resolution. High FCR with a high reopen rate is closing theatre. Low FCR with a low reopen rate means you are slow but real, which is a fixable problem. Both high is a documentation gap. Both low means you have a genuinely healthy tier one, and you should go and tell them so.

8. Backlog age distribution.

Not the backlog count. The distribution. Bucket everything open into 0 to 2 days, 3 to 7, 8 to 30, and over 30, and watch the shape rather than the total.

A stable count can hide a growing tail perfectly well, and the tail is where the money and the reputational damage live. One district found free-text requests got miscategorized and then sat in the wrong queue for weeks, partly because faculty could not agree on categories. One person's broken screen protector is another person's broken screen. Their blunter diagnosis was that things sat unprocessed simply because people do not pay enough attention to queues.

That is what the over-30 bucket is: an inventory of your routing mistakes, sorted by how long you have been ignoring them.

Three measurements to stop taking

Ticket volume as a performance measure. Volume going down can mean your systems got better or it can mean your colleagues stopped asking. Those are opposite outcomes with identical readings, which disqualifies volume as a KPI regardless of how good the chart looks.

Individual tickets-closed leaderboards. I ran one for two quarters. It worked exactly as designed, and that was the problem. My fastest closer had optimized himself into a specialist in short, easy tickets, and the person who took the ugly six-week storage migration finished the quarter looking like the weakest member of the team.

Anything that makes a person look bad for taking on a hard problem will get you fewer people taking on hard problems. That took me a year to undo, and I am not certain I fully did.

The reliability problem sitting underneath all of it

Here is the part almost no metrics article deals with. Before you argue about which number to track, check whether the number you already report is being produced by something that works.

Two stories from fleet management make the point better than I can in the abstract.

The first is about dates. MDM enrollment timestamps get overwritten whenever a machine is re-enrolled, which service desks do routinely as a fix for all sorts of unrelated problems. One Mac administrator put it plainly: something that was enrolled two years ago was now enrolled last week, and he no longer knew when it was deployed. Every metric built on that timestamp, average device age, refresh due, warranty exposure, was wrong, and nothing in the console indicated a problem. His fix was to write his own build name and deployment date directly onto each machine at first setup and read that instead.

The second is about single points of failure. One long-running compliance check, verifying that machines had completed a platform SSO migration, began failing silently after a routine OS update and restart. A couple of dozen machines simultaneously lost their SSO profile, dropped out of compliance, and stopped reporting compliance data upstream. Three symptoms, one cause. The fix was not a better check. It was a second, simpler, dumber check written alongside it, so that when the clever one times out the group stays populated correctly.

Generalize that, because it applies far beyond device management. If a single fragile detector gates a number you report to leadership, that number will eventually be confidently wrong, and you will find out in a meeting.

Where history goes. MDM platforms are good at current state and bad at answering what your patching level was six months ago, which is precisely the question an auditor asks. Ship device telemetry daily into a SIEM, a data lake, or your ticketing system, and treat the management console as a live view rather than an archive. Historical evidence has to accumulate somewhere that is not the tool that only knows about now.

And one boring metric that pays for itself. A government IT org runs a weekly zero-use device report plus a separate weekly hasn't-checked-in report, and uses both to challenge departments monthly on whether they still need paid lines. That same audit found they were paying for roughly 4,000 device licences against about 3,500 actual active devices. Five hundred phantom entries, found by reading a report nobody considered strategic.

The metric that changes the conversation entirely

One team started mapping their security questionnaire responses to closed deals, and found that answering a prospect's questionnaire well made the deal roughly eight times more likely to close.

Sit with that for a second. It converts security and IT work from a cost line into a revenue-attributable one, and every budget conversation afterwards is a different conversation. Nobody argues about the cost of a control that visibly helps sales close.

I think this is the most powerful metric an IT team can build, and hardly anyone builds it, because it requires going and asking another department for their data. Support tickets tied to onboarding time, device reliability tied to field productivity, access request latency tied to how fast a new salesperson reaches quota. Any of those beats a perfect MTTR chart.

The scorecard, on one page

The quarterly reliability audit is the item people skip, and it is the one I would defend hardest. Once a quarter, take each number on your scorecard and trace it back to the query, the extension attribute, or the report that produces it. Confirm it still runs. That exercise has caught more embarrassment for me than any dashboard ever prevented.

Promises

A metric is a promise about what you have decided to notice.

Choose MTTR and you have promised to notice slowness. Choose reopen rate and you have promised to notice whether the fix held. Ticket volume promises to notice silence, which means the day your colleagues give up on you will register as your best month on record.

Pick the ones that make you notice the things you would rather not know about. Then go check, on a Tuesday afternoon when nobody is asking, that the thing producing the number is still alive.

---

Foqal brings IT support into Slack and Microsoft Teams, with structured intake and reporting built so the numbers reflect the work that actually happened.