How to automate ticket routing without creating a black hole

Routing is the first decision made about a ticket and the one with the largest effect on how long it takes. A ticket that lands with somebody who can answer it is resolved in one reply; one that lands in a general queue is read by three people before reaching the same place.

The failure worth designing against is not a misroute. It is the ticket that lands somewhere nobody owns, which produces no error, appears in no agent's queue, and is discovered when the customer follows up.

What we'll cover

• What routing actually decides
• Rules before classification
• When the classifier is unsure
• Building it with CodeWords
• The queue nobody owns
• Rerouting without losing the history
• Routing by more than topic
• Telling the customer something while it routes
• Making it survive
• Limits worth knowing about
• What to build first
• Frequently asked questions

What routing actually decides

Who reads it first, which for most tickets determines whether it is answered or forwarded.

How quickly, since queues have different staffing and different response expectations.

Whether the SLA clock is right. A ticket in the wrong queue is frequently measured against the wrong target.

Whether it is seen at all, which is the failure this whole article is about.

Not the answer. Routing is a delivery decision, not a support decision, and automations that try to answer while routing do both badly.

Rules before classification

Start with what is certain, and use inference only for what is left.

Route on facts you have. The product the customer uses, their plan, the form they submitted, the address they wrote to, the integration that raised it — all are unambiguous and none requires interpretation.

Structured intake beats classification. A form with a category field routes perfectly; an email requires a guess. Where you control the intake, adding the field is cheaper and more reliable than any classifier.

Rules are auditable. When a ticket goes to the wrong place, a rule can be read and corrected; a model's decision can only be observed.

Use classification for the genuinely ambiguous — free-text email, chat, anything where the customer describes a problem rather than selecting a category.

Most routing is rules. Teams reach for classification first and discover afterwards that two-thirds of their tickets carried the answer in a field.

When the classifier is unsure

The design decision that determines whether routing helps or quietly harms.

Get a confidence signal and use it. Below a threshold, the ticket should go to a triage queue rather than to a guessed destination.

A wrong route costs more than an unrouted one, because a ticket in the wrong specialist queue looks handled and sits, while one in triage is visibly waiting.

Tune the threshold against the cost. Misrouting a billing question to technical support wastes a few minutes; misrouting an outage report wastes an hour.

Measure the reroute rate, which is the direct evidence of how well classification is working and is usually not tracked.

Feed reroutes back. Where agents send tickets is the best training signal available and it is free.

Never let low confidence produce a silent default. That is the mechanism that fills a general queue nobody reads.

Building it with CodeWords

CodeWords connects to more than 3,000 integrations, so routing can use the CRM, the product, and the billing system rather than only the ticket's text.

1. Open CodeWords and start a new automation.
2. Describe what should happen in plain language to Cody, the automation builder: which signals decide the route, and what happens when they are absent.
3. Authorize the connections — the helpdesk, and whatever systems hold the customer context.
4. Describe the exceptions: an unclassifiable ticket, a queue with nobody available, a customer who cannot be matched.
5. Run it in shadow mode first, logging the route it would have chosen, and compare against what agents actually did.

You describe the outcome; Cody builds it, connects it, and deploys it. The free plan covers light use, with Pro at $39 per month and Business at $100 per month as usage grows; details are on the pricing page.

The queue nobody owns

The failure this is all about, and it is worth being explicit.

Every routing scheme has a default, and defaults acquire whatever the rules could not place.

A queue with no named owner is not swept. Everybody assumes somebody else is watching it.

Name an owner, a person rather than a team, and say so where the queue is defined.

Report its contents daily, since the point is that nobody looks at it spontaneously.

Report its age, because the oldest ticket in the default queue is the best single measure of whether routing is working.

Treat its growth as a routing bug. A default queue filling up means the rules do not cover something, and the fix is a rule rather than more sweeping.

Rerouting without losing the history

Agents will reroute, frequently, and the process should expect it rather than treat it as an exception.

Keep the conversation. A reroute that starts a new ticket loses what the customer already explained and makes them repeat it, which is the single most disliked support experience.

Record why it moved, in a note, since that is both useful to the next agent and the data that improves the routing.

Do not restart the clock. The customer has been waiting since they wrote in, not since the ticket arrived in the second queue, and measuring from the reroute flatters the numbers.

Cap the hops. A ticket rerouted three times should escalate to a person who decides where it belongs, rather than continuing round.

Report multi-hop tickets weekly, since they are where both the worst customer experience and the clearest routing gaps are.

Routing by more than topic

Topic is the obvious signal and rarely the only useful one.

