Issue resolution time
Issue resolution time is the average elapsed time between a customer raising an issue and that issue being fully resolved. It captures the whole journey, not just the first reply, so it reflects how quickly your team actually fixes problems. Tracking it tells you whether support is keeping pace with demand and where work stalls.
7 min read
What is issue resolution time?
Issue resolution time is the average elapsed time between a customer raising an issue and that issue being fully resolved. If a ticket is opened at 9am on Monday and closed at 9am on Wednesday, that issue took 48 hours to resolve. Average those durations across every resolved ticket and you have the metric.
It differs from first response time, which only measures how long until someone replies. Resolution time covers the whole arc: triage, investigation, the fix, and confirmation that the problem is gone. A team can reply in minutes and still take days to resolve, so the two numbers tell different stories and you need both.
Definition note
Issue resolution time should measure time to genuine resolution, not time to first close. If a ticket is closed and then reopened because the problem persisted, the clock should continue. Counting a premature close as resolved hides the real cost of unsolved issues and flatters the number.
How to calculate issue resolution time
To calculate issue resolution time, sum the resolution duration of every issue closed in the period, then divide by the number of issues resolved. The result is an average, usually expressed in hours or business hours.
Many teams report the median alongside the mean. A handful of multi-week edge cases can drag the average up and make a healthy queue look slow, so the median often describes the typical customer experience more honestly. Decide upfront whether you count calendar time or business hours, because a ticket opened on Friday evening will look very different under each.
- 1
Issue created timestamp
The moment the customer raised the ticket, not when an agent first saw it.
- 2
Issue resolved timestamp
The moment the issue was confirmed fixed, with reopens extending the clock.
- 3
Business hours adjustment
Optionally subtract time outside working hours so overnight gaps do not inflate the figure.
- 4
Resolved issue count
The number of tickets that reached genuine resolution in the period you are measuring.
Issue resolution time in a metric tree
Issue resolution time is an outcome, not a lever. You cannot pull it directly, so the useful move is to decompose it into the stages a ticket passes through and the factors that slow each stage down. A metric tree does exactly that, breaking the headline duration into queue wait, investigation, and handling time, then breaking each of those into their own drivers.
When you see the tree, the bottleneck becomes obvious. If queue wait dominates, the problem is staffing or routing, not engineer speed. KPI Tree lets you assign RACI ownership on each branch, so the team responsible for routing sees their node and the team handling escalations sees theirs. When the number moves, the platform pushes to the accountable owner rather than leaving the regression buried in a dashboard nobody opens.
Metric tree insight
A rising average rarely comes from agents working slower. More often a single branch, such as engineering handoff speed or routing accuracy, has shifted. The tree isolates which branch moved so you intervene where the time actually accrues instead of asking the whole team to go faster.
Issue resolution time benchmarks
Resolution time benchmarks vary widely by channel and complexity, so treat these as orientation rather than targets. A live chat product question and a technical bug in an enterprise integration belong on completely different scales. The figures below describe typical full resolution windows for B2B SaaS support, measured in business hours.
| Tier | Typical resolution time | What it signals |
|---|---|---|
| Excellent | Under 8 business hours | Same-day resolution, strong tooling and routing |
| Good | 8 to 24 business hours | Most issues closed within a working day |
| Average | 24 to 72 business hours | Workable but with visible queue or handoff drag |
| Needs attention | Over 72 business hours | Backlog building, likely staffing or escalation gaps |
How to improve issue resolution time
The fastest way to lower resolution time is to attack the largest branch in the tree, not to push the whole team to hurry. Find where the hours accrue, then remove the specific friction. The cards below map to the most common bottlenecks.
Sharpen routing
Send each ticket to the right specialist first time. Misroutes add a full queue wait before real work even begins.
Build the knowledge base
Document recurring fixes so agents resolve known issues immediately instead of re-investigating from scratch.
Cut handoff delay
Tighten the escalation path to engineering. Slow handoffs are often the single biggest contributor to long tails.
Improve reproduction context
Capture environment, logs, and steps at ticket creation so investigation starts with what it needs.
Common mistakes when tracking issue resolution time
- 1
Counting first close as resolved
If reopened tickets are not tracked, premature closes make the average look better than reality.
- 2
Reporting only the mean
A few extreme cases distort the average. Pair it with the median to describe the typical experience.
- 3
Mixing calendar and business hours
Comparing teams on different clocks produces meaningless gaps. Pick one definition and apply it everywhere.
- 4
Optimising the number over the outcome
Closing tickets fast to hit a target invites reopens. Track resolution quality alongside speed.
Related metrics
First response time
Customer Support Metrics
Metric Definition
FRT = Total First Response Times / Total Tickets With a First Response
First response time measures the elapsed time between a customer creating a support ticket and receiving the first substantive response from a human agent. It is the metric that shapes the customer's initial impression of the support experience and sets the tone for the entire interaction.
Average resolution time
Customer Support Metrics
Metric Definition
Average Resolution Time = Total Resolution Time Across All Tickets / Total Tickets Resolved
Average resolution time measures the mean elapsed time from when a support ticket is created to when it is fully resolved and closed. It captures the end-to-end customer experience of getting an issue fixed, encompassing wait times, agent work time, escalations, and any back-and-forth exchanges required to reach a solution.
Escalation rate
Customer Support MetricsMetric Definition
Escalation Rate = (Escalated Tickets / Total Tickets Handled) x 100
Escalation rate measures the percentage of support tickets that are transferred from one tier or team to a higher tier or specialist group for resolution. It reflects the gap between the issues customers raise and the ability of frontline agents to resolve them, making it a key indicator of agent readiness, process maturity, and product complexity.
Ticket volume
Customer Support MetricsMetric Definition
Ticket Volume = Total New Tickets Created in Period
Ticket volume is the total number of new support tickets created within a defined period. It is the fundamental demand metric for support operations, determining staffing requirements, budget allocation, and the urgency of self-service and product quality investments.
Metric decomposition
Metric Definition
Break issue resolution time into its underlying drivers so you can see which stages of the resolution process are slowing it down.
Metric trees for operations teams
Metric Definition
See how operations teams place issue resolution time alongside related throughput and quality metrics in a connected tree.
Build issue resolution time as a metric tree
Decompose resolution time into queue wait, investigation, and handoff, then put a RACI owner on every branch. When the number slips, KPI Tree pushes to the accountable owner and verifies whether the fix actually moved it.
