Issue resolution rate

Issue resolution rate is the percentage of issues a team resolves relative to the number received in the same period. If 500 issues arrive in a month and the team resolves 460, the resolution rate is 92 percent. A rate at or above 100 percent means the team is clearing more than it receives and the backlog is shrinking. A rate below 100 percent means the backlog is growing, even if the team feels busy.

The metric is a measure of pace, not quality. It tells you whether capacity matches demand. That makes it the natural top-line number for a queue, but it is also the easiest number to game: a team can lift resolution rate by closing issues prematurely, which is exactly why it should never be read alone. Resolution rate sets the headline and other metrics keep it honest.

Resolution rate pairs naturally with average resolution time. One tells you how much of the incoming work you clear, the other tells you how long each one takes. Together they describe both the volume and the speed of a queue, and a healthy team needs both to hold rather than trading one against the other.

The calculation is a ratio of resolved to received, but the inputs need clear boundaries so the rate stays comparable from one period to the next.

1. 1

   Issues received

   Count every issue that entered the queue in the period. This is the denominator and the measure of demand. Be consistent about whether duplicates and spam are counted, since including them deflates the rate without reflecting real work.

2. 2

   Resolved issues

   Count issues moved to a resolved or closed state in the period. Exclude issues closed without a genuine fix, such as duplicates and withdrawals, so the numerator reflects real resolution rather than queue tidying.

3. 3

   Measurement period

   Fix the window, commonly a week or a month. Resolution rate is volatile over short windows because a single backlog-clearing day distorts it. Longer windows smooth the noise and reveal whether capacity truly matches demand.

4. 4

   Backlog carried in

   Note the open issues carried from earlier periods. When the team resolves carried-in backlog alongside new arrivals, the rate can exceed 100 percent, which is the signal that the queue is shrinking rather than a calculation error.

Worked example: 600 issues arrive in a month and the team resolves 540 of them, drawing some from earlier backlog. The resolution rate is 540 divided by 600, multiplied by 100, which is 90 percent. The 60-issue shortfall means the backlog grew that month. If instead the team had resolved 630 by clearing backlog, the rate would be 105 percent and the backlog would have fallen, which is what sustained recovery looks like.

A metric tree decomposes resolution rate into the forces that set it, then ties each branch to the team that controls that force. This turns a single throughput number into a map of where pace is won or lost.

The first level splits the rate into the two things that determine it: how much arrives and how much the team can clear. Incoming volume decomposes into new issues, reopened issues, and recurring issues, since reopens and recurrences add load without adding new demand. Resolution capacity decomposes into the number of people available, their effective time on the queue, and how long each issue takes. The gap between volume and capacity is the backlog movement.

Reading the tree tells you why the rate is what it is. A falling rate driven by the volume branch is a demand problem that better prevention or deflection addresses. A falling rate driven by the capacity branch is a staffing or efficiency problem. Treating a demand problem as a staffing problem, or the reverse, wastes the intervention. The tree makes the difference visible.

Benchmarks depend on whether you measure period rate or cohort rate and on queue complexity. The ranges below describe a period rate measured monthly, where 100 percent means resolved volume matched received volume.

Resolution rate is most useful read together with escalation rate and reopening. A high resolution rate alongside rising escalations or reopens is a warning that the team is keeping pace by passing work on or closing it prematurely, not by genuinely resolving more.

Improving resolution rate means either reducing incoming volume or increasing the volume the team can clear, ideally without sacrificing quality. The levers below split across both sides of that equation, and each one has a clear owner.

KPI Tree connects each branch of the resolution-rate tree to its owner through RACI, so the deflection node sits with the knowledge team, the routing node sits with triage, and the capacity node sits with the queue lead. When resolution rate moves, the accountable owner of the branch driving the change is notified rather than the whole team chasing an aggregate dip. The verified impact loop then checks whether the deflection or routing change actually raised the rate, so capacity decisions rest on confirmed effect rather than on the assumption that more staff is always the answer.

1. 1

   Reading resolution rate without quality metrics

   A high rate can hide premature closures. Always pair resolution rate with reopening and recurrence so a team cannot lift its headline number by closing issues that bounce straight back.

2. 2

   Mixing period rate and cohort rate

   Period rate can exceed 100 percent, cohort rate cannot. Switching between them without saying so produces figures that look contradictory and undermine trust in the metric.

3. 3

   Counting tidy-up closures as resolutions

   Closing duplicates, spam, and withdrawn issues inflates the numerator without resolving real work. Exclude them so the rate reflects genuine demand cleared, not queue housekeeping.

4. 4

   Measuring over too short a window

   A single backlog-clearing day can swing a daily rate wildly. Use a weekly or monthly window so the rate reflects whether capacity truly matches demand rather than the noise of one busy shift.