Intelligent Ticket Routing: A Practical Guide

Do you actually have a routing problem?

Three questions settle it, and most teams have never asked any of them. Does the rule you are considering change who touches the conversation, or does it just add a label? Does a wrong assignment cost more than the click it takes to fix? Can you measure whether it was wrong at all?

If a rule fails any of those, it is decoration. Plenty of teams run elaborate routing configurations where every agent could have handled every ticket, the automation simply decided the order. That is not routing, it is a very expensive random number generator with a maintenance burden.

The genuine symptoms are specific. Conversations sitting untouched in a queue nobody watches. Customers being transferred more than once. A named person who is the only route to certain answers. Volume spikes where assignment becomes the bottleneck rather than resolution. If none of those describe you, spend the effort on knowledge or response templates instead, and revisit routing when you feel one of them.

What does routing cost you today?

Pull the reassignment events for the last month. Every conversation that changed owner is a routing failure, a workload correction, or an escalation, and those three need separating before the number means anything.

Here is the arithmetic, with illustrative inputs you should replace with your own. Twelve hundred conversations a month. Nine percent get reassigned once, so 108 reassignments. Each one costs roughly four minutes of combined agent attention, the first agent reading and passing it on plus the second re-reading it. That is about seven hours a month of agent time.

Then count the customer side, which most teams forget. If a reassignment adds an average of forty minutes to first response, those 108 conversations carry roughly seventy-two hours of extra waiting, concentrated entirely on customers who already had a problem.

Seven hours of agent time may not justify a project. Seventy-two hours of avoidable customer waiting probably does. Notice that the two numbers point in different directions, which is why teams that only measure agent efficiency conclude routing does not matter.

Why does splitting one queue into five make waits longer?

This is the part of routing nobody tells you, and it is a standard result in queueing theory usually called the pooling effect. For the same total arrival rate and the same total capacity, one shared queue produces shorter average waits than several separate queues, because idle capacity in a specialist queue cannot help a backlog in another one.

You do not need the mathematics to recognise it. You have watched one agent drown in billing tickets while two technical agents had nothing to do, and you have seen the billing queue's response time collapse while the overall team utilisation looked healthy. The dashboard says you have capacity. The customer in the wrong queue disagrees.

The literature this comes from also measured what customers do while they wait. In a full year of call-by-call data from a bank call centre, Brown and colleagues found that among callers who left the automated system to ask for a person, "about 80% of those requesting service were in fact served, and about 20% were abandoned before being served" (Journal of the American Statistical Association, 2005, data from 1999). It is one small call centre in the phone era, so treat the 20 percent as illustrative. The transferable point is that abandonment was a property of the queue, not of the customers.

The consequence is a genuine trade-off rather than a free improvement. Every queue you add buys expertise and costs you flexibility. That trade is worth making when expertise is truly non-transferable, and it is a bad trade when the difference between two agents is twenty minutes of reading. Most teams make it far too early, then add load balancing rules to compensate for the fragmentation they created.

Which routing dimension should you add first?

In roughly this order, and only when the trigger in column two is real rather than anticipated.

The ordering is deliberate. Business hours routing is nearly free and prevents your worst failure, a conversation landing in an empty office. Named-skill routing sits near the bottom because it is the most expensive to maintain and the most damaging to get wrong.

What does topic classification get right and wrong?

It gets breadth right. Sorting conversations into a handful of broad buckets is something modern language models do reliably, and it is genuinely faster than a human dispatcher reading each one.

It gets boundaries wrong, and boundaries are where your tickets live. "I was charged after cancelling" is billing and account management and possibly a bug. "The integration stopped syncing after your update" is technical and could be a known incident. Real conversations arrive as compound problems, and a classifier forced to pick one label picks one, confidently.

Two practical consequences follow. First, keep your categories few and obviously distinct; if a human dispatcher would hesitate for three seconds, the classifier will be inconsistent too, and inconsistent training data produces inconsistent routing forever. Second, when you audit disagreements, check whether your own humans agree with each other on the same ticket. If two experienced agents route the same conversation differently, the taxonomy is the problem, not the model, and no amount of retraining fixes it.

Why does skill-based routing create single points of failure?

Because it works, and then it keeps working, and nobody learns anything new. Send every Salesforce question to the agent who knows Salesforce and within six months you have exactly one person who knows Salesforce, permanently. Your response times look excellent right up until they take two weeks off.

