Average resolution time (also called mean time to resolution, or MTTR) is the average time it takes to fully solve a customer issue, measured from when the ticket is opened to when it is resolved. You calculate it as the total resolution time across all solved tickets divided by the number of tickets resolved. It is not the same as first response time, which only measures how long the customer waited for a first reply. Resolution time measures whether the problem actually got fixed, and for standard B2B tickets in 2026 a common target is one business day, with 4 to 8 hours for high-priority issues.
Speed of first reply gets most of the attention, but customers care about two clocks, not one. The first is how long until someone answers. The second, and the one that decides whether they walk away satisfied, is how long until the problem is actually gone. Average resolution time is the second clock. A team can have a fast first response and still leave customers waiting days for a fix, and resolution time is the metric that catches that gap. This guide covers what resolution time measures, how to calculate it, what a good number looks like in 2026, how it differs from first response time, and how to bring it down without the shortcut that ruins it: closing tickets before the customer's problem is truly solved.
What is average resolution time?
Average resolution time is the mean duration between a ticket being opened and that ticket being resolved, across all the tickets your team closed in a period. Some teams call it mean time to resolution or MTTR, a term borrowed from IT operations; in a customer support context they mean the same thing. The metric captures the customer's full wait for an outcome, not just the wait for acknowledgment. That is what makes it different from and complementary to first response time. A customer who gets a friendly reply in two minutes but waits four days for the actual fix has experienced a two-minute response time and a four-day resolution time, and only the second number reflects how the experience actually felt.
Because resolution time spans the entire life of a ticket, it is shaped by more than agent speed. Routing, escalation paths, how often a ticket bounces between teams, whether engineering or billing has to get involved, and how clearly the issue was captured up front all feed into it. That makes resolution time one of the best diagnostic metrics in support, because a high number usually points at a broken handoff or a bottleneck rather than a slow agent.
How do you calculate average resolution time?
The formula is a simple average. Add up the resolution time of every ticket you closed, then divide by the number of tickets.
Average resolution time = total resolution time of all resolved tickets / number of resolved tickets.
Say your team resolved 5 tickets today with resolution times of 2, 4, 6, 3, and 5 hours. The total is 20 hours, divided by 5 tickets, for an average resolution time of 4 hours.
| Input | Value |
|---|---|
| Total resolution time (5 tickets) | 20 hours |
| Number of resolved tickets | 5 |
| Average resolution time | 4 hours |
Two measurement decisions matter as much as the formula. First, measure in business hours, not calendar hours, or a ticket opened Friday at 5pm and solved Monday at 9am will look like a 64-hour failure when your team was closed the whole time. Second, decide how you handle waiting-on-customer time. If a ticket sits idle because you are waiting for the customer to reply, that delay is not yours, and mature help desks let you pause the clock during customer-pending status so the metric reflects your team's actual work rather than the customer's response speed. And because a handful of ugly, long-running tickets can drag the average way up, always look at the median alongside the mean. The median tells you the typical experience; the gap between the two tells you how bad your worst cases are.
What is a good average resolution time?
There is no single good resolution time, because it depends on channel, complexity, and priority, but 2026 benchmarks give you useful anchors. For standard B2B SaaS tickets, resolving within one business day is a common target, with high-priority issues expected in 4 to 8 hours. For ecommerce, the bar is faster: same-day or even same-session resolution on chat, and 24 to 48 hours for email. Teams using AI assistance are pulling overall resolution times well down, often under 15 hours on average versus 30 or more for teams without it.
| Context | Typical 2026 resolution target |
|---|---|
| Ecommerce, live chat | Same session to same day |
| Ecommerce, email | 24 to 48 hours |
| B2B SaaS, standard ticket | Within one business day |
| B2B SaaS, high priority | 4 to 8 hours |
| Complex, multi-team issues | Set by tiered SLA, often 2 to 5 days |
The right move is to set resolution targets by priority tier inside your service level agreement rather than chasing one blanket number. A password reset and a data-integrity bug should never share a resolution target. Tiered targets keep the metric fair and keep your team focused on getting the urgent things fixed fast without pretending a complex issue can be closed in an hour.
Average resolution time versus first response time
These two metrics measure different halves of the same experience, and you need both. First response time measures how long the customer waited for any reply; average resolution time measures how long they waited for the fix. A fast first response sets the tone and tells the customer they were heard, which is why surveys consistently show customers rank response speed highly. But a fast response with a slow resolution wears thin quickly, because acknowledgment is not a solution. The failure mode to watch for is a team that optimizes first response time in isolation, sending quick "we are looking into it" replies that make the FRT dashboard green while resolution time quietly balloons. Track them side by side. First response time protects the start of the experience; resolution time protects the outcome, and only the outcome decides whether the customer stays.
How do you reduce average resolution time?
Because resolution time spans the whole ticket, the biggest wins come from fixing the process around the ticket, not from asking agents to type faster. These are the levers with the most impact.
1. Fix your slowest handoffs. Most long resolution times are handoff times in disguise: a ticket waiting in a queue, sitting with the wrong team, or stalled while it bounces to engineering and back. Map where your longest tickets actually spend their hours, and you will usually find one or two handoffs eating most of the clock. Fixing those specific escalation paths moves resolution time more than any other single change.
2. Resolve more issues on the first contact. Every issue solved in one interaction has a short resolution time by definition, so raising first contact resolution pulls average resolution time down directly. Give agents the knowledge and authority to finish issues without escalating, and the long tail of multi-touch tickets shrinks.
3. Prioritize and triage on the way in. A tiered priority scheme with a clear escalation matrix means urgent issues get worked immediately instead of waiting behind routine ones. Good triage does not just speed up the important tickets; it keeps the average honest by making sure nothing critical sits in a general queue.
4. Arm agents with knowledge and macros. A strong internal knowledge base and well-built canned responses cut the research and typing time on every ticket, and they keep answers consistent so a customer does not come back with a follow-up that reopens the case.
5. Attack your repeat-offender ticket types. Find the categories that consistently take longest to resolve and treat the root cause. If a particular integration failure always takes three days because it needs a specialist, a documented runbook or a product fix removes those hours permanently.
6. Pause the clock honestly on customer-pending tickets. Make sure your help desk stops counting time while you are legitimately waiting on the customer, so your metric measures your team's speed and not the customer's. This is accuracy, not gaming, as long as the pause is genuinely for customer-pending status and not a way to hide your own delays.
Making average resolution time a metric you can trust
Average resolution time is the metric that keeps a support operation honest about outcomes, because it measures the thing the customer is actually waiting for: a solved problem, not a fast hello. Measure it in business hours, report the median alongside the mean so a few outliers do not distort the picture, and set targets by priority tier inside your SLA rather than a single blanket number. Read it next to first response time so a quick reply never disguises a slow fix, and next to first contact resolution, which is often the fastest way to bring resolution time down. Kept in that context inside your core support metrics, resolution time becomes a diagnostic that points straight at the bottlenecks slowing your customer experience operation, rather than one more number on a dashboard nobody acts on.