Service Level Pack: Two Correct Comments, One Misleading Conclusion

January. Team A: 400 × 0.92 = 368. Team B: 1,600 × 0.80 = 1,280. Combined = 1,648 / 2,000 = 82.4%.

February. Team A: 1,200 × 0.88 = 1,056. Team B: 300 × 0.76 = 228. Combined = 1,284 / 1,500 = 85.6%.

Reconciliation. Both comments are arithmetically correct, which is why neither can simply be deleted.

• The head of operations is right about the aggregate: 82.4% → 85.6%, a rise of 3.2 percentage points.
• The team leader is right about the teams: each fell by exactly 4 percentage points (92 → 88 and 80 → 76).

Why both can be true. This is a mix effect, not a performance effect. Team A's share of tickets moved from 20% (400/2,000) to 80% (1,200/1,500). The better-performing team became the dominant team, so the average rose even though every part of it fell. The aggregate is dominated by whichever team holds the volume, and that changed by a factor of four.

Correction to the pack. The circled figure should not be labelled 'improvement' without a note that both constituent rates declined. A single combined percentage with a shifting denominator is not a performance measure.

The recommendation does not follow from the data.

Reason 1 - the comparison is not like-for-like. Team A's higher rate in both months is confounded with volume. In February, Team A processed 1,200 tickets at 88% while Team B processed 300 at 76%. Small teams with unusual tickets (here, a migrated product line) frequently have different SLA profiles; the difference may reflect ticket mix rather than process quality. Nothing in the pack holds mix constant.

Reason 2 - the movement is common, not differential. Both teams lost exactly 4 percentage points. A change that hits two teams equally, in the month a product line migrated, points to a shared cause - new ticket categories, changed clock rules, a system change - not to a team-specific process defect. Copying Team A's process to Team B would not address a common cause.

Reason 3 - scale effect. Team A's rate fell 4 points precisely when its volume tripled. That is at least as consistent with strain from absorbing the migrated line as with anything about Team B.

What to do instead. Before any roll-out, establish the common cause of the 4-point fall across both teams; compare like-for-like ticket categories; and pilot any process transfer on a matched sample. A roll-out launched on a mix artefact would be expensive and would not move the number.

Report team-level rates plus a fixed-weight (standardised) combined rate.

The calculation. Apply February's team rates to January's ticket mix. January mix: Team A 20%, Team B 80%.

Standardised February rate = (0.20 × 88%) + (0.80 × 76%) = 17.6 + 60.8 = 78.4%.

Compare with January's 82.4%: the like-for-like change is −4.0 percentage points, exactly the fall seen within each team.

The gap between this and the headline move is the whole story: reported +3.2 points, like-for-like −4.0 points, a swing of 7.2 points created entirely by the change in mix.

Reporting changes to make.

1. Show each team's rate with its ticket count, never a bare percentage.
2. Show the combined rate alongside a fixed-weight version, and state which mix is being used.
3. Annotate any month in which the volume split between teams moved by more than, say, 10 percentage points, because the aggregate is no longer comparable.
4. Separate the effect of the migration from business-as-usual tickets, so the client is not comparing a changed ticket population with an unchanged one.

The headline figure can still be reported - it is not wrong - but it needs the standardised figure beside it, or the pack will keep generating the same argument every month.