Case resolution time

Case resolution time is the total elapsed time from when a support case is opened to when it is fully resolved and closed. If a case opens on Monday at 9am and resolves on Wednesday at 9am, the resolution time is 48 hours. It captures the whole journey to a fix, not the speed of the first response.

The metric matters because it is what the customer actually feels. A fast first reply is welcome, but the case is not over until the problem is solved. Resolution time exposes the difference between a team that answers quickly and a team that finishes quickly. It also drives cost, since cases that drag on consume more handling and more follow-up.

For a single case, resolution time is simply the close timestamp minus the open timestamp. For a team or period, you average that duration across every resolved case. Because a few very long cases can drag the average up, the median is often the more honest summary of the typical experience.

The inputs are easy to define but easy to corrupt. Reopened cases, cases auto-closed for inactivity, and time spent waiting on the customer all distort the figure if you do not handle them deliberately. Pin down those rules before you trust the number.

1. 1

   Case open timestamp

   Record when each case was created. This is the start of the clock for that case.

2. 2

   Case close timestamp

   Record when the case was marked resolved. Exclude cases reopened later unless you count the reopened span too.

3. 3

   Per-case duration

   Subtract open from close. Decide whether to use elapsed time or working hours and whether to pause the clock during customer waits.

4. 4

   Average or median across cases

   Sum the durations and divide by the number of resolved cases, or take the median to reduce the pull of outliers.

An average resolution time of 22 hours tells you where you are but not why. Decomposing it into a metric tree reveals where the hours actually go: waiting for first contact, sitting in a queue, bouncing between teams on escalation, or stalled waiting on the customer. Total resolution time is the sum of the time spent in each stage of a case.

This is precisely the gap between a dashboard and a decision. KPI Tree breaks resolution time into the stages that make it up, assigns RACI ownership so the front-line, escalation, and engineering teams each own their branch, and pushes an alert to the accountable owner when their stage slows. When resolution time climbs, you see whether the cause is a backed-up queue, a slow handoff, or a class of cases that keeps reopening, and the verified impact loop checks whether the fix you made actually shortened the number.

Resolution time benchmarks vary enormously by case complexity, channel, and whether you measure elapsed or working time. A billing query and a deep technical bug do not belong in the same average. Use these ranges as a rough orientation for working-hours resolution on standard cases, and always segment by case type before drawing conclusions.

Cutting resolution time means finding where the hours hide and removing them without closing cases prematurely. The biggest wins usually come from routing cases correctly the first time, equipping agents to resolve more without escalating, and tightening the handoffs that quietly add days. Each change should be checked against reopen rate so speed does not come at the cost of a real fix.

1. 1

   Confusing it with first response time

   A fast first reply does not mean a fast fix. Resolution time measures the whole journey, not the opening move.

2. 2

   Counting customer wait time

   Time spent waiting on the customer is not agent time. Including it punishes teams for delays they do not control.

3. 3

   Letting outliers set the average

   A handful of week-long cases can pull the mean far from the typical experience. Report the median alongside it.

4. 4

   Ignoring premature closures

   Closing cases early to lower the number just shifts the cost to reopens. Always read resolution time next to reopen rate.