Time to resolution (TTR) measures the interval from a defined issue-start event to a defined resolution event. In a helpdesk report, that commonly means ticket creation to the chosen solved event. It describes the issue’s lifecycle, while first response time describes the wait for an initial reply.
Before trying to reduce TTR, decide what the report actually measures. Calendar time, business hours and a status-based clock that pauses are different intervals. First resolution, latest resolution and confirmed customer completion are also different endpoints.
This guide explains the clocks, calculations and reporting cohorts, then shows how to investigate delays without rewarding premature closure.
What time to resolution includes
A customer’s issue can pass through intake, initial response, investigation, specialist work, waiting and verification. Calendar elapsed time includes those intervals even when nobody is actively working on the case.
| Event or interval | Record | Avoid assuming |
|---|---|---|
| Issue start | Report receipt or ticket creation, explicitly chosen | Ticket creation is always the first moment the customer reported it |
| First response | First qualifying reply under defined channel rules | A reply resolved the issue |
| Investigation and collaboration | Relevant actions, results and owners | Time in an open status equals active work |
| Waiting | Customer, specialist or external dependency, with timestamps | Every wait was outside the team’s influence |
| Resolution | Chosen event and outcome evidence | A solved status independently proves the task succeeded |
If the earlier report timestamp is available and important, measure receipt-to-resolution separately. If you have only ticket creation, use that label; do not estimate missing history. Keep administrative closure and the customer’s outcome distinguishable.
Choose the endpoint: first, latest or verified resolution
First resolution ends when the case first reaches the specified solved event. Latest resolution ends at the most recent such event available at the reporting cutoff. Reopening can make those results substantially different.
Zendesk’s metric reference distinguishes first resolution from full resolution to the latest solved event, including calendar and business-hours variants. Read the selected metric’s definition rather than treating “full” as proof that a customer confirmed success.
For a customer-outcome measure, specify the required confirmation or observable task result and how its time is recorded. Cases awaiting confirmation remain a separate population unless the agreed rules establish another outcome. A workaround can restore a task while a linked product defect remains open; choose which outcome this report is meant to describe.
Do not combine first resolution for some cases with latest or customer-confirmed resolution for others. Label any deliberately different populations.
Calendar, business-hours and paused clocks
Calendar elapsed time
Calculate the chosen end timestamp minus the start timestamp. Include nights, weekends and customer waiting. This view describes elapsed experience even when the team provides support only during business hours.
Business-hours time
Count the portion of that interval falling inside a specified support schedule. Document time zone, working days, holidays and how daylight-saving changes are handled. The result is time within the schedule, not active agent effort.
You can report business hours for the service commitment and calendar time for the customer’s elapsed experience. A team does not have to choose one and hide the other.
Status-based or SLA time
A paused clock excludes intervals defined by a policy, such as particular pending states. State the start, stop, pause and reopen rules. Do not call this unqualified elapsed TTR.
Zendesk’s SLA documentation gives examples of different rules: requester wait time pauses in Pending, while total resolution time includes Pending and treats time in Solved as a pause if the case reopens. Native full resolution and an SLA clock are not interchangeable.
“Pause while waiting for the customer” is therefore not a universal TTR rule. Keep the excluded duration visible and inspect why it occurred. Unclear instructions or repeated requests for information can create customer waiting even when the status is correctly recorded.
An illustrative clock example
A case starts Friday at 16:00 and reaches its chosen resolution event Monday at 10:00. Assume the same time zone, no holiday or clock change, and a Monday–Friday 09:00–17:00 schedule. It is pending from Friday 16:30 to Monday 09:30.
| Clock | Calculation | Result |
|---|---|---|
| Calendar elapsed | Friday 16:00 to Monday 10:00 | 66 hours |
| Business-hours interval | Friday 16:00–17:00 plus Monday 09:00–10:00 | 2 hours |
| Local business-hours clock excluding pending | 2 scheduled hours minus 1 pending hour within that schedule | 1 hour |
The third result is an illustrative local rule, not a universal vendor default. None of these numbers tells you the agent’s active work time, and the one-hour result does not mean the customer waited only one hour.
Calculate a mean and show the distribution
Mean TTR = sum of included resolution intervals ÷ number of included intervals. Keep units, endpoints and clock consistent. For three illustrative cases taking 4, 8 and 12 hours, the mean is 24 ÷ 3 = 8 hours.
A mean can hide a long tail. In another illustrative set, intervals of 1, 2, 2, 3 and 32 hours also average 8 hours, but the median is 2 hours. Show sample size, a median and, when useful, a percentile with its calculation method stated. Small samples can produce unstable tail estimates.
Break down comparable issue types, priority, channel and dependencies. A team handling more difficult cases may have a higher overall mean without becoming slower within each category.
Choose the reporting cohort and cutoff
A resolved-in-period cohort includes cases whose chosen resolution event occurred during the period under the report’s rules. It can contain old cases and omit new cases that remain unresolved. Clearing old work may raise its mean even when the backlog improves.
A created-in-period cohort follows cases that started during the period. At a cutoff, some may remain unresolved. Do not silently remove them and present the resolved subset as the outcome of the whole cohort.
For an illustrative created cohort of 20 cases, 12 have reached the chosen resolution event by the cutoff and 8 remain unresolved. Completion by the cutoff is 12 ÷ 20 × 100 = 60%. The mean among the 12 resolved cases is a conditional result; report it alongside the 8 unresolved cases and their ages.
State whether a case reopened before the cutoff remains eligible for a resolved report. Preserve the cutoff or snapshot needed to reproduce the result. A “latest solved” timestamp can change after subsequent work, so a live rerun may differ from an earlier report.
Set a useful baseline before choosing a target
Compare representative periods under the same definitions. Check volume, issue mix, incomplete records and changes to status or routing rules. Use the service commitment and business impact to choose an objective; do not adopt an unexplained SaaS or e-commerce average.
Pair TTR with outstanding age, reopenings, validated outcomes and customer feedback. It does not directly measure customer effort, trust or agent labor cost. A short interval can still contain an ineffective answer, and a long elapsed interval can include substantial waiting rather than paid active work.
For the broader portfolio, see key support metrics. Keep individual performance conclusions proportional to assignment complexity and authority.
Reduce delays by improving the actual lifecycle
- Improve intake: capture the goal, actual behavior and relevant context so the next action is clear. Ask for needed evidence without sending every customer a lengthy questionnaire.
- Make applicable knowledge findable: maintain instructions with conditions, versions and an owner. The Consortium’s structured problem-solving guidance recommends understanding and searching before diagnosis.
- Route by the required skill or authority: tiered support can be useful, but avoid forcing a clearly specialist issue through unnecessary transfers. Preserve the history and accepting owner.
- Make internal dependencies visible: use a shared case or linked work item with a decision request, evidence and update commitment. A collaboration channel should have an owner and expectations.
- Verify the proposed outcome: test the relevant task or obtain appropriate confirmation. Do not lower the reported duration by closing before the outcome check.
Use the ticket escalation process for accepted handoffs and the problem-resolution method for the whole customer conversation.
Use technology where evidence is missing
A recording, image or call can help clarify a screen-based issue when words leave an important ambiguity. Choose the format around the task, customer preference and appropriate data scope; visual evidence does not automatically establish a cause.
Screendesk describes browser recording links and video calls integrated with helpdesks. Its product documentation also makes technical capture conditional on the relevant setup and supported plan. Do not assume any recording automatically contains all browser logs or that screen sharing provides remote control.
For example, an explicitly illustrative case could use a recording to show which export step fails, then give a specialist that context in the ticket. Measure whether the revised workflow reduces repeat evidence requests or comparable resolution intervals. Do not assume a guaranteed minutes-versus-hours result.
For self-service, evaluate whether customers complete the task, not just whether they viewed an article. Keep current instructions and a route to support when the answer does not apply.
Common questions about time to resolution
Is TTR the same as first response time?
No. First response ends at a qualifying initial reply; TTR ends at the chosen resolution event. Define both clocks and inspect unanswered or unresolved cases beside completed averages.
Should a small team use business hours?
Use the documented schedule where it matches the service commitment, and keep calendar elapsed experience available. Team size does not determine the correct clock.
Should pending time be excluded?
Only from an explicitly defined paused measure. Calendar elapsed time includes it. Show excluded durations separately and inspect whether the wait reflects a necessary dependency or avoidable friction.
What should we improve first?
Choose the delay supported by case evidence: unclear intake, knowledge gaps, routing, approval or verification. Give the change an owner and check comparable outcomes after implementation, including unresolved work and quality.
