Average resolution time with reopens and pending tickets

Helpdesk apps, where each customer email becomes a ticket, name it differently. Zendesk keeps two, first and full resolution time. Intercom and HubSpot use time to close, in Intercom’s reporting metrics and HubSpot’s ticket properties. Jira Service Management sets it up as a deadline called time to resolution, one of its default service level agreements. In IT support it is mean time to resolve, or MTTR, and Atlassian’s guide to incident metrics uses that name for fixing an outage.

First solve, last solve and business hours

A customer of a subscription app emails at 9:00 on Monday. At 11:00 the team asks for a screenshot and sets the ticket to pending, which means waiting on the customer. The screenshot arrives at 15:00 on Tuesday. The team fixes the problem and marks the ticket solved at 16:00. On Thursday at 10:00 the customer writes back that it broke again, and the ticket is solved for good at 12:00.

The 75 hours include 28 hours of waiting for a screenshot and 42 hours when the ticket sat solved before the customer wrote back. Zendesk’s article on support metrics says the total includes time when nobody is working on the ticket, such as a pending status. Its recipe takes out pending and on-hold time.

Reports also differ on whether the reopened ticket appears at all. Freshdesk’s resolution time report leaves out a ticket resolved in the period and reopened later. Gorgias leaves it out until it is closed again.

Business hours make the number smaller than the customer’s wait. Help Scout’s article on time to resolution says “a customer still has to wait the full length of time!” Gorgias includes outside business hours.

Why one 30-day ticket calls for the median

One old ticket can swamp a month. Say nine tickets took 2, 3, 4, 5, 6, 6, 8, 9 and 10 hours to resolve, and a tenth took 30 days. The mean is 77 hours. The median, the middle of the ten once sorted, is 6 hours.

Gorgias uses the median for resolution time to limit extreme values, and its own example is “a ticket with a 1-month resolution time”. Zendesk’s recipe suggests the median over the average. Intercom’s reporting help explains how to switch from median to average. Freshdesk’s report and HubSpot’s time to close use the mean.

Median resolution times from Freshworks and Kustomer

Each figure below was read on 19 September 2026 and comes from a vendor measuring its own customers. No study from outside the helpdesk vendors turned up. Zendesk left resolution time out of its 2012 benchmark because it “was all over the map”.

In the 2022 data, software and IT companies took longest, at 39 hours 52 minutes. Retail and ecommerce were quickest, at 23 hours 53 minutes.

Pages that grade resolution times cite no source, and their answers differ by a factor of 200 or more. Medallia’s glossary gives five to seven minutes, and Plecto’s KPI page 24 hours. Fullview’s guide lists Kustomer’s industry figures as resolution times. They are Kustomer’s handle times, the minutes of work. Kustomer’s first resolution times for the same industries run from 9.15 to 106.8 hours.

Bots in Freshdesk’s data and Intercom’s time to close

In Freshdesk’s 2019 benchmark, companies using bots had the same 25-hour resolution time as companies without them. Their first response time was 6 hours shorter.

Intercom’s default figure drops bot-closed conversations. Its time to close counts only conversations a teammate closed, and leaves out those closed by Fin, Intercom’s AI agent, or by a workflow. A second metric, time to close including automation, counts every close.

A question Deacon answers from your documentation is answered in the chat and never becomes a ticket. The ones it hands to you wait in your conversations list, with the visitor’s email address if they left one.

Resolution time against handle time on that ticket

The subscription app’s ticket got its first response 2 hours after the email arrived. Its handle time was 20 minutes of work. Resolution time ran on while the ticket waited, for 15 to 75 hours depending on how it is counted.

The resolution rate counts something else, the share of tickets that get solved. MetricNet’s column counts MTTR in business hours. A desktop fault reported at 4pm on a Friday and fixed at 4pm on Monday took 8 business hours there, against 72 clock hours.