Sign in

Blog · Board and management reporting · Customer service

Average Resolution Time KPI: Formula and Example

Average resolution time divides total elapsed resolution hours by resolved cases. Calculate it from a support export, compare issue types and prove the company figure with a weighted check.

The short answerThe average resolution time KPI is the total elapsed time from case creation to the defined resolution event, divided by the number of resolved cases. Use one clock and reporting population throughout. Show open-case aging separately, and compare issue types before interpreting a change: a higher share of complex cases can increase the average without slower work.

The average resolution time KPI is total elapsed resolution time divided by resolved cases. Define the start, resolution event and clock before calculating it; otherwise two teams can report different numbers for the same service history.

Use the average to find changes in customer waiting, then inspect the issue types and open cases behind it. Elapsed resolution time includes waiting and is not the same as agent handling effort.

The formula and the measurement choices

Case resolution time = Defined resolution timestamp − Case creation timestamp

Average resolution time = Total resolution time of eligible resolved cases / Number of those cases

Use a consistent unit, such as hours. Calendar elapsed time includes nights and weekends. Business-hours time counts only the agreed service calendar and requires the relevant schedule and holidays. Neither is automatically correct for every report.

Also choose the resolution event. A case may be marked solved, reopened and solved again. The native support duration definitions distinguish first resolution from the most recent resolution; those events answer different questions. This example uses the latest resolution as of a stated cutoff, for cases currently resolved at that cutoff.

Choose the reporting cohort separately from the duration. A resolved-in-period report includes eligible cases whose defined resolution falls in the period, even if they were created earlier. A created-in-period report follows arrivals and needs a clear observation cutoff because some have not resolved yet.

The KPI glossary covers how to select a measure against an objective. Here the objective is understanding elapsed customer waiting, with separate views of issue type and outstanding work.

The support export rows you need

Keep one row per case with case ID, owning team, issue type, creation timestamp, defined resolution timestamp, current status and reporting cutoff. Retain any reopen information needed to confirm which event is being used. Remove duplicate case records before adding durations.

Assign ownership consistently. The team that resolves a case may differ from the team that first received it. A report grouped by final team measures a different population from one grouped by original team, so record which assignment rule you use.

For a calendar-hours calculation in Excel, put case ID in A, team in B, creation in C and resolution in D. With recognized date-time values, E2 is:

=IF(OR(C2="",D2="",D2<C2),"",(D2-C2)*24)

Fill down. The guard leaves missing timestamps and negative intervals blank for review rather than treating them as completed zero-hour cases. Keep the rejected records in a separate check list and explain their exclusion; a blank result is not a repaired timestamp.

A worked example from a US support team

The following illustrative cases were resolved from October 20 through October 23, 2026. Every timestamp uses UTC, every case remains resolved at the October 23 cutoff, and the clock is calendar elapsed hours. The issue type also defines the team grouping in this small example.

Case Team and issue type Created, 2026 (UTC) Latest resolution, 2026 (UTC) Resolution hours
T201 Billing Oct 20, 09:00 Oct 20, 11:00 2
T202 Billing Oct 20, 10:00 Oct 20, 16:00 6
T203 Billing Oct 21, 09:00 Oct 21, 13:00 4
T204 Billing Oct 21, 10:00 Oct 21, 18:00 8
T205 Technical Oct 20, 09:00 Oct 21, 09:00 24
T206 Technical Oct 21, 08:00 Oct 23, 08:00 48
Total 6 cases 92

The total duration is 2 + 6 + 4 + 8 + 24 + 48 = 92 hours. Divide by six resolved cases: 92 / 6 = 15.33 hours, rounded to two decimal places.

=SUM(E2:E7)/COUNT(E2:E7)

This is the arithmetic mean. The AVERAGE function documentation explains the same sum-over-count calculation and confirms that empty referenced cells are ignored while zeros are included. A missing resolution date must therefore remain missing, not become a numeric zero.

The sorted durations are 2, 4, 6, 8, 24 and 48 hours. Their median is (6 + 8) / 2 = 7 hours. The difference between mean and median points to the longer technical cases; it does not make either statistic wrong.

The check: group totals must rebuild the overall average

Group the same rows by team and issue type. Keep the duration total and case count beside each average so the rollup can be rebuilt.

Team and issue type Resolution hours Resolved cases Average hours
Billing 20 4 5.00
Technical 72 2 36.00
Total 92 6 15.33

The duration check is 20 + 72 = 92 hours. The population check is 4 + 2 = 6 cases. The weighted average must equal the result from the individual rows:

Weighted average = (5 × 4 + 36 × 2) / (4 + 2) = 92 / 6 = 15.33 hours

The simple average of the team averages would be (5 + 36) / 2 = 20.50 hours. It overweights the smaller technical group. Carry counts through every team, issue-type and monthly rollup, then divide the summed durations by the summed counts.

What the result should change

The service lead owns the operational review. The reporting owner maintains the clock and cohort definition, while team leads review the underlying cases and their causes. Compare billing with billing over time and technical cases with comparable technical cases before making a staffing judgment.

A shorter resolved-case average can coexist with an older open backlog. Review outstanding case ages alongside it, using the support backlog recovery guide when the question becomes capacity. Do not estimate handling capacity by dividing working hours by elapsed resolution time.

Likewise, an average below a contractual limit does not prove individual cases met their commitments. Use SLA attainment per account for that comparison. Track the first response time KPI separately when the immediate concern is how long customers wait for acknowledgment.

Where it goes wrong

  • Open cases recorded as zero. They have an age, but no completed resolution duration. Keep their aging visible outside the resolved average.
  • First and latest resolution mixed. Reopened cases make the distinction material. Use the same event definition and cutoff throughout.
  • Calendar time compared with business hours. Label the clock and apply the right service calendar before comparing results.
  • Group averages averaged equally. Rebuild the total from duration sums and case counts, as the weighted check demonstrates.
  • Changing case mix read as slower service. Separate team, severity and issue type. A shift toward longer cases can move the total even when comparable work is unchanged.

Covirage is not affiliated with Zendesk or Microsoft.

Calculate resolution time on your own export

Bring a case export with the timestamps, team, issue type and status: Covirage maps the columns, and its tools compute and check the durations and grouped averages. The external AI model explains the results with every figure traced to its rows. Create a free Covirage account and bring a sample of your own data; creating the account takes about a minute.

See self-service analytics for the supporting approach to analyzing your business files.

Questions people ask

What is a good average resolution time?

Use the service commitment and the history of comparable cases as your reference. Separate issue type, severity and service calendar. A single universal target ignores differences in work and can reward teams for closing simple cases while complex work remains open.

Do unresolved tickets belong in average resolution time?

They do not have a completed resolution duration. Keep them outside a resolved-case average and report their current age separately. Otherwise the resolved average can look better while unresolved work grows older and the customer experience deteriorates.

How should reopened cases be measured?

Choose the event that matches the question. First resolution measures the first solved event; latest resolution measures the most recent solved event as of the reporting cutoff. State the choice, retain the reopen history and apply it consistently across teams.