This is the honest cost of skill routing and it rarely appears in vendor material. Skill routing optimises today's handling time by trading away tomorrow's flexibility, and the bill arrives as a resignation, a holiday, or a sick week.

If you use it, build a deliberate counterweight. Route a small share of each specialist's tickets to a second person on purpose, accepting the slower resolution as training cost. Require that every specialist scenario has a runbook before it gets its own routing rule. And audit the bus factor quarterly by listing which categories have only one competent owner, because that list is also your hiring and documentation backlog, ranked for free.

How do you stop everything becoming urgent?

By budgeting priority rather than defining it. Write criteria for high priority and, given enough time, everything satisfies them; every customer's issue is urgent to that customer, and every agent wants their ticket seen.

Set the budget first. Decide that top priority is a small single-digit percentage of volume, then write criteria that actually produce roughly that share, and check monthly. When the share drifts upward, the criteria are wrong, not the tickets. A priority level that contains forty percent of your volume is not a priority level, it is a queue with an alarming name.

The measurement that keeps this honest is simple: compare response times across priority levels. If your high priority tickets are not answered meaningfully faster than your normal ones, your priority system is doing nothing except making people feel their concerns were recorded.

What does load balancing actually balance?

Usually the wrong thing. Most systems balance the count of open conversations, which treats a thread waiting three days on a customer reply identically to an active investigation. An agent with fifteen dormant conversations may be completely free; an agent with four live escalations is underwater.

Balance on active work instead. Conversations awaiting an agent response, weighted by whether they need investigation, is a far better proxy than raw open counts. Then cap concurrency: a hard limit on how many conversations one person can hold in an active state protects quality better than clever distribution.

The stance we would defend: for teams under roughly a dozen agents, pull with a cap beats push almost every time. Agents choose their next conversation from a shared queue, with a limit on how many they can hold. It preserves pooling, it self-balances without configuration, and it fails visibly rather than silently. The failure mode is cherry-picking, easy conversations taken first while hard ones age, which you catch by watching oldest-unassigned rather than average age. Fix that with a rule that the oldest conversation must be taken next, not by installing an assignment engine.

How do you run a shadow test that produces a real number?

Log what the classifier would have done, let humans route as they normally do, change nothing for two to four weeks. Then compare.

You get two outputs. The agreement rate, which is the headline number, and the disagreement set, which is where the value is. Read those by hand. Some will be classifier errors. A surprising share will be cases where the human was wrong, or where both answers were defensible because the conversation genuinely spanned two categories.

Do not enable automatic routing on agreement rate alone. Add two gates. First, no category may be worse than the others by a wide margin; a strong average hiding one badly-classified category will fail loudly in production on your most sensitive topic. Second, confirm that reassignment stays one click and that reassignments are logged after go-live, because the moment routing becomes automatic, that log is your only remaining early warning. If you also route certain conversations straight to a person, make sure the handoff path is explicit rather than implied.

Where this breaks

Below roughly eight agents, skip all of it. One queue, agents pull, done. Configuring routing for a six-person team creates coordination overhead that exceeds anything it saves, and it hides the fact that your real constraint is knowledge rather than distribution.

If your volume is genuinely spiky, routing rules tuned in a normal week behave badly in a peak. Test your configuration against your worst week, not your average one.

If agents constantly escalate because they cannot resolve independently, routing will not help. That is a documentation and permissions problem wearing a routing costume, and better classification will simply deliver conversations more accurately to people who still cannot close them.

And to be straight about our own limits: Corebee is not a workforce management suite. If you run sixty agents across three shifts with skill matrices, forecasting and adherence reporting, buy an enterprise platform built for that. Our Zendesk comparison covers where that line sits.

What should you do in the first two weeks?

Week one: confirm your tool logs reassignments, then pull last month's. Separate them into misroutes, workload moves and genuine escalations. Calculate agent minutes and added customer wait using the arithmetic above, with your own numbers.

Week two: if the customer-wait number is small, stop here and write it down so nobody reopens the question next quarter. If it is large, identify which single dimension explains most of the misroutes, usually topic or business hours, and configure only that one. Run it in shadow mode before it touches a real assignment.

If you want a shared queue with reassignment logging before deciding whether you need anything cleverer, you can start a free trial and get a month of honest data first.