Average resolution time rewards closing tickets early. Tickets closed per agent rewards closing them twice. Four numbers actually tell you whether support is working.
Every ticketing system ships with a dashboard, and most of those dashboards are optimised for the thing that is easy to count rather than the thing that matters. The result is a monthly report full of numbers that look like performance management and are mostly measuring volume.
The test for whether a metric belongs in a monthly review is simple: if somebody wanted to improve this number without improving anything real, could they? If the answer is yes, it is a reporting number, not a management number.
The four worth watching
Tickets per user per month, trended
The single most useful number, and almost nobody reports it. Total ticket volume tells you how big you are. Tickets per user tells you how much friction the average person is experiencing, and it is comparable across time even as headcount changes.
A healthy environment trends downward as problems get fixed properly. A flat line over a year means you are keeping up and not getting ahead. An upward trend means something is degrading and the ticket queue is absorbing it.
Repeat tickets
The same person, the same issue, within thirty days. This is the clearest signal of a ticket closed rather than solved, and it is the metric that most directly measures quality.
It is also the one metric that is genuinely hard to game, because the only way to improve it is to actually fix things.
Time to first meaningful response
Not the automated acknowledgement. The first point at which a human has read the ticket and said something specific about it.
This correlates with satisfaction more strongly than resolution time does, which makes sense: people can work around a problem for a day, and what they cannot tolerate is not knowing whether anyone has seen it.
Backlog age
Not backlog size. Age. Specifically, how many tickets are older than two weeks, and what the oldest one is.
Queues do not fail by getting big. They fail by developing a stratum of old tickets that everyone has stopped looking at, which becomes the thing users complain about even though it is a small fraction of volume.
Why the common ones are worse than useless
Average resolution time rewards closing easy tickets fast and leaving hard ones open, or closing hard ones prematurely. It is also dominated by outliers, so a single three-week ticket distorts the month. If you must track duration, use the median and report the long tail separately.
Tickets closed per agent rewards volume over quality, and in a team under pressure it rewards splitting one issue into three tickets. It also punishes the engineer who spends a day fixing the cause of forty tickets.
SLA attainment as a single percentage compresses everything into one number that is almost always in the high nineties and therefore carries no information. Report the misses instead: how many, which, and why.
Satisfaction scores are fine when the response rate is high enough to mean something. Below about twenty-five percent you are measuring the people who were either delighted or furious, and the average of those two is noise.
The monthly review
The step that converts reporting into improvement is the third one. A repeating issue has to leave the ticket queue and become a problem with an owner and a date, because the queue is designed to handle incidents and has no mechanism for root causes.
In practice this means one person leaves the review with one task that is not a ticket. One per month is enough. Twelve causes fixed in a year will visibly change the first metric.
What the numbers cannot tell you
Two things, both important.
Tickets nobody raises. Every organisation has a population who have given up and developed workarounds. They are invisible to every metric in this article, they are often the most senior people, and the way to find them is to ask. A short survey twice a year with one open question, being "what do you work around rather than report", finds things no dashboard will.
Whether the right things are being worked on. A queue can be beautifully managed and entirely occupied with low-value work while a structural problem goes unaddressed. The monthly review's job is partly to notice that.
If you are a provider's client
Three things to ask for in your contract or your next review.
The raw ticket data, not just the summary. You should be able to see every ticket, its timestamps and its category, and run your own count. A provider who will not provide this is reporting on themselves without a check.
Tickets per user, trended over at least six months. If it is going up, that is a conversation worth having early.
The top repeating issue and what is being done about it. The answer to that question each month tells you more about the relationship than any dashboard.
