The moment a customer asks for help, a clock starts. It only stops when they get a complete answer. This total wait time is known as time to resolution. It is a vital metric that directly impacts customer loyalty and agent efficiency.
Simply tracking the hours is not enough, though. Many teams make costly mistakes by prioritizing speed over actual problem-solving. You need the right context to see where you truly stand.
In this blog, we’ll break down what time to resolution really means. We will also cover the exact formula, current channel benchmarks, and how to avoid common tracking mistakes.
What is time to resolution?
Time to resolution (TTR) is the average time between a customer opening a support request and that request being marked resolved. It’s also called mean time to resolution (MTTR), average resolution time, or full resolution time. The name changes depending on which help desk or reporting tool your team uses.
TTR covers the entire lifecycle of a ticket, not just the first reply. A conversation might get an instant acknowledgment but still take three days to actually fix. That ticket still counts as a three-day resolution. A fast first response and a fast resolution are two different wins. Teams that only track one often misread how their support is performing.
A lower TTR generally signals a more efficient support process. But the number only means something once you know what it’s being measured against. That’s why benchmarks and clear definitions matter more than the raw figure alone.
Time to resolution vs. First response time vs. First contact resolution
These three metrics get confused constantly. They all describe speed, but each one answers a different question. Mixing them up in a report can make a team look faster or slower than it actually is.
| Metric | What it measures | When it counts as “done” |
|---|---|---|
| Time to resolution (TTR) | Total time from ticket opened to ticket resolved | When the issue is fully fixed and closed |
| First response time (FRT) | Time from ticket opened to first human reply | When the customer gets any reply, even if unresolved |
| First contact resolution (FCR) | Whether the issue got solved in a single interaction | When no follow-up contact was needed |
A team can post an excellent FRT and a poor TTR at the same time. Answering fast but bouncing a ticket between three departments still produces a long resolution time. The first response looked great on paper. The actual fix took days.
How to calculate time to resolution
The formula is simple. Add up the total resolution time across every resolved ticket in a period. Then divide by the number of tickets resolved in that same period.
Average TTR = Total resolution time for all resolved tickets ÷ Total number of resolved tickets
Here’s a worked example using a small support queue:
- Ticket A took 2 hours to resolve.
- Ticket B took 6 hours to resolve.
- Ticket C took 1 hour to resolve.
- Ticket D took 15 hours to resolve.
- Ticket E took 4 hours to resolve.
Add those five times together: 2 + 6 + 1 + 15 + 4 = 28 hours. Divide by 5 resolved tickets. The average time to resolution is 5.6 hours.
Notice Ticket D. A single 15-hour outlier pulled the average up noticeably. This is why many teams report the median alongside the mean. The median for this set is 4 hours. That’s a more honest picture of what a typical customer actually experiences.
What counts as a good time to resolution?
A “good” TTR depends heavily on channel and ticket priority. A single target number across your whole support operation usually hides more than it reveals.
| Channel or priority | Reasonable target |
|---|---|
| Live chat | Under 10 minutes |
| Standard email inquiry | Under 24 business hours |
| Phone support | Resolved on the call where possible |
| Critical (P1) technical issue | Under 4 hours |
| Standard (P2/P3) technical issue | 24 to 72 hours |
Cross-industry data from Help Scout puts general resolution benchmarks in a similarly wide range. A billing question and a multi-team technical escalation were never going to resolve at the same speed. Set separate targets by ticket type instead of one number for everything.
Why time to resolution matters
Speed shapes how customers judge your entire support experience, not just the individual ticket. According to HubSpot’s customer service research, response time is one of the top three metrics customer service leaders track. It sits right alongside CSAT (customer satisfaction score) and retention, because the three tend to move together in practice.
Forrester’s customer satisfaction benchmark research has consistently linked faster problem resolution to stronger loyalty and repeat business. That connection also shows up in Net Promoter Score data. Customers who wait too long for a fix are far more likely to become detractors than promoters.
TTR has a quieter effect on revenue too. A customer who gets fast, complete resolutions tends to stick around longer. That feeds directly into customer lifetime value. Slow resolutions do the opposite. They erode trust well before a customer ever files a formal complaint.
How to choose the right TTR target for your team
There’s no universal “good” number. Pick a target by weighing what actually shapes your customers’ patience and your team’s capacity.
- Industry and channel.
A live chat customer expects minutes. An email customer will tolerate a day.
- Ticket complexity.
A password reset and a data migration issue shouldn’t share a target.
- Customer segment.
Enterprise or VIP accounts often carry contractual SLAs (service-level agreements setting a maximum allowed resolution time) that require tighter targets than your general queue.
- Team capacity.
A target your staffing can’t realistically hit will just get ignored internally.
Once a target is set, tie it back to outcomes you care about. These customer retention strategies show why speed alone isn’t the goal; keeping the customer is.
Common mistakes when tracking time to resolution
A handful of tracking errors quietly distort what TTR is telling you. They’re easy to miss until a report contradicts what your agents are actually experiencing.
- Reporting the mean without the median.
A few extreme outliers can make an otherwise solid team look slow.
- Treating TTR as the only metric that matters.
A short resolution time paired with a high Customer Effort Score often means the ticket was closed fast but not solved well.
- Ignoring reopened tickets.
If a “resolved” ticket gets reopened days later, the clock should restart. It shouldn’t stay frozen at the original close time.
- Mixing calendar hours and business hours.
Comparing a 24/7 chat channel’s TTR against a 9-to-5 email queue without adjusting for hours produces a meaningless number.
How to reduce time to resolution
Bringing TTR down isn’t about rushing agents. It’s about removing the friction that slows a ticket down before it ever reaches a solution.
- Build out self-service: A solid knowledge base resolves simple, repetitive questions before they become tickets at all, freeing agents for harder cases.
- Fix your triage and routing: Tickets that land with the wrong team add hours before anyone starts working the actual problem.
- Staff to your volume patterns: Track ticket volume by hour and day. Schedule shifts to match, instead of running flat staffing across peaks and lulls.
- Give frontline agents more authority: Every issue that has to escalate for approval adds wait time. Letting tier-one agents resolve more cases outright cuts that dead time out.
- Use your own TTR data to find bottlenecks: Break resolution time down by ticket type and team. You’ll usually find one or two categories dragging the whole average up.
Measuring time to resolution alongside customer satisfaction
TTR tells you how fast an issue got closed. It doesn’t tell you how the customer actually felt about the experience. Pairing it with a satisfaction survey at the moment of resolution closes that gap. A tool like QuestionPro can trigger a short survey right after a ticket closes, so the speed data and the sentiment data land in the same report.
Common channels for this kind of feedback include:
- A post-chat or post-call survey sent immediately after the interaction ends
- A short survey after an automated phone (IVR) resolution
- A feedback link placed in the footer of the resolution email
Following up on the responses matters as much as collecting them. A post-purchase survey works on the same principle. The value isn’t in the score itself. It’s in closing the loop with the customers who flag a problem.
Getting time to resolution right
TTR is one of the clearest signals of whether customers feel like their time is respected. It won’t tell you everything about your support quality on its own. Tracked alongside effort and satisfaction scores, though, it becomes one of the fastest ways to spot where a support process is quietly losing customers. Set targets by channel and priority. Watch the median as closely as the mean. Treat every spike as a bottleneck worth investigating, not a number to explain away.
Frequently Asked Questions (FAQs)
Not automatically. A very low TTR paired with a high reopen rate or low satisfaction score usually means tickets are being closed quickly without being properly solved, which just shifts the frustration to a second contact later.
It depends on whether you’re measuring calendar hours or business hours. Most teams report business hours for internal performance tracking, since it reflects actual working time, but calendar hours better represent what the customer experienced.
AI-assisted triage and suggested-reply tools can shorten TTR by routing tickets faster and giving agents a starting draft, but the gains disappear if the underlying issue still needs manual escalation to get fully resolved.
An SLA is a commitment, often contractual, that sets a maximum allowed resolution time for a given priority level. TTR is the actual measured average your team is delivering against that commitment.
The formula stays the same, but small teams should set shorter measurement windows and simpler priority tiers, since a handful of slow tickets can swing a small sample’s average far more than it would in a high-volume enterprise queue.
