What Time to Resolution Measures
Time to resolution is the elapsed time from a ticket being raised to the underlying issue being fixed. It is measured end to end, not by how long anyone worked on it. That distinction is the whole point for an MSP: internal effort is invisible to the client, elapsed time is not. A ticket that sat waiting on a vendor for two days is two days of the client's problem, however little of it was yours. The mean time to resolve KPI page covers the calculation.
Choosing How to Measure It
Two choices change the number more than any improvement on the desk will:
- Which tickets you include. Measure against tickets raised in the period, not only tickets closed. Excluding the ones still open flatters the average precisely when things are going badly.
- Whether the clock pauses. Many PSAs let a ticket pause while waiting on the client. That is reasonable when the client genuinely owes you something, and dishonest when it is used to hide a stalled ticket.
Report the median alongside the mean. One ticket that stayed open for a month will distort an average across hundreds of password resets, and the median shows what a typical client actually experienced. Split by priority too, because a combined figure hides whether outages are being fixed quickly.
Why Owners Should Watch It
For an MSP, a rising TTR is usually an early warning rather than a desk problem on its own. It tends to show one of these:
| Pattern | Likely Cause |
|---|---|
| Rising across all clients | The desk has more volume than technicians |
| Rising for one client | An environment that was never properly documented or standardized |
| Rising on escalated tickets only | Senior technicians are overloaded or pulled onto projects |
| Rising while hands-on time is flat | Tickets are waiting, not being worked |
Compare it with average hands-on time per ticket. When elapsed time grows and hands-on time does not, the gap is queue time, and queue time is a scheduling and capacity problem you can size with the staffing calculator.
Why It Rarely Belongs in a Contract
TTR is the number the client feels, but it depends on things you do not control: vendor fixes, parts delivery and the client's own staff being available. Committing to resolution times in an SLA is how an agreement becomes unmeetable in exactly the situations it was written for. Most MSPs promise response times contractually, track TTR internally, and discuss it openly with clients at the QBR, where the context can be explained.
Common Questions
Is TTR the same as MTTR?
Close enough in everyday use. MTTR is the mean of time to resolution across tickets, while TTR can refer to a single ticket or to the metric in general.
Should we pause TTR while waiting on the client?
Only when the client owes you a specific answer or action, and the pause should be visible in the ticket history. Pausing for vendor waits hides a real delay the client still feels.
Does a reopened ticket reset TTR?
It should extend the original ticket's resolution time rather than start a new clock. Otherwise a fix that did not hold looks like two fast resolutions.