Time to Resolution
Definition
Time to Resolution
Time to resolution is the elapsed time between a customer reporting an issue and that issue being genuinely fixed. It is the customer’s clock, not the agent’s, and it runs through every queue, handover, and overnight gap along the way.
Handling time is a different measure entirely — an issue can take eleven minutes of work spread across four days.
Averages flatter this metric more than most. One outlier resolved in three weeks barely moves a mean built from hundreds of same day fixes.
Percentiles tell the honest story — the 90th percentile describes the experience of the customers who suffered most.
Clock rules need writing down first. Whether the timer pauses while you wait for the customer changes the reported figure enormously.
Key takeaways
- Time to resolution measures elapsed time from report to verified fix.
- It counts waiting, not just working, which is why it dwarfs handling time.
- Report the median and the 90th percentile, never the mean alone.
- Clock pause rules belong in the definition before the first report is published.
How it works
Start the clock when the issue is reported, stop it when the fix is confirmed, then summarise across the period using median and percentile figures. Decide in advance whether the timer runs on a calendar basis or only during agreed business hours.
Pauses are the most contested rule. Stopping the clock while awaiting a customer reply is standard, and stopping it while awaiting a third party rarely is.
| Rule | Options | Common practice |
|---|---|---|
| Clock basis | Calendar or business hours | Business hours for standard, calendar for critical |
| Pause on customer | Yes or no | Yes, with pause duration reported separately |
| Pause on third party | Yes or no | No, since the customer still waits |
| Summary statistic | Mean, median, percentile | Median plus 90th percentile |
Statistical practice supports the percentile habit. The NIST/SEMATECH engineering statistics handbook records Walter A. Shewhart developing control charts in the 1920s, using three sigma limits to separate ordinary variation from a real shift.
Service design frames why the wait matters. Digital.gov describes customer experience as the sum of the public’s interactions with a service, which makes elapsed waiting part of the product.
Segment by severity before comparing anything. A single blended figure across critical outages and cosmetic bugs describes neither of them.
Watch the handover count as well as the clock. Tickets crossing three or more teams dominate the long tail in almost every operation, and each handover adds waiting nobody is measuring.
Examples
Resolution clocks diverge most where handovers, third party dependencies, and business hour rules pile up on top of each other. Four cases from service desks and field operations show what a single average hides.
A Philippine IT service desk. Median resolution ran at 4.2 hours while the 90th percentile sat at 61 hours. The long tail was entirely tickets needing a third party licence.
A SaaS support team. Switching from calendar to business hours cut reported resolution by 38% overnight — a definition change with no operational improvement behind it.
A field maintenance operator. Pausing the clock during parts delivery hid an average nine day supply delay. Reporting the pause separately exposed it.
A banking contact centre. Severity one incidents resolved in 90 minutes and severity three in nine days. The blended average of two days described no real ticket.
Related terms
Resolution time sits alongside the other clocks in a support operation and the escalation paths that stop the worst cases running away. The terms below cover them.
- Resolution Time: the closely related contact centre measure.
- First Contact Resolution: the stricter test of a single interaction.
- Escalation: the route that shortens the long tail.
- Support Ticket: the object the clock is attached to.
- Service Level Agreement (SLA): the contract that sets the target time.
- Queue Time: the waiting portion of the elapsed total.
- Helpdesk Technician: the role working the ticket through.
FAQ
What is a good time to resolution?
It depends entirely on severity. Critical incidents are usually targeted in hours, standard requests in one to three business days.
Should the mean or the median be reported?
The median, plus the 90th percentile. Means are dragged around by a handful of very long cases.
When should the clock pause?
While waiting on the customer, and only then. Third party delays still leave the customer waiting.
How does it differ from handle time?
Handle time counts the work. Time to resolution counts everything the customer waited through, including queues and overnight gaps.
Why did the figure improve without any change?
Check for a definition change. Moving from calendar hours to business hours produces an instant improvement that is not real.
Should it be segmented?
Always, by severity and by request type. One blended number describes no actual ticket.
Find support delivery partners in the Outsource Accelerator BPO hubs.
Independent
