Support Metrics That Are Not Vanity: Backlog, Breaches & Reopens
Ticket counts and average response times are the two most reported and least useful numbers in support. The four measures that actually tell you whether a desk is coping, why reopens matter more than resolutions, and how to read a satisfaction score honestly.
Every support report opens with tickets received and tickets closed. Both numbers go up when the business grows and down when people give up on the helpdesk, which means they are equally consistent with things going very well and things going badly. They are reported anyway, because they are easy and because everybody else reports them.
The useful measures answer questions somebody would actually act on: is the backlog growing, is anything unowned, is work coming back after we said it was done, and are the promises we made being kept. Four numbers, and none of them is a ticket count.
The four that matter
| Measure | The question it answers | What to do when it moves |
|---|---|---|
| Open backlog, trended | Are we closing at the rate work arrives? | A rising line for three weeks is a capacity decision, not an effort problem |
| Unassigned count | Is anything owned by nobody? | Should be near zero every day — this is the number that guarantees breaches |
| Breaching share of open work | What proportion of live work has already failed its target? | A rising share with flat volume means the targets or the routing are wrong |
| Reopen rate | Are we closing things that were not fixed? | The single best indicator of whether resolution quality is real |
Backlog trend rather than backlog size is the discipline. A desk holding sixty open tickets steadily is in equilibrium; a desk holding thirty and adding four a week is in trouble, and the second one looks better in every monthly report. Trend is also the only version of the number that supports a hiring conversation, because it projects.
A desk holding sixty tickets steadily is fine. A desk holding thirty and adding four a week is in trouble — and it looks better in every monthly report.
Reopens are the honest measure
Resolution counts are the easiest support metric to game and nobody has to be dishonest to do it. Close a ticket to hit a target, the customer comes back, a new ticket is raised, both get counted as resolutions. Volume rises, targets are met, and the underlying problem is untouched.
A reopen count breaks that loop, which is why tracking reopens on the ticket rather than counting new tickets matters. A ticket that has been reopened three times is a specific, visible failure — and the pattern across a category tells you something no satisfaction survey will: which kinds of problem your team is closing without solving.
Read reopens by category, not by agent
Reopens concentrated on one agent is a coaching conversation. Reopens concentrated on one category is usually a knowledge or a product problem — the agent could not fix it properly because nobody can, with what they have. Starting with the agent view finds the wrong cause most of the time.
First response is not resolution, and both are promises
Two clocks run on every ticket and they measure completely different things. First response measures whether a human acknowledged a person. Resolution measures whether the problem went away. Conflating them produces the worst support behaviour there is: an auto-reply that satisfies the first clock while nothing happens on the second.
Both due times are stamped from the category when the ticket is created, on whichever clock that category uses — elapsed wall-clock, or working hours only. When you report on them, report the share of open work currently past its target rather than an average of everything closed. Averages hide the tail, and the tail is where your reputation is made — nobody remembers the ticket answered in four minutes.
Satisfaction, read honestly
A satisfaction rating on a resolved ticket is worth collecting and worth reading carefully, because it has a well-known bias: the people most likely to respond are those who were delighted and those who were furious. The comfortable middle stays silent, so your average is assembled from the two extremes.
Which makes the distribution more informative than the average, and the free-text comment more informative than either. Read the low ratings individually, every month, all of them. Twenty minutes on the actual sentences will tell you more than a year of watching an average drift between 4.1 and 4.3.
There is a second bias in our own implementation that you must know before you quote the figure to anybody: rating requires a login. Both routes that submit a rating authenticate the requester and check the ticket is theirs, so an employee using the tokenized portal cannot rate, and neither can an external customer on their signed tracking link. If your desk is mostly customer-facing, the satisfaction average on the dashboard is describing the logged-in minority of your work and presenting it as the whole. Read it as an internal-support signal until customer rating exists, and get your customer sentiment from the threads. The arithmetic of how narrow that can get is worked through in four ways to be a requester.
A month that looks fine and is not
Illustrative. The headline reads: 212 in, 208 out, 4.2 satisfaction — a good month. The other three lines say the backlog is growing, nearly a third of live work has already missed its target, and one closure in eleven was not a fix. Same data, opposite conclusion.
A composite score is a prompt, not a verdict
The helpdesk insight in AWRA OpsHub condenses this into a health score built from the breaching share of open work, the count of unassigned tickets and the recent satisfaction average, alongside a confidence indicator that reflects how much data sits behind it.
Two things to hold in mind about any score of this kind, ours included. It is a weighted rule, not a measurement — the weights are a judgement about what matters, and yours might differ. And it is low-confidence on low volume: a desk with nine tickets a month will produce a score, and that score is noise. Use it as a prompt to look at the four underlying numbers, never as a substitute for them.
What we do and do not do
What AWRA OpsHub does today
- Open, unassigned and breaching counts, computed live against your own tickets.
- Reopen count held on the ticket, so repeat failures are visible per ticket and per category.
- First response and resolution due times with the actual response and resolution timestamps beside them.
- Satisfaction ratings with submission dates, so recent sentiment can be read separately from historic.
- A composite health score with a confidence indicator, and a plain-language summary where an AI provider is configured.
- Ticket data available to the report builder, so you can define and schedule the trend reporting this article argues for.
More we can add to your workspace
- Working hours apply to SLA due dates, not to the metrics. A category can run its SLA clock on working hours, but the reported averages — time to first response, time to resolve — are still elapsed. Two tickets meeting the same working-hours target can therefore report very different elapsed durations, which is worth saying out loud before anyone benchmarks the numbers.
- An agent productivity or utilisation reporting. Tickets closed per agent is not a built-in measure, deliberately — it is the metric most likely to be gamed.
- A first-contact resolution measure. Reopen rate is the closest available signal.
- Automatic trend alerting, noticing that your backlog has risen for three consecutive weeks. Today that is a scheduled report and a person reading it.
Trend alerting is the practical one. Everything this article recommends measuring is available today — and tracking it over time means a scheduled report somebody actually reads, rather than a dashboard somebody occasionally visits.
Anything above that you need, we can build for you
Everything listed above as something we can add describes what ships in the standard product today — it is a starting point, not a limit on what AWRA OpsHub can do for your organisation. Kenya's eTIMS integration and its maintained payroll engine are both in the product because clients needed them and commissioned them; neither appeared by itself, and the same door is open for whatever you just read about. One qualification so this is worth what it claims: a small number of things on this blog we deliberately leave to a specialist rather than build — a statutory ledger we will not sign our name to, a rule that would decide a tax question for you, a clinical or member-funds record that belongs in a regulated system — and where that is true the post says so in those words. Everything else is a scope, a timeline and a price.
The operational work, which is what most commissions actually are
An extra approval stage in a chain that does not match the standard one, a custom field set on employees or assets that only your sector needs, an expiry that has to block an order rather than send an email, a report your board asks for in a shape nothing produces, or a scanner or weighbridge feeding the goods-in door. These are the commissions we are asked for most often and the smallest ones we quote — and unlike a revenue-authority pipeline, none of them waits on a regulator.
The module-shaped additions, which are the ones readers ask for most often
A price list with real discount authority, a customer-facing quotation that expires, a bill of materials or recipe costing, a staff advance that is issued, acquitted and chased, a member or unit ledger, a matching rule that holds a payment. Each of these is a build rather than a setting, and each has been quoted before — a bigger piece of work than a custom field, with a written spec and a date instead of a roadmap slide.
The report, document or pack nothing currently produces
The board pack in the shape your board actually asks for, a donor or funder layout, an invoice or receipt template carrying what your regulator or your customer expects, a dataset the report builder cannot reach yet. Usually the fastest thing on this list to deliver, because the data is already in the system.
Systems, rails and hardware you already run
The accounting package, CRM, online store, core banking or custom database you intend to keep — connected through our API so a fact is entered once and appears everywhere it is needed. Plus the physical edge: a scanner, a scale, a weighbridge or a till peripheral feeding the door it belongs to.
How it works: you describe the requirement, we return a written scope, timeline and cost, and once agreed it is built into your environment and maintained as part of the product. Nothing here waits on a regulator or a published specification, which is why operational builds are the ones we quote fastest. Tell us the requirement that would otherwise rule us out — that is a better first conversation than a demo.
Tell us what your operation needsThe reporting rhythm
- Daily, five minutes: unassigned count to zero, and anything past first-response target.
- Weekly: backlog trend line, and the reopen list read by category.
- Monthly: all low satisfaction ratings read individually, comments included.
- Quarterly: targets reviewed per category against what you actually achieve — a target missed 40% of the time is not a target, it is a fiction with a number on it.
That last one is where most support functions never go. Targets are set optimistically at launch and then defended for years against the evidence. Reviewing them against reality either produces a plan to meet them or an honest revision, and both are better than a promise everybody has privately stopped believing.
Our take
Stop reporting tickets received and closed. Report the backlog trend, the unassigned count, the breaching share of open work and the reopen rate — four numbers, none of which can be made to look good by working harder on the wrong thing. Then read every low satisfaction comment monthly, because that is the twenty minutes that changes anything.
See the support agent dashboard
Open, unassigned and breaching work at a glance, reopen counts on tickets, satisfaction ratings and a health score you can trace to its inputs.
Explore the agent dashboardFrequently asked questions
What is the single most useful support metric?
The backlog trend — whether the number of open tickets is rising, flat or falling over weeks. It is the only measure that distinguishes a busy desk from a failing one, and it is the only one that supports a staffing conversation, because a line rising steadily for a month projects forward and a snapshot does not. Ticket volume tells you about the business; backlog trend tells you about the desk.
Why not measure tickets closed per agent?
Because it is the metric most reliably gamed, and it is not built in for that reason. An agent optimising for closures closes things that are not fixed, avoids hard tickets and stops helping colleagues with theirs. Reopen rate by category, response times against target, and satisfaction comments give you a truer picture of how a desk is performing, and none of them reward the wrong behaviour.
Do the SLA measures account for working hours?
No. Due times are elapsed wall-clock from ticket creation, so overnight and weekend hours count against a target. This matters when reporting: a desk that looks like it breaches frequently may be meeting every commitment during working hours and losing the count to Saturdays. Convert your working-hours commitments into elapsed time when configuring targets, and factor the gap in when you interpret the breach numbers.
How should we read the satisfaction score?
As a distribution and a set of comments rather than as an average. Response bias means the delighted and the furious answer while the satisfied majority does not, so the mean drifts within a narrow band and tells you very little. Read every low rating individually each month — twenty minutes on the actual sentences reveals more than a year of watching the average move between 4.1 and 4.3.
What does the health score actually mean?
It is a weighted rule combining the breaching share of open work, the number of unassigned tickets and recent satisfaction, with a confidence indicator that reflects how much data is behind it. Treat it as a prompt rather than a verdict: the weights are a judgement about what matters, and on a low-volume desk the score is mostly noise — which is exactly what the confidence figure is telling you. Look at the four underlying numbers before drawing any conclusion from it.
