The same ticket keeps getting reassigned between two teams

Export one week of assignment-change events and plot hops per ticket. The shape of that histogram tells you the cause before you read a single ticket. A long tail — 12 tickets with 6 or more hops each — is a rules conflict between two automations. A fat bar at exactly 2 hops across hundreds of tickets is a boundary problem in the taxonomy, where the first assignment is systematically wrong for one kind of request. They are different faults with different fixes, and the fix for one makes the other worse.

What almost never explains it is model accuracy. A classifier that is wrong 15 per cent of the time produces tickets that move once and stay. A ticket that moves 6 times has been claimed 6 times, which requires 2 things that both believe they own it.

The confirming check: count the hops, and read the actor column

1. Export every assignment-change event for 7 days: ticket id, timestamp, from-group, to-group, and the actor — a named person, a named trigger, an integration token or the model.
2. Histogram hops per ticket. Record the counts at 0, 1, 2 and 3-or-more. The 0 bucket matters too: a healthy queue has most tickets there or at 1.
3. For the 3-or-more population, write out the group sequence. A to B to A to B is a conflict. A to B to C is an escalation chain, which is a different conversation and possibly fine.
4. For the 2-hop population, group by intent label and product area. If 70 per cent of them sit in 2 or 3 labels, the taxonomy boundary is your problem and no amount of rule tuning will help.
5. Read the actor column last, because it usually ends the investigation. Two automated actors writing the same ticket within a few seconds of each other is a conflict you can see without any interpretation.

If your helpdesk does not record which rule made an assignment, that is the first thing to fix. A reason string on every write — rule name, model version, confidence — turns this from an afternoon of guessing into a query.

What each hop signature means

The four causes, ranked

1. Overlapping trigger conditions. Two rules whose conditions are both true for the same ticket, executing in an order that is either undefined or an accident of when each was created. The tell is an alternating pair with automated actors. Fix: make the conditions mutually exclusive, or delete one rule. Ordering them is a patch that survives until somebody adds a third.
2. Two writers on the assignee field. A model asserts an owner, an automation asserts another, and an integration writing back from a CRM or an engineering tracker asserts a third. Each is individually correct. Fix: exactly one writer, described below.
3. A product area genuinely spanning two teams. Nothing is misconfigured — the request really does need both, and each team correctly believes the other should start. Fix: name a default owner and make the second team a consulted follower, never a co-assignee.
4. Escalation implemented as reassignment. A ticket escalated to a senior queue and returned looks identical to a bounce, and the original accountability is lost on the way. Fix: escalation is a state change plus a follower, not a transfer of ownership.

The third cause is the one teams argue about longest, because it is genuinely a business decision rather than a configuration error. Settle it with evidence rather than a workshop: work out which accounts sit behind the contested requests and what they are worth, using the method in putting a number on the accounts behind one request. The team with the most exposure to those accounts should own the default.

The tie-break order, when one writer is not available

Some helpdesks do not let you funnel every assignment through one component. Then the answer is an explicit, written precedence order that every rule is built to respect — the same discipline, enforced by convention instead of by code.

1. An explicit human assignment wins over everything, and locks the ticket. Set a flag that suppresses automated reassignment for the rest of the ticket's life. Automation overriding a person is the most damaging version of this bug, because the person stops trusting the queue.
2. A named account owner beats a topic rule. If an account has a named owner for contractual reasons, topic classification does not get to move it.
3. A topic rule beats a channel or language rule. Language decides who can answer within the group, not which group.
4. Load balancing runs last, and only inside the group already chosen. A balancer that can cross group boundaries is a second writer wearing a different hat.
5. Anything below the confidence floor goes to a triage view owned by a named person. Not to a team, because a team is where unowned tickets go to age.

A ticket that has moved 6 times has not been misclassified 6 times. It has been claimed 6 times, by things that were never told who wins.

The decision tree

1. Is the hop distribution a long tail or a spike at 2? Long tail means rules, spike means taxonomy. Do not proceed until you have answered this.
2. Long tail with automated actors: collapse to a single writer for the assignee field. This is the default recommendation and it resolves most cases outright.
3. Long tail with human actors: the dispute is real. Write the ownership rule down, and convert escalation from a reassignment into a state change with a follower.
4. Spike at 2 hops in a few labels: the boundary is wrong. Either merge the labels, or move the team split to match how requests actually arrive. Retuning rules against a wrong boundary just relocates the bounce.
5. Spike at 2 hops spread evenly: your first assignment is a placeholder. Send unclear tickets to a triage view rather than pretending to route them.
6. If two teams still both need to act on most of these tickets after all of the above: merge the queue. Two groups that touch 60 per cent of the same tickets are one group with a rota, and the routing layer cannot fix an organisational split.

What this does not fix

• Capacity. If one group is shedding load, ownership rules will not create hours. Which assignment model survives a backlog is a separate argument, made in priority lanes against round-robin assignment.
• Duplicates. One issue arriving as 3 tickets looks like churn in every report you have — the transport-level cause is in customer replies opening brand-new tickets, and merging them downstream treats the symptom.
• The clock. In most helpdesks reassignment does not pause a first-reply timer, so a bounced ticket is also a breaching ticket, and the two reports look unrelated until you overlay them. The timer's own edge cases are in SLA breaches on tickets that arrived at 2am.

Almost everything above is instrumentation rather than intelligence: record who wrote the assignee and why, then look at the distribution. That is a couple of days of internal tools and ops work, and it is the prerequisite for anything ambitious in ticket and inbox triage — a router you cannot audit is a router you cannot improve. The wider practice is SaaS and customer support.

• routing
• triage
• ownership
• helpdesk