Of all the numbers a support team watches, time to resolution is the one customers feel most. A fast first reply is reassuring, but it isn't the thing they actually wanted — they wanted the problem to go away. Resolution time measures the distance between "I have a problem" and "my problem is solved," and it is the single best proxy for whether your support is genuinely helping or just politely acknowledging. It is also one of the easiest metrics to measure dishonestly, which is why so many teams report a resolution time that looks great and means nothing.
What you're actually measuring
Time to resolution is the elapsed time from when a ticket is created to when it is genuinely resolved. Two definitions hide inside that sentence, and getting them wrong is how the number starts lying.
- Resolved, not closed. A ticket is resolved the moment the customer's problem is fixed — not when an automation auto-closes it three days later for inactivity. If your tool measures to the close event, you're inflating the number with idle waiting time.
- First resolution, not final. If a ticket gets reopened, the honest move is to track both the time to first resolution and how often that resolution didn't hold. A low resolution time paired with a high reopen rate isn't speed; it's premature closing wearing a costume.
Decide these definitions once, write them down, and make sure everyone reporting the number means the same thing by it. Half of all "our resolution time went up" panics are really "someone changed the definition."
Stop averaging — the mean hides the pain
The average resolution time is almost always a comforting lie. A queue where most tickets close in an hour but a stubborn 10% drag on for a week will report a cheerful-looking average while a meaningful slice of your customers suffer. Report the median for the typical experience and a high percentile — the 90th or 95th — for the tail. The tail is where churn lives. A customer whose ticket sat for nine days does not care that your average was four hours.
This is the same discipline that makes first response time trustworthy, and the same reason the broader support metrics that matter should almost never be a single mean on a dashboard.
Subtract the time that isn't yours
Some of a ticket's lifespan is genuinely outside your control — the hours it sits in "waiting on customer" while the requester finds their order number, or the time parked with engineering on an escalation. If you count that against your team, you're measuring the customer's response speed and the world's, not your performance. Track resolution time with those paused states subtracted so the number reflects work your team could actually have done faster. The same business-hours and pause logic that keeps SLA compliance fair applies here.
The levers that actually move it
Once you measure resolution time honestly, the ways to shrink it are concrete:
- Resolve more on first contact. Every ticket your front line closes without a handoff skips the slowest part of the lifecycle. First contact resolution is the most direct lever on resolution time there is.
- Route it right the first time. A ticket bouncing between the wrong agents accumulates dead time. Tight routing and assignment rules get it to someone who can solve it before the clock runs.
- Arm agents for the hard cases. The long tail is usually a handful of complex problem types. Runbooks and good canned responses let a newer agent resolve them at expert speed instead of escalating.
- Deflect the slow-but-simple. Some questions are fast to answer but waste a full ticket lifecycle; moving them to self-service removes them from the resolution-time math entirely.
The honest test
Your resolution time is real when the median is dropping and the reopen rate is flat or falling — meaning you're solving problems faster without solving them worse. If the number improves while reopens climb, you haven't gotten faster; you've just started closing tickets before they were done. Measure to genuine resolution, watch the tail, and the metric becomes a true map of how much your support actually helps.