Do ticket handoffs predict SLA misses?

In the queue we measured, yes. Across 6,952 resolved tickets, tickets with one or two handoffs missed their SLA target 16% of the time. Tickets with six or more missed it 92% of the time. We used the handoff count alone, and no ticket contents were read. Before you put AI on a ticket type, count how many hands its tickets pass through.

TL;DR

• 1 to 2 handoffs: 16% missed their SLA target. 6 or more: 92% missed.
• The jump comes early. At 3 handoffs, 54% missed.
• A ticket type that bounces between people is a process problem first. Fix it before you automate it.

What did we measure?

One support queue, 6,952 resolved tickets. For each ticket we took one number, the handoff count, and checked whether the ticket met its SLA target.

A handoff is when a ticket changes owner. The handoff count is the number of people who owned a ticket before it was resolved, the way the help desk records it. It counts the first owner too, so a ticket one person handled start to finish has a count of 1.

We didn't read subjects, messages or notes. The handoff count is part of a queue's structure, so this test needs no ticket text at all.

What did the data show?

The more hands a ticket passed through, the more likely it was to miss its target, and the higher the median time.

Fig. 2. One anonymized queue, 6,952 resolved tickets, handoff count only. A correlation, not a cause.

• 1 to 2 handoffs: 16% missed their SLA target. Median time 2 hrs.
• 3 handoffs: 54% missed. Median time 25 hrs.
• 4 to 5 handoffs: 72% missed. Median time 48 hrs.
• 6 or more handoffs: 92% missed. Median time 102 hrs.

Two things stand out.

The jump comes early. Going from the 1-to-2 band to 3 takes the miss rate from 16% to 54%, the biggest step in the data. The median time goes from 2 hours to 25.

At six or more, missing is the norm. 92% of those tickets missed their target. The median time in that band was 102 hours.

Do handoffs cause SLA misses?

We can't tell from this data alone, and we won't claim more than it shows. It's a correlation in one queue.

It can run both ways. Each handoff can add a wait in another person's queue and lose context along the way. But hard tickets also get passed around more, because nobody can solve them. Both are probably true somewhere in your queue.

What the data does show: the handoff count is a cheap early warning. You can see it without reading a single ticket, and in this queue the miss rate rose with every band.

How do you count handoffs in your help desk?

It depends on what your tool records.

• Zendesk keeps two counts per ticket in its ticket metrics: assignee_stations, the number of assignees the ticket had, and group_stations, the number of groups it passed through.
• Other help desks vary. Some record reassignments in an audit log or assignment history rather than a single number. Some don't record handoffs at all. Freshdesk doesn't, for example, so Copious's Freshdesk reads have no handoff counts.

Then run the same test on your queue:

1. Pull 90 days of resolved tickets with ticket type, handoff count, created time and resolved time.

2. Group them into the same bands: 1 to 2, 3, 4 to 5, and 6 or more handoffs.

3. For each band, work out two numbers: the share that missed your target, and the median time.

4. Then do it by ticket type. For each type, find the share of tickets with three or more handoffs. Sort by that share, highest first.

The ticket types at the top of that list are where to look first.

What should you do with a ticket type that bounces?

Fix the process before you add AI. Adding AI to a ticket type that already passes through six people only makes the failure faster.

Look for the usual causes:

• Routing. Tickets land with the wrong group first, then get moved.
• Ownership. Nobody owns the ticket type end to end, so it gets passed along.
• Permissions. The first person can't do the fix, such as issuing a credit, so they have to hand it off.
• Knowledge. The answer lives in one person's head, so everything goes to them.

Once a ticket type stops bouncing, measure it again. Then decide whether AI should handle it. (Here's how to make that call.)

Why doesn't deflection rate show this?

Because deflection counts the tickets that never reached a person. It says nothing about the ones that did.

A bot can raise your deflection rate while the tickets it couldn't solve arrive later, angrier, and with an extra handoff attached. Read deflection next to handoffs per ticket type and repeat contacts. If all three move the right way, that's a better sign than deflection alone.

Where this doesn't apply

• This is one queue. Your mix of ticket types, your target and your staffing will give different numbers. Run the test on your own data before you act on ours.
• Targets differ. Each ticket was checked against this queue's own SLA target. If yours is tighter or looser, the bands will land differently.
• Some handoffs are by design. If tier 1 is supposed to pass certain tickets to tier 2, measure those planned escalations separately from the unplanned ones. A planned path can still be a slow one.
• If your help desk doesn't record handoffs, you'll need assignment history from an audit log or an export before you can run this.

Frequently asked questions

What is a good number of handoffs per ticket?

We don't publish a benchmark, because it depends on your queue and your target. In the queue we measured, tickets with one or two handoffs missed their SLA target 16% of the time, and at three it was 54%. Treat three or more as a reason to look closer.

How do I find the handoff count in Zendesk?

Zendesk's ticket metrics include assignee_stations, the number of assignees a ticket had, and group_stations, the number of groups it passed through. Both are per ticket, so you can pull them for resolved tickets and group them by ticket type alongside created and resolved times.

Is an escalation the same as a handoff?

An escalation is one kind of handoff: a planned move to a higher tier or a specialist team. Every escalation is a handoff, but not every handoff is an escalation. Reassignments caused by wrong routing, missing permissions or shift changes are handoffs too, and they're usually the ones worth fixing first.

Will AI reduce handoffs?

Only if the handoffs come from work AI can do. If they come from routing rules, unclear ownership or missing permissions, AI adds a step instead of removing one. Count handoffs by ticket type first. Fix the ticket types that bounce, then decide where AI belongs.

Where Copious fits

Copious reads the shape of a queue, including handoff counts where the help desk records them, and lists your ticket types by volume. By default it never stores, logs or analyzes ticket contents to do that. You can also run this test yourself from a help desk export, with the four steps above.

Related: What should AI handle in customer support? · How to write an AI usage policy support agents will actually follow

---

Copious helps support and CX leaders decide what AI should handle in their queue and what their people should keep, one ticket type at a time. We take no money from AI vendors.