Resolution time

Resolution time is the total elapsed time from when a ticket is created to when it is fully resolved. For a single ticket it is simply the resolved timestamp minus the created timestamp. Across many tickets it is usually reported as an average or, more reliably, as a set of percentiles such as P50 and P90. A customer who reports a problem on Monday morning and gets confirmation it is fixed on Wednesday afternoon experienced a resolution time of just over two days.

The metric matters because it represents the customer total wait for a solution, not just the active work. It is distinct from first response time, which only measures how long until someone replied. A team can respond in minutes and still take days to resolve, so the two metrics answer different questions and both belong on a support dashboard.

Resolution time is also a capacity signal. Longer resolution times mean more tickets stay open at once, which raises ticket volume in the queue, increases context switching, and can become self-reinforcing as the backlog grows. A small increase in resolution time can have an outsized effect on how many tickets are open on any given day.

The average hides as much as it shows. A team that resolves 90 percent of tickets in two hours but lets 10 percent run for five days can report a respectable average while a meaningful group of customers has a poor experience. Percentiles expose this. The median tells you the typical case and the P90 tells you how bad the tail gets, and the gap between them is often where the real problem lives.

There is also a choice between calendar time and business hours. If your team does not work around the clock, calendar time penalises overnight and weekend gaps the team cannot control. Business-hours measurement isolates genuine working efficiency and is the fairer basis for targets when support is not staffed continuously.

For each ticket, subtract the created timestamp from the resolved timestamp to get its resolution time. To summarise a period, take the average across all tickets resolved, and ideally compute the median and P90 alongside it. Decide up front whether you are measuring in calendar time or business hours, and whether time spent waiting on the customer counts.

The inputs below define the metric. Each choice changes the number, so document them and apply them the same way every period so the figure stays comparable.

1. 1

   Capture created and resolved timestamps

   Record when the ticket was opened and when it was marked resolved. Decide whether the clock starts at ticket creation or at the customer first message, and apply that rule consistently.

2. 2

   Choose calendar time or business hours

   Calendar time reflects the customer actual wait. Business hours measure team efficiency without penalising nights and weekends. Pick one per report and never blend them.

3. 3

   Decide how to treat customer wait time

   Choose whether to include time the ticket sat in a waiting-on-customer status. Excluding it isolates team performance, including it reflects the full customer experience.

4. 4

   Summarise with average and percentiles

   Compute the average for the headline, but report the median and P90 too. The percentiles reveal whether a small group of slow tickets is dragging the experience down.

Resolution time is the sum of every wait and every working period across a ticket life. That makes it a natural fit for a metric tree, which breaks the total into phases and shows where the time is actually being spent. A high resolution time always traces to a specific phase, and each phase has a different owner and a different fix.

Resolution time benchmarks depend heavily on priority and context. A critical outage and a minor feature question should never be measured against the same target. The ranges below are typical for each context, but the most important rule is to segment by priority before comparing, because a blended figure is neither accurate for urgent issues nor meaningful for routine ones.

Reducing resolution time means shortening the phase that dominates it, which is why the tree comes first. The cards below cover the moves that most reliably bring the number down, from resolving more issues on first contact to keeping the slow tail under control.

1. 1

   Reporting only the average

   A single mean lets a worsening slow tail hide behind a steady headline. Always pair the average with the median and P90.

2. 2

   Blending priorities into one number

   Mixing critical and low-priority tickets produces a target that fits neither. Segment by priority before comparing or setting goals.

3. 3

   Using calendar time for a part-time team

   Counting overnight and weekend hours when the team is not working makes efficiency look worse than it is. Measure in business hours when support is not continuous.

4. 4

   Confusing resolution time with response time

   A fast first reply does not mean a fast fix. Track first response time and resolution time separately, because they have different drivers and different owners.