Availability. Routing to somebody who is away is the most avoidable delay there is, and a routing rule that does not know the rota will do it daily.

Language, which is unambiguous and frequently ignored until a customer complains.

Account ownership. A named account's tickets should reach whoever knows them, which is information the CRM holds and the helpdesk usually does not.

Prior context. A customer who wrote last week about the same thing should reach the same agent, which shortens the conversation considerably.

Workload. Distributing to the least loaded person within a queue beats round robin, which assigns to people who are already behind.

Severity, for anything that looks like an outage, since those should skip the normal path entirely.

Telling the customer something while it routes

The customer's experience of routing is silence, and a few seconds of automation changes that.

Acknowledge immediately, saying what will happen and roughly when, rather than confirming receipt of something they know they sent.

Set the expectation by queue. A billing question and an outage report have different realistic response times, and saying which applies prevents the follow-up email.

Do not promise a time you will not meet. An acknowledgement that overstates is worse than none, because it converts a wait into a broken promise.

Say nothing about the route. "Assigned to the integrations team" means nothing to a customer and invites a question about why.

Suppress it for anything already in a conversation, since an automated acknowledgement mid-thread reads as nobody having read the message.

Measure whether it reduces follow-ups, which is the outcome it exists for and is easy to check.

Making it survive

Route in shadow mode first, logging the decision without acting, and compare against what agents do. This is the cheapest possible validation.

Handle the missing signal by routing to triage rather than to a default, and reporting it.

Keep rules readable and in one place, so the person who understands the support process can change them.

Handle the queue with nobody available — a rota gap, a holiday — rather than assigning into a void.

Report the outcome. Tickets routed, by queue, rerouted, and left in triage.

Limits worth knowing about

Classification degrades as your product changes, since the language customers use shifts with the features they are using.

Short tickets carry little signal. "It's broken" cannot be classified by anything, which is an argument for structured intake rather than a better model.

Rerouting statistics are affected by agent habit as well as by routing quality, so a high rate is a prompt to look rather than a verdict.

Helpdesk automation may already do some of this, and duplicating it in two places produces routes that depend on which ran last.

Customer data crosses systems here, from the CRM into the helpdesk, which is worth mapping once rather than discovering during a review.

What to build first

Rule-based routing on the facts you already have — product, plan, form, address, account owner — with everything unmatched going to a named triage queue that is reported daily. It handles the majority of tickets correctly, it is auditable, and the triage queue's contents tell you exactly which rule to write next.

Two habits make the difference. Send low-confidence tickets to triage rather than to a guessed destination, since a wrongly routed ticket looks handled and a triaged one visibly waits. And put a named person on the default queue, because a queue belonging to a team belongs to nobody and is where tickets go to be found by the customer's second email.

Frequently asked questions

Should routing use rules or classification?

Rules for anything you can determine from a fact — product, plan, form, account owner — and classification only for genuinely ambiguous free text. Most teams reach for classification and later discover two-thirds of tickets carried the answer in a field.

What should happen when classification is unsure?

Route to a triage queue, not to a best guess. A wrongly routed ticket looks handled and sits in a specialist queue; a triaged one is visibly waiting and gets picked up.

Why does the default queue matter so much?

Because it acquires everything the rules could not place, and a queue owned by a team is swept by nobody. Name a person, report its contents and its age daily, and treat growth as a routing bug rather than a sweeping problem.

Should a reroute create a new ticket?

No. The customer explained the problem once and should not repeat it. Keep the conversation, record why it moved, and do not restart the response clock — they have been waiting since they wrote in.

What signals besides topic are worth routing on?

Availability, language, account ownership, whether they contacted you recently about the same thing, workload within the queue, and anything that looks like an outage. Availability alone removes a delay that otherwise happens daily.

How do I know routing is working?

Reroute rate, the age of the oldest ticket in triage, and the count of tickets rerouted more than twice. The last is where both the worst customer experience and the clearest gaps are.

How should I validate a change to routing?

Shadow mode: log the route it would have chosen without acting, and compare against what agents actually did. It costs nothing, it runs on real tickets, and it finds the disagreements before customers do.

Should an automated acknowledgement be sent?

Yes, if it says what happens next and roughly when, set by queue. "We have received your message" tells somebody nothing they did not know and does not prevent the follow-up email, which is the point.

What should the acknowledgement not say?

The internal route. "Assigned to the integrations team" means nothing to a customer and invites a question. And never promise a response time you will not meet — that converts an ordinary wait into a broken promise.

Related reading

• Automating bug triage
• Connecting Zendesk to Slack
• Freshdesk and CodeWords