Why the same tickets keep coming back
A support desk measured on how fast it closes things will get very good at closing things. Recurrence is the number that tells you whether anything is actually being fixed.
Here is a support report that looks excellent. Average time to resolution is down to under four hours. Ninety-four per cent of tickets are closed within the agreed window. Satisfaction scores are good. Volume is steady.
Now here is the question that report cannot answer: how many of those tickets were the same problem arriving again?
Fast closure is not the same as fixed
Measure a desk on speed and it will optimise for speed. That is not cynicism — it is what measurement does, and the people doing it are usually responding sensibly to what they are judged on.
The fastest way to close a ticket is the workaround. Clear the cache. Restart the service. Reset the password. Reconnect the printer. Each is a legitimate fix for the person in front of you, and each takes four minutes instead of the two days it would take to work out why the service keeps falling over on Monday mornings.
Do that for a year and you have a desk that is excellent at closing tickets and a queue that never gets shorter.
Steady volume is not stability. It is often the sound of the same handful of problems circulating.
The number to start tracking
Recurrence. For any ticket closed this month, has something materially identical been closed in the previous ninety days? Group them by cause rather than by wording — "printer not working", "can't print" and "queue stuck" are one problem, and any categorisation that separates them is hiding the thing you are looking for.
Most organisations doing this for the first time find that a small number of underlying causes account for a startling share of total volume. It is rarely evenly spread, which is good news: it means a modest amount of work aimed at the right few things can measurably shrink the queue.
Separating incidents from problems
The distinction is old and still useful. An incident is this person, right now, unable to work. A problem is the underlying cause that will produce more incidents until it is dealt with.
They need different work, different time horizons and different people, and if they share a queue the incident always wins — because someone is waiting, and the problem is not visibly costing anyone anything this afternoon. That is precisely why the problem never gets done.
- Protect time for cause analysis. Not best-effort when quiet — it is never quiet. A fixed, defended share of the week.
- Open a problem record once the same cause has produced a threshold number of incidents, and give it an owner by name.
- Let the desk link a ticket to a known problem in one action, so the recurrence data accumulates without anyone being asked to do extra admin.
- Review the top causes monthly with someone who can authorise the fix. Many root causes are not support's to solve — they are a licence that was never renewed, a process that creates the calls, or a piece of hardware past its life.
When the root cause is not technical
A surprising share of recurring tickets are not faults at all. They are a joining process that does not create accounts in time, so every new starter raises three tickets in their first week. They are a form so confusing that a third of submissions need correcting. They are a change rolled out with no notice.
No amount of support skill fixes these from inside the queue, and a desk with no route to raise them will keep absorbing them indefinitely — usually while being told its volume is too high.
What good looks like
Not zero tickets. Things break, people need help, and a desk with nothing in the queue is usually one people have given up on. What good looks like is a queue whose composition changes: this quarter's common problems are different from last quarter's, because the old ones were dealt with.
If your top five causes have been the same for two years, speed of closure is not the metric to be proud of. It may be the reason nothing has changed.
