Ticket resolution time is the period from the moment a customer raises an issue to the moment your team marks it resolved. That sounds simple until a case waits three days for an order number, runs across a weekend or comes back a week after closing. Each of these situations changes the result, and teams rarely record how they handled it. That is why two companies reporting the same figure may be measuring very different things.
This guide covers the calendar time of the whole case, not the agent effort spent on a single conversation. You will work through start and end points, pausing for the customer, business hours, median with p90, splitting by category and reopened tickets. At the end you will find a definitions table you can paste into your team standard and apply to every report.
Where measurement starts and ends
The usual starting point is either the customer's first message about the issue or the creation of the ticket. Pick one and stick to it. If an agent creates the ticket a day after a chat, starting the clock at ticket creation hides that day. The customer has been waiting since their first message, so that moment usually reflects their experience better.
The end point is the change to resolved status, not archiving or an automatic close after a period of inactivity. Resolved should mean the outcome was achieved or properly verified. When you may set it is covered in the guide on confirming a resolution before closing. If the team closes cases to improve the number, the metric stops measuring support.
Also decide what happens on a reopen. You can count time to the first resolution or to the last one. The first option rewards quick closing; the second shows how long it really took to reach the outcome. For judging service quality, time to the last resolution fits better, with the reopen count reported alongside it.
Pausing while the case waits on the customer
When the missing piece can only come from the customer, the team cannot move the case forward. Counting that period penalises agents for someone else's pace and distorts comparisons between categories. Yet the customer still has an unsolved problem. The fairest approach is to keep two figures: gross time from start to end, and net time with the customer-waiting periods subtracted.
A pause only makes sense when the request was specific and genuinely blocks the work. A waiting status used to clear a case from view or stop the clock corrupts both figures. How to word the request and when to revisit the case is explained in the guide on waiting for a customer reply. Add one rule to your standard: the pause ends when the customer replies, even if the reply is incomplete.
The Jira Service Management documentation shows a condition that pauses the SLA clock, for example on a waiting-for-customer status, along with a working-hours calendar. It describes how one tool can be configured, not a rule every team must adopt: Atlassian, setting up SLAs.
Business hours or calendar hours
A case raised on Friday at 4:30 pm and resolved on Monday at 10:00 am takes more than 65 calendar hours. For a team working 9 am to 5 pm on weekdays, it is an hour and a half of working time. Both figures are true, but they answer different questions. Business hours show how the team uses the time it is available. Calendar hours show how long the customer lived with the problem.
For targets and week-to-week comparisons, use business hours with a recorded schedule and time zone. When your opening hours change, note the date, otherwise a drop in the result may come from a shorter day rather than worse service. Show calendar time alongside for categories where customers genuinely lose money or access. Turning this into a commitment to customers is covered in the guide on customer support SLAs.
Median and p90 instead of the average
Resolution times have a long tail: most cases finish quickly, a few drag on for weeks. The average reacts to that tail so strongly that one case can shift a whole month. The median tells you how long a typical case takes, and p90 shows how long the slowest ten percent of customers waited. The same logic appears in the guide on first response time in chat; for resolution the tail is usually even longer.
Scroll the table sideways to see all columns.
| Measure | Result | What it tells you |
|---|---|---|
| Average | 14.1 h | Inflated by two long cases |
| Median (p50) | 5.5 h | A typical case this week |
| p90 | 30 h | The time one in ten customers exceeded |
The data is fictional: ten tickets from a bike accessories shop, resolved in 2, 3, 3, 4, 5, 6, 8, 10, 30 and 70 business hours. The median is the mean of the fifth and sixth values, and p90 uses the nearest-rank method, so it is the ninth of ten values. With a sample this small every case moves the result, so always show the number of resolved tickets next to the percentiles. When the median falls while p90 rises, the team is most likely closing easy cases faster and putting hard ones off.
Case categories and reopened tickets
An invoice question and a damaged-goods complaint should not share one pool. If complaints rise in a given month, the combined median goes up even though the team works exactly as before. Calculate median and p90 separately for a few main categories and treat the combined figure as background. Keep categories stable for the whole year, or period comparisons lose their meaning.
A reopen after resolution signals that the fix may have been only apparent: a workaround instead of a repair, instructions without checking the outcome, or a close when nobody replied. A team with short resolution times and a growing reopen count has not sped up; it has pushed work into the future. Review a handful of these cases every month. Common causes of repeat contacts are covered in the guide on repeat support tickets.
Zendesk distinguishes time to first resolution from time to the most recent resolution, both measured from ticket creation, and separately totals the time a ticket spent in the pending status. These are one vendor's definitions, not a shared industry standard: Zendesk, Support time duration metrics.
A definitions table for your team standard
Copy the table below into the document where your team keeps its support rules. Fill in the last column with your own decisions and revisit it whenever the process changes. If the report goes to a manager or business partner, attach this table with the date the definition last changed.
Scroll the table sideways to see all columns.
| Element | Suggested rule | Your decision |
|---|---|---|
| Start | Customer's first message about the issue | Fill in |
| End | Most recent change to resolved | Fill in |
| Pause | Only after a specific request to the customer | Fill in |
| Time basis | Business hours, schedule and time zone | Fill in |
| Measures | Median, p90 and case count | Fill in |
| Split | Separately for main categories | Fill in |
| Quality check | Reopen count next to time | Fill in |
In Meetlead analytics, the service report shows resolution time, measured from ticket creation to the most recent resolution, as p50 and p90 with the sample size, plus the number of tickets reopened in the period. The SLA policy stores first response and resolution targets, a weekly schedule and a time zone, and with business hours the report counts time against that schedule. Tickets have a waiting-for-customer status, and a customer message reopens a resolved case. The report does not subtract customer-waiting time, though, so you calculate net time manually for a sample of cases from the ticket event history, which records every status change. For the monthly summary, see the guide on customer service reports.
Questions about resolution time
What is a good ticket resolution time? No single figure fits every industry and case category. Start with your own median and p90 from the last quarter, calculated with your written definition. Set the target per category and check that meeting it does not push up the reopen count.
Doesn't pausing for the customer hide long waits? It can, if you only report net time. That is why you show both figures and check how many cases went through a waiting period at all. If that share grows, look at your team's first replies: they may be asking for details that could have been collected straight away or found in the conversation history.
