Give the agent a routing table that people own and let it route from that table alone. It reads the ticket and the customer's recent history, picks the team, and moves the ticket at depth 3 because a misroute is easy to undo. Tickets it cannot place with confidence go to a triage queue a person works. Changes to the table stay with team leaders.
What is ticket routing, and who owns it?
Routing decides which team picks up a ticket. A misrouted ticket waits in the wrong queue, gets bounced, and arrives late at the team that could have solved it in minutes. Customers feel that as being passed around. Routing also has a safety side: fraud reports, complaints and legal threats must reach the teams that handle them, quickly, every time.
The support operations lead owns the routing table: which teams exist, what each handles, and the rules for overlaps. Each team leader owns their own row. Routing depends on good tags; the tagging side is covered in tagging and categorising support tickets. The wider support position is in the AI support agent that knows when to say no.
How does the agent route, step by step?
- Agent, depth 1: reads the ticket. Subject, body, attachments, channel, language. Evidence: the inputs used, stored with the routing verdict.
- Agent, depth 1: reads recent history. Open tickets for the same customer and the team handling them. A follow-up should usually go to the team that already owns the issue. What the agent may read is set out in can a support agent read a customer's previous tickets. Evidence: related tickets linked.
- Agent, depth 1: checks the protected routes first. Fraud, complaints, legal threats, data protection requests, safeguarding signals. If any is present, the ticket goes there, whatever else it contains. Evidence: the protected-route check and its result.
- Agent, depth 2: matches the ticket to the routing table. Product, request type, language and any skill or authority the work needs. Evidence: the table row matched and the table version.
- Platform: tests confidence against the threshold. Above it, routing is allowed. Below it, the ticket goes to triage. Evidence: the verdict and the bound that decided.
- Agent, depth 3: moves the ticket and writes a one-line internal note saying why. Evidence: the note and the move.
- Person, triage lead: routes tickets the agent could not place. And settles disputes when a team says a ticket is not theirs. Evidence: the person's routing decision.
| Step | The agent does | Depth | Stays with a person |
|---|---|---|---|
| Read ticket | Reads content and metadata | 1 | Nothing |
| History | Links open tickets for the customer | 1 | Nothing |
| Protected routes | Checks fraud, complaints, legal first | 1 | Handling those tickets |
| Match | Finds the routing table row | 2 | Changing the table |
| Threshold | Platform tests confidence | None | Setting the threshold |
| Move | Routes and notes the reason | 3 | Nothing |
| Triage | Nothing | None | Unplaced and disputed tickets |
Why is routing depth 3 when replies start at depth 2?
Because a misroute is reversible and visible. If the agent sends a billing ticket to the delivery team, the delivery team sees it, moves it, and the record shows what happened. The cost is delay, not harm. A wrong reply, by contrast, reaches the customer and cannot be unsent. This is why routing is often the first capability a new support agent earns at depth 3 while its replies remain held, in line with draft and hold as the default for new support agents.
The exception is the protected routes. Routing a fraud report into the general queue is not a delay, it is a failure. Build those checks so that doubt always sends the ticket towards the protected team, never away from it.
What stays with a person?
The routing table and the threshold. If the agent could rewrite the table, it could route its way around a difficult team. Team leaders also keep the right to reject a ticket and send it back to triage, which is the signal that the table or the agent's matching is wrong.
Tickets that contain two unrelated issues also go to triage. Splitting a ticket changes what each team sees and how the customer is answered, so a person decides. Once routed, the receiving team may use the agent to draft replies for staff to send, as described in drafting replies to support tickets for staff to send.
Which controls matter, and what evidence do they leave?
Protected routes before everything. Evidence: the protected-route check recorded on every ticket.
Table versioned and owned. Evidence: the version cited in each routing verdict, and the change history with approver.
Confidence threshold. Evidence: the score and the threshold on each verdict, and the triage volume it produces.
Reason note on every move. Evidence: the internal note, which also helps the receiving team.
Bounce tracking. Every time a team moves a ticket on, the record links it to the original routing verdict. Evidence: the bounce chain.
What should you measure?
- Bounce rate: tickets moved again after the agent routed them.
- Protected-route misses, found when a fraud, complaint or legal ticket surfaces in the wrong queue. Review every one.
- Triage volume and how long tickets wait there.
- Time from arrival to the right team.
- Follow-ups routed to a different team from the open ticket.
Where does it usually go wrong?
The table describes the organisation chart, not the work. Teams are named by department, but tickets describe problems. Write table rows in the customer's terms.
Language is ignored. A ticket in a language one team does not handle reaches them anyway. Language is a routing input, not an afterthought.
The threshold is set to empty triage. It looks efficient, but the hard tickets are then routed on a guess. Keep the triage queue staffed and visible.
Re-organisations break routing overnight. A team is merged and the table is not updated. Make the table change part of any team change.
Questions people ask
Can the agent route to a named person?
No. Routing goes to a team or queue, and the team leader decides who takes the work. That keeps workload decisions with people.
Should the agent route by customer value?
Only if the routing table has a row for it, approved by the operations lead. Hidden priority rules are hard to defend when customers compare experiences.
What if a team keeps rejecting tickets the agent sends?
Look at the bounce chain. Either the table row is wrong or the agent's matching is, and the record shows which.