What is average resolution time?
Average resolution time is the mean elapsed time between a support ticket being created and that same ticket being fully resolved, measured across every case closed in a reporting period. It is usually reported in hours for consumer channels and in business days for B2B queues.
Targets vary sharply by sector. E-commerce teams often aim to close tickets inside 24 hours, B2B SaaS queues commonly run two to five business days, and fintech and healthcare sit between the two because identity checks and compliance reviews add mandatory steps.
How average resolution time is calculated
The formula is a single division: total resolution time across all tickets closed in the period, divided by the number of tickets closed. Everything difficult about the metric sits in three upstream decisions: what starts the clock, what stops it, and which tickets are eligible to count.
Take a queue that closed 400 tickets in a week, accumulating 3,600 hours of open time. The average is 9 hours. Remove the 20 tickets that each sat for 100 hours awaiting a vendor reply, and the remaining 380 tickets account for 1,600 hours, an average of about 4.2 hours. Same week, same team, two very different stories.
The clock start is normally ticket creation, which is why this number and first response time drift apart on queues that reply fast and close slowly. Every transfer adds fresh queue time, so escalation rate is usually the strongest structural driver of the average. And a ticket reopened two days later was never resolved, so resolution rate has to be read beside it.
What counts and what does not
Calendar hours versus business hours: A ticket opened Friday evening accrues sixty weekend hours on a calendar clock and none on a business clock, which moves the average more than most process fixes.
Pending and on-hold time: Waiting on a customer reply or a third-party vendor is still time the customer experiences, though many teams pause the clock and should say so in the definition.
Reopened tickets: A reopen either restarts the original ticket's clock or spawns a new record, and that choice quietly decides whether slow fixes stay visible.
Bulk and automatic closures: Auto-closing stale tickets at day thirty injects either a mass of very long durations or a mass of instant ones, depending on how the closure is stamped.
Merged conversations: When an email thread and a chat about the same issue merge, one of the two creation timestamps disappears from the calculation entirely.
Average resolution time vs first response time vs average handling time vs resolution rate
Support dashboards show these four side by side, and teams regularly improve one while believing they moved another. First response time measures how fast someone replies, so it flatters queues where nothing ever closes. Average handling time measures labour inside a single contact, so it ignores every hour a ticket waits. Resolution rate measures how many cases close at all, so it stays flat whether closure took an hour or a fortnight. Average resolution time measures the customer's wait from problem to fix, the promise a support team actually makes.
What it counts | What it misses | Typical benchmark | |
|---|---|---|---|
Average resolution time | Total elapsed time from ticket creation to closure | Effort, cost, and whether the fix held | Set internally; e-commerce often targets under a day, B2B SaaS two to five business days |
First response time | Wait until the first human or AI reply | Everything that happens after that reply | Minutes on chat, hours on email, by internal policy |
Average handling time | Agent time talking, holding, and wrapping up | Queue time, waiting time, follow-up work | Varies by channel and case complexity; no published standard |
Resolution rate | Share of cases fully closed without escalation or reopen | How long any of it took | Set internally against contact mix |
If you are answering to a customer, average resolution time is the number they feel. If you are staffing a team, average handling time is the one that prices it, and resolution rate tells you whether either figure was earned.
Why average resolution time matters for customer experience
Customers absorb a slow first reply far better than a slow fix. A reply signals that someone is present; only a resolution ends the problem, and tickets that drag past roughly 48 hours are disproportionately likely to finish as a refund request or a cancelled account.
When nobody watches the average, the damage stays invisible in aggregate. The queue looks healthy because most tickets close quickly, while a long tail of complex cases sits for weeks, and those cases usually belong to the highest-value accounts, because complex accounts generate complex problems.
The tradeoff is real. Push the average down hard enough and agents begin closing tickets that were never finished, which relocates the work into reopens and second contacts where it is harder to see. A team that cut its average from three days to one while doubling its reopen rate made service worse.
What is a good average resolution time?
No standards body publishes a resolution-time target, so the honest comparison set is your own history, your contractual commitments, and the pace your customers already expect from your sector.
The nearest defensible external anchor is satisfaction data. The American Customer Satisfaction Index scores US sectors on a 100-point scale, and industry results generally land between the high 60s and the low 80s, which makes it a usable check on whether faster resolution is actually reaching customers. If your resolution time falls while your satisfaction position holds flat against that spread, the speed is not landing.
Read the average against three companions: the median, which shows the typical case; the ninetieth percentile, which shows the worst experience you routinely ship; and the distribution shape, which tells you whether one queue or one issue type is producing the tail. Mature teams publish all four, the average included.
How AI agents change average resolution time
An AI agent changes the shape of the distribution before it changes the mean. Tickets that used to wait for a human to become free are answered on arrival, so the entire class of simple, high-volume cases collapses to seconds and pulls the average down sharply in the first weeks of deployment.
The second-order effect matters more. Once automation absorbs password resets, order status and refund eligibility, what remains in the human queue is the hard residue: multi-system investigations, exceptions, and cases needing a policy decision. The human team's own average resolution time therefore rises, and reading that rise as a regression is a common misdiagnosis.
Routing is where the two effects meet, since a layer that classifies and enriches a ticket before a person opens it removes the diagnosis time, which ticket routing and resolution-time analytics treats as its own measurable stage.
What to look for when implementing resolution-time tracking
Coverage comes first: a tool that times email tickets but cannot time a chat, a call, or a case that moved between channels will report an average for part of your operation and label it the whole.
Integration surface decides where the clock can stop. If a refund is issued in a billing system, resolution is only timestamped honestly when the helpdesk can see that event, which is also what makes SLA compliance rate trustworthy.
Governance is ownership of the definition. One named person holds the clock rules and every change is dated, because regulated buyers ask how a reported figure was produced and whether the definition shifted mid-period. SOC 2 Type II and GDPR are the frameworks raised most in that conversation, usually around evidencing controls and around how long ticket contents are kept.
The constraint teams underestimate is that redefining the stop-clock invalidates the trend line, so any move from calendar hours to business hours needs a dual-reporting period.
Average resolution time and support workload planning
Average resolution time and ticket volume move together in ways that make either one misleading alone: a volume spike lengthens queue time and inflates the average without anyone working slower, so a staffing model reads both or neither.
Channel mix does the same. Resolution on live chat is often measured in minutes because the customer is present, while the same issue by email may take a day of asynchronous exchanges, so a shift toward chat lowers the blended average for reasons unrelated to capability. Automation reporting hits the same problem, which is why deflection and resolution reporting are worth separating.
What does average resolution time mean in plain terms?
Think of average resolution time as the answer to one customer question: from the moment I told you something was broken, how long until it was actually fixed.
A counterfactual makes it concrete. Imagine a shop that replies to every message within two minutes and takes nine days to ship a replacement part. Its reply metrics look outstanding, its customers are furious, and only the resolution clock explains the gap.
The tradeoff you accept is that an average hides people. Twenty customers helped within an hour and one left waiting a fortnight still average out to well under a day, and the one who waited is the one who writes the review. That is why this number gets read with its median and its slowest tenth attached.
Common average resolution time mistakes
Reporting the mean without its distribution is the first and most common. A handful of tickets stuck behind a vendor or a legal review can move a weekly average by hours, and the team then investigates a slowdown that never happened in the cases customers experienced.
Pausing the clock generously is the second. Every hour subtracted as pending time widens the gap between the reported figure and the wait the customer felt, until the metric describes internal effort while the customer describes something else.
Benchmarking against another company's number is the third. Two teams with different start events, business calendars and reopen rules are measuring different quantities, so the comparison yields a target with no mechanism attached to it.
Treating the average as one lever is the fourth. It aggregates routing accuracy, knowledge availability, escalation depth and staffing against volume, so moving it means choosing which of those four to work on.
What is the formula for average resolution time?
The formula for average resolution time is total resolution time for all tickets closed in a period, divided by the number of tickets closed. Total resolution time sums each ticket's elapsed time from creation to closure. Whether that elapsed time uses calendar hours or business hours has to be fixed before you report anything.
What is the difference between average resolution time and average handling time?
Average resolution time measures the customer's total wait from ticket creation to closure, including every hour a case spent sitting in a queue. Average handling time measures only agent labour inside a contact: talk, hold, and after-call work. The first is an experience measure, the second a staffing and cost measure.
Average resolution time vs first response time: which one matters more?
Average resolution time and first response time answer different questions. First response time shows whether anyone acknowledged the customer, which protects perceived responsiveness in the opening minutes. Average resolution time shows whether the problem ended. Fast replies followed by slow fixes produce excellent response figures and poor retention, so most teams treat resolution as the outcome measure.
What is a good average resolution time for a SaaS company?
A good average resolution time depends on sector and channel. Consumer e-commerce teams commonly target closure inside a day, B2B software queues often run two to five business days, and regulated sectors sit between because verification and compliance steps add fixed delay. Your own trailing median is a more useful target than any published figure.
Should the clock pause while a ticket waits on the customer?
Average resolution time can pause its clock while a ticket waits on a customer or a vendor, and teams split on whether it should. Stopping the clock isolates internal performance; leaving it running reflects the wait the customer actually felt. Either is defensible, provided the definition is published and stays stable across quarters.
Why did our average resolution time increase after deploying AI agents?
Average resolution time often rises for human teams after AI agents are deployed, and that movement is usually expected. Automation absorbs the fast, repetitive cases, leaving the human queue holding complex investigations and exceptions that always took longer. Track the blended figure across both populations, plus the change in case mix, before calling it a decline.