Resolution time is how long a customer waits for an issue to be solved: from their first message about it, on any channel, until the outcome is recorded, such as the order cancelled, the address changed or the refund submitted. Measure it for each request type, as a median and a 90th percentile in calendar hours, because an average across all tickets hides the customers who waited longest.
It's also called time to resolution. This guide is about customer service; mean time to resolution (MTTR) in IT operations measures recovery from incidents, which is a different job.
In short
- Count issues, not tickets, and stop the clock when the outcome is recorded in the system that owns it.
- Five choices change the number: ticket or issue, first or final resolution, business or calendar hours, what may pause the clock, and average or median.
- Set targets per request type from your own median and 90th percentile; published benchmarks rarely say how they were measured.
- Most of the time is waiting, not working. AI shortens it when it completes the change in the conversation, not when it only answers.
Resolution time vs other time metrics
| Metric | Clock starts | Clock stops | What it tells you |
|---|---|---|---|
| Resolution time | The customer's first message about the issue | The outcome is recorded: order cancelled, refund submitted, replacement created | How long the customer waited for the problem to be solved |
| First response time | The customer's first message | The first reply that addresses the request | How long before anyone engaged with it |
| Average handle time | An agent starts working the conversation or call | The agent finishes, including wrap-up | Agent effort, for staffing |
| First contact resolution | Not a time | Not a time | The share of issues solved in the first contact and never raised again |
Of the customer service metrics a consumer brand reviews weekly, resolution time is the closest to what the customer experiences. First response time can look fast because of an instant acknowledgement, and average handle time counts agent minutes, not the customer's wait. A short resolution time with many repeat contacts means issues were closed, not solved, which first contact resolution checks.
Five choices that change the number
Helpdesks disagree by default: Zendesk's full resolution time report shows the median in calendar hours, while Front's resolution time counts business hours and shifts. Make these five choices, write them down and keep them.
1. Per ticket or per issue. A customer who messages on Instagram, then emails, then calls about one damaged order has one issue and, in many helpdesks, three tickets: three short waits in the report, one long one in her life. Count per issue, grouping contacts by customer, order and request type from the first contact on any channel. Keeping one issue on one ticket across channels is what omnichannel customer service does for your reporting.
2. First or final resolution. Zendesk's metric definitions separate first resolution time (created to first solved) from full resolution time (created to latest solved). Several guides advise excluding reopened tickets. Don't: a reopened issue belongs to a customer who waited longer than most. Report the final resolution, with the reopen rate beside it.
3. Business or calendar hours. Business hours show how fast the team works on shift. Calendar hours show what the customer waited: a message sent at 9pm on Friday and resolved at 11am on Monday is a 62-hour wait, even if it took two business hours. Make calendar hours the headline and use business hours for staffing; the gap between them shows what 24/7 customer support would change.
4. Where the clock stops, and what may pause it. Stop it when the outcome is recorded in the system that owns it: the cancellation in the store, the refund submitted to the payment provider, the replacement order created. Not when an agent writes "we've raised it with the warehouse", and not when the bank credits the money, which is its own step. Time waiting on the customer for a photo or an address can be reported separately, because the customer controls it. Time waiting on your warehouse, courier or finance team can't be paused: the customer is still waiting, and even Zendesk's requester wait time includes on-hold time.
5. Average, median or percentile. A few slow cases drag the average up. The median is the typical customer's wait; the 90th percentile is how long your slowest tenth waited, which is where complaints come from. Read both next to the customer satisfaction metrics for the same request type, so a fast resolution that left the customer unhappy doesn't pass as a good one.
Flowcall's AI Helpdesk makes the first choice easier to keep. When the same customer writes on another channel while their issue is open, Flowcall keeps it on the same ticket, with the whole history visible, while a new issue or a different order gets a ticket of its own. Counting per issue then starts from tickets that already match the issues.
How to calculate resolution time
For each resolved issue, resolution time is when the outcome was recorded minus when the customer first messaged about it. For each request type, take the median (the middle value), the 90th percentile (the time within which 90% were resolved) and, if older reports need it, the average. Suppose ten refund requests last week took 2, 3, 3, 4, 5, 6, 8, 20, 30 and 71 hours:
| Measure | Result | What it says |
|---|---|---|
| Average | 15.2 hours | Longer than seven of the ten customers waited |
| Median | 5.5 hours | The typical customer's wait |
| 90th percentile | 30 hours | Nine in ten were resolved within this; one waited 71 |
Spreadsheet percentile functions interpolate and may differ slightly, so pick one method. Below about 20 issues of a type, read the cases instead. A customer service dashboard can do the arithmetic once you know which of the five choices it makes.
Resolution time for each request type
An overall figure mixes one-minute order-status answers with week-long damaged-item claims, so it moves whenever the mix moves. Split it by request type. The clock always starts at the customer's first message about that order and request; where it stops differs.
| Request type | Resolved when | What usually adds time | Track as a separate step |
|---|---|---|---|
| Order status ("where is my order?") | The customer has the current status and expected date from the courier's latest scan | Looking the order up in the store and the courier portal | A parcel stuck at one scan, raised with the courier as its own issue |
| Cancellation | The order is cancelled in the store or order-management system, with the refund submitted if it was prepaid | Checking whether it has been packed; waiting for the warehouse to pull it | Refund submitted to money credited |
| Address change | The new address is on the order before dispatch, or the customer has been told it's too late and given the options | Collecting the full address; checking the courier serves the new postcode | None |
| Return or exchange | The pickup is booked or the exchange order created | Reasons and photos collected over several messages; eligibility checks | Pickup booked to parcel collected |
| Refund | The refund is submitted to the original payment method or as store credit, and the reference sent | Waiting for the return to reach the warehouse; approval above a value limit | Refund submitted to money credited |
| Damaged or wrong item | A replacement, refund or repair is created and confirmed to the customer | Photos; a stock or quality check by the warehouse; approval | Replacement shipped to delivered |
One damaged order, two clocks
A customer's blender arrives with a cracked jar. At 8:10pm on Friday she sends a DM on Instagram. At 10am on Saturday the social team asks her to email photos and closes the Instagram ticket. She emails them at 1:30pm. The email team works weekdays, 9 to 6; at 11am on Monday an agent asks the warehouse whether a replacement jar is in stock. The warehouse replies at 4pm on Tuesday, and the agent creates the replacement order and solves the ticket.
| What the ticket report shows | What the customer lived | |
|---|---|---|
| Count | Two tickets | One issue |
| Resolution time | 14 hours (Instagram, closed without a resolution) and 74.5 calendar hours, or 16 business hours (email) | 92 calendar hours |
| Where the time went | Not visible | 14 hours to the first reply; 3.5 hours waiting on her photos; 45.5 hours in the email queue over the weekend; 29 hours waiting on the warehouse; about 20 minutes of work |
The ticket report isn't wrong; it answers a different question. And working faster wouldn't have helped much: 20 minutes of work sat inside 92 hours of waiting.
What a realistic target looks like
There is no reliable industry figure to borrow, because published numbers rarely say what they measured. One contact-center glossary gives "five to seven minutes", which only fits issues solved within a single call. Freshworks' 2025 benchmark report, from its customers' 2024 data, gives an average of 36 hours for service tickets at companies not using AI: an average across industries and ticket types, and the published summary doesn't say how business hours or reopened tickets were treated. Gorgias's April 2026 research on its ecommerce merchants uses medians and still found resolution time varying 1.5 times across 14 verticals. Even within ecommerce, what you sell matters.
Some deadlines are firmer, because the law sets them. They are ceilings for particular requests, not targets:
| Where | Rule | Deadline |
|---|---|---|
| European Union | Consumer Rights Directive 2011/83/EU, Article 13 | Refund within 14 days of being told the customer is withdrawing from an online purchase; the trader may wait until the goods are back or proof of return is supplied |
| United States | FTC Mail, Internet, or Telephone Order Merchandise Rule, 16 CFR 435 | When an order is cancelled because it can't ship on time, a refund within seven working days, or one billing cycle for credit card orders |
| India | Consumer Protection (E-Commerce) Rules, 2020, rule 4(5) | A grievance officer acknowledges a consumer complaint within 48 hours and redresses it within one month |
Complaints need a process as well as a clock; see how to handle customer complaints. To set your own target:
- Take eight to twelve weeks of each request type, measured with your five choices.
- Record the median and the 90th percentile in calendar hours.
- Set the promise from the 90th percentile, so nine in ten issues already meet it. State it in terms the customer understands ("refunds submitted within one working day of your return reaching us"), tell customers what it is, and tighten it as the 90th percentile falls.
- Track the share of issues resolved within the promise each week, and read every one that missed it.
In Flowcall, SLA policies set resolution targets for each team or workflow, with timers that follow your business hours and holidays or run around the clock. You see which tickets are at risk of missing their target, the people you choose are alerted before the breach, and breached tickets move up the queue, so an issue heading past your promise gets attention while there's still time to keep it, not only in the weekly read.
Where the hours go: a 20-conversation audit
Before trying to reduce resolution time, find out where it goes. Take 20 resolved issues of one request type from last month, including the five slowest, and split each one's time into these segments:
| Segment | Typical causes in a consumer brand |
|---|---|
| Waiting for the first reply | A backlog; weekends; a channel nobody watches in the evening |
| Waiting on the customer | Asking for the order number, then photos, then the reason, one message at a time |
| Waiting on another team | A warehouse stock check, a finance approval, a handoff from the bot or between tiers |
| Waiting on a third party | A courier investigation, the payment gateway, a marketplace or an outside vendor |
| Working | Reading, looking up the order, deciding and acting |
As in the damaged-order example, working is often the smallest segment. Start with the largest waiting segment, not with agent speed.
How to reduce resolution time
Waiting for the first reply. Route by request type, so a refund reaches someone who can issue refunds; automated ticket routing does this by rule. Cover the evenings on the channels customers use then.
Waiting on the customer. Ask for everything in one message. The order can usually be found from the phone number or email the customer wrote from, so don't ask for it. Ask for photos and the reason together, use a form for addresses, and send a reminder when the customer goes quiet instead of closing the ticket.
Waiting on another team. Replace email chains with an internal task that has an owner and a deadline, so the warehouse or finance step is visible and the customer's issue stays open until it's done. Write rules for common exceptions, so fewer cases wait for approval. Let agents act in the store, courier and payment systems from the ticket, so fewer issues pass between customer service tiers. When a handoff is needed, it should carry the order and what has been tried; see escalation management.
In Flowcall's AI Helpdesk, that internal task is a child ticket: the warehouse, finance or logistics step gets its own assignee, and the customer's ticket stays open and owned until every child ticket is done. For the steps agents can take themselves, Customer 360 puts the customer's orders, delivery, payments and refunds on the ticket. Agents process a refund, create a replacement or update an order from the ticket, with the form prefilled from the conversation.
Waiting on a third party. You can't make a courier investigate faster, but you can chase on a schedule, tell the customer the next date and report that wait as its own segment.
Reopened issues. Read them weekly. Each is an answer or a rule that didn't hold.
Auto-closing quiet tickets, excluding reopened ones and closing tickets with "we've raised it" improve the report and leave the customer waiting just as long.
How AI changes resolution time
AI changes resolution time only when it ends the clock in the conversation. Whether it can depends on the request.
- Answers. An AI agent that tells a customer where the order is, from the courier's latest scan, resolves an order-status request in the conversation; order tracking automation covers where that data comes from. One that replies with the cancellation policy has only answered: the request becomes a ticket, and the clock runs until an agent cancels the order.
- Actions. When the AI can check the order and make the change under your rules, the request is resolved in the conversation. That covers cancellations before dispatch, address changes, return pickups and refunds within a value limit (see returns management): customer service automation that completes requests rather than replying to them.
- Handoffs. Exceptions, high-value refunds and damaged items that need judgement still need a human agent. The AI shortens these by collecting the order, photos and reason first and handing over with a summary.
We built Flowcall's AI Agent to end the clock in the conversation wherever your rules allow. It follows your workflows for cancellations, returns, exchanges, refunds and damaged products, checks current order, delivery and payment data, and completes the change when the rules pass: in Shopify natively, and in other order-management systems through their APIs. It collects addresses and photos in WhatsApp and Live Chat forms, and when the customer goes quiet, it sends reminders and picks the workflow up where it left off. When a human agent is needed, it creates a ticket with the conversation, a summary, the order details and what's left to do.
This changes how you read the numbers. Start the clock at the customer's first message, not the handoff, and measure handoff to first human reply separately. Report AI-resolved and human-resolved issues separately for each request type: as the AI takes the quick requests, the human queue's median will rise because its mix got harder, not because the team slowed down. And a conversation that ended because the customer stopped replying is abandoned, not resolved; check resolved ones for a repeat contact about the same order within seven days, on any channel.
AI doesn't change the courier's or the bank's timeline. A fast resolution can also be wrong, such as a refund the policy didn't allow; reading the conversations, which AI quality assurance does, shows that.
How Flowcall helps reduce resolution time
Most of a resolution is waiting, so we built Flowcall around the waits you can shorten. The AI Agent ends the clock in the conversation where your rules allow it, and it can email an outside vendor and continue the workflow when they reply. The AI Helpdesk keeps a customer's open issue on one ticket across channels, with back-office steps visible and a resolution target running. Flowcall's dashboards show resolution time by agent and channel as a median and 75th to 99th percentiles, which includes the 90th percentile this guide recommends. They sit next to the AI automation rate and CSAT, with CSAT split by AI and human, so a faster resolution can be read against how customers rated it.
To see this in practice, book a demo and we'll walk through one request type, from the customer's first message to the outcome recorded in the store. Qualifying brands get a free proof of concept on the service problem they most need solved, built with their team and tested before anything goes live.
Frequently Asked Questions
What is resolution time in customer service?
Resolution time is the time from a customer's first message about an issue to the outcome being recorded: the order cancelled, the refund submitted or the replacement created. It's also called time to resolution. First response time is different: it stops at the first useful reply.
How do you calculate average resolution time?
Add up the resolution times of all issues resolved in a period and divide by the number of issues. Because a few slow cases pull the average up, report the median and the 90th percentile beside it, split by request type.
What is a good resolution time?
There's no reliable cross-industry figure, because published benchmarks rarely say whether they're averages or medians, in business or calendar hours, per ticket or per issue. Start from your own median and 90th percentile for each request type, stay inside legal deadlines such as the EU's 14-day refund rule, and set a promise customers can see.
What does expected resolution time mean?
It's the time you tell a customer to expect before their issue is solved, usually set by a service level agreement (SLA) or stated in an acknowledgement ("we'll resolve this within two working days"). The share of issues resolved within it shows whether the promise holds.
