Ticket routing rules: how to build rules that keep working

You sit down, map out the logic: "billing keywords go to the billing team", watch the first conversation route cleanly to the right inbox, and feel the specific relief of a problem that has been solved.

The triage queue that ate your Monday mornings is gone. Automation is working exactly the way it was supposed to.

Six months later, you have forty routing rules. Nobody remembers why seventeen of them exist. Conversations are landing in the wrong inbox again; except now, instead of a triage problem, you have a debugging problem. You cannot fix what you cannot read.

This is the failure mode of keyword-based routing. It does not announce itself. The business evolves, the team restructures, a product gets renamed, and the rules keep firing against a version of reality that no longer exists. And somewhere in that friction, customers quietly decide they have had enough.

That failure mode matters more now, not less, because the nature of what gets routed has changed. In the AI Agent era, conversations don't hit your routing rules first; they reach the AI agent first.

It resolves the routine and only escalates what genuinely needs a human as per your instructions. So the conversations still being routed by rules are, by definition, the harder ones — the cases where landing in the wrong inbox costs the most, because a real person is already waiting on something the AI couldn't close.

Brittle rules used to misroute easy tickets. Now they misroute the ones that were already escalated for being difficult.

The stakes here are higher than most teams realize. Gartner research found that 96% of customers who experience a high-effort service interaction become more disloyal — and being transferred while having to repeat information is one of the defining features of high effort. Routing rules that silently degrade are not just an operational inconvenience. They are a loyalty tax, paid by every customer the AI already escalated in good faith, only to be bounced to the wrong team by a rule that stopped reflecting reality months ago.

This guide starts where setup ends. Building routing from scratch? Read our guide to automated ticket routing first. Here, you will learn how to:

• Spot rule sprawl early. Catch the overlapping rules that turn a clean setup into a debugging problem, before customers feel it.
• Keep your rule set readable. Any new teammate should understand it in under ten minutes.
• Catch every unmatched conversation. A named fallback queue with a named owner means nothing disappears silently.
• Detect drift before it costs you. A quarterly review built on reassignment data shows which rules misroute and where.
• Fast-track what cannot wait. Enterprise accounts, at-risk customers and time-critical issues skip the queue automatically.
• Ship rules with confidence. Run every new rule through a 7-point checklist before it goes live.

Why support routing rules break

Think of your routing rule set like a city street map: when the city is small, everyone knows every road, the navigation is intuitive. But as the city grows...new districts, renamed streets, roads that no longer connect to anything useful...the old map becomes a liability.

Two classic failures:

• keyword rules that miss how customers actually write and rules nobody revisits, are covered in our guide to automated ticket routing.

But there is a third routing rule that deserves a closer look, a rule sets that grow without architecture.

Routing Rules that accumulate like a spaghetti plate

When every exception becomes a new rule, every edge case gets its own condition. And later, six months of good intentions produce a rule set that is technically comprehensive and practically unreadable.

Two rules both match an incoming conversation: which one fires depends on execution order, which nobody might have documented when it was set. Now you have a routing behavior that nobody can explain, cannot reliably reproduce, and cannot safely change without the risk of breaking something else.

Every principle below exists to stop that sprawl, or to catch it before customers feel it.

How to build modern support routing rules that last

They are structural decisions, choices you make at the architecture level that determine whether your routing system holds up or transform into an ugly spaghetti plate (even though you love spaghetti).

The evolution of routing rules combined with Agentic AI

The six principles below are the same structural disciplines that have always separated routing systems that last from ones that rot. What's changed in the agentic era is when they fire.

The AI Agent is the default first layer, not routing rules: Every conversation reaches the AI layer at the front, where it resolves what it can:  

• the routine questions,
• the refunds it can issue through a connector,
• the look-it-up-and-act tickets,

and escalates only what genuinely needs a person. By the time a conversation reaches your routing rules, it has already been filtered: it's there because the AI determined a human is required (and thanks to your instructions).

That changes what these rules are for. They are no longer triaging the full firehose of inbound; they are placing the escalated residual: a smaller, harder, higher-stakes stream where every conversation already represents a customer the AI couldn't fully satisfy.

Two consequences follow, and both raise the bar:

First, the volume through your rules drops, but the difficulty concentrates. The easy, unambiguous tickets that keyword rules handled well are exactly the ones the AI now resolves before routing ever runs. What's left leans toward the ambiguous and the sensitive, which is precisely where keyword matching is weakest. The case for building on durable signals rather than phrasing (Principle 1) gets stronger, not weaker.

Second, the AI agent and the rules now share one decision surface. When the AI escalates, it already holds the full context: intent, history, sentiment, the account detail. Good routing architecture hands that context to the rules rather than discarding it: the AI's read of the conversation becomes another structured signal the rules can route on, alongside plan tier, channel, and language.

The escalation isn't a reset to a cold queue anymore; it's a hand-off with everything the AI already knew attached. Designing for that hand-off is the new structural decision sitting above all five principles.

So read what follows with that framing: these are the rules that govern the escalation layer in the agentic AI era — the conversations the AI agent has already decided need a human. The discipline is the same; the stakes are higher, because there are no easy tickets left in the stream.

Principle 1: keep the rule set legible.

A routing system you cannot read is a routing system you cannot fix.

Legibility has a simple operational test: can a new team member understand what your rule set does in under ten minutes? If the answer is no, the rules are too complex, and that complexity will eventually produce a failure you cannot diagnose.

Here are some recommendations to keep your customer support routing rules simple:

1. Keep the rule count as low as possible. Fewer, broader rules beat many narrow ones. If you have three rules that all handle variations of the same scenario, merge them into one.
2. Document the purpose of every rule at creation. Not the condition: the purpose. "Routes French-language conversations to the french-speaking team" tells you what to check when the Paris team is restructured. "language = fr" tells you nothing.
3. Establish clear precedence. When rules can overlap, the execution order should be deliberate and documented, not incidental.
4. Run a complexity audit every time you add a new rule. Is this genuinely a new case, or is it an exception that belongs inside an existing rule?

Principle 2: build explicit fallbacks before you need them.

The conversations that match no rule are the ones most at risk of disappearing entirely. In routing systems without an explicit fallback, an unmatched conversation does not go somewhere predictable, it goes somewhere undefined, which in practice means it goes nowhere useful.

An explicit fallback is not a catch-all team assigned by default. It is a deliberate architectural decision: when no other rule fires, this conversation goes here, to this named queue, visible to this owner. That owner can see it, triage it, and either handle it or use it as signal that the rule set has a gap.

The operational discipline that goes with fallbacks is monitoring. If your fallback queue is consistently empty, your rules are probably covering everything, which is great! If it is consistently full of a particular type of conversation, you have found a gap worth closing with a new rule.

Unmatched conversations are not edge cases: they are a daily occurrence in any support operation with meaningful volume. The fallback is not the safety net you hope to never use, it is the mechanism that makes silent misrouting visible.

Principle 3: treat your rule set as a living system, not a finished product.

The teams whose routing keeps working are not the ones who built it best at launch: they are the ones who maintain it.

A quarterly review cadence is the minimum viable maintenance schedule, just like you do with your AI Agent or your teammates.

Here are questions you can ask yourself to get started:

• Which rules are still firing correctly against current team structure and product names?
• Which rules have not fired in the past 90 days?
• What does your reassignment rate look like?
• Where are conversations landing after reassignment?

Principle 4: build a fast lane for conversations that can't wait their turn.

Not every escalated conversation carries the same urgency, and a routing system that treats them as equal will route a furious enterprise customer and a routine question into the same queue at the same priority: even distribution is fair; it is not always right.

A fast lane is an explicit, high-precedence path for conversations where delay itself is the failure: it must be defined by durable signals.

Here are some reliable triggers you can leverage to build your routing rules fast lane:

1. Severity by attribute: an Enterprise or top-tier account, a contractual SLA, a flagged at-risk customer. These are customer data, static, and known before the conversation starts.
2. Sentiment and intent from the AI hand-off: when the AI sees or understand a specific topic and read as high-frustration or churn-risk, that read should promote the conversation into the fast lane automatically, this is the clearest and easiest example of the AI's context becoming a routing signal.
3. Time-sensitive context: a checkout failing mid-purchase, an outage report, a payment blocked.

The fast lane needs the same discipline as the rest of the system: a named owner, a monitored queue, and a precedence rule that fires before round-robin or skills-based distribution gets a say.

⚠️ It needs a guard against abuse if everything qualifies for the fast lane, nothing does. Audit it on the same quarterly cadence as the rest: a fast lane that's catching 40% of volume isn't a fast lane, it's the default queue wearing a costume.

Principle 5: build on intent and attributes, not raw keywords.

The foundation of a durable routing rule is a signal that does not depend on predicting customer phrasing.

1. Customer attributes (their plan tier, account type, region, language) are stable, they do not change based on how a customer words their message. A rule that routes all Enterprise-tier accounts to a dedicated team is robust in a way that a rule checking for the word "enterprise" never will be.
2. Channel is also worth checking as a durable signal. A message arriving through your API integration should probably route differently than one arriving through your public chat widget.
3. Language detection is a structured signal that generalizes perfectly. A French-speaking customer should reach a French-speaking agent without you needing to anticipate every French phrasing of every problem type.

The practical principle: keyword is an old-fashioned way of dealing with routing rules, combine AI + customer data to build the most efficient and productive customer support experience.

Principle 6: hand rules off to intent-based AI where they cannot keep up.

Static rules have a ceiling, they can express structured signals and conditional logic well, but they cannot read meaning, and a meaningful portion of incoming conversations will always resist clean categorization.

Intent-based AI routing solves this at the layer where rules cannot. Rather than matching words, it reads the conversation — the full context, the expressed need, the emotional register — and routes on what the customer is actually communicating.

This is not a replacement for well-structured rules. It is a complement to them. The structured signals (attributes, channel, language) can be applied at the same time as AI kicks in, because they are reliable and cheap to evaluate from an AI point of view.

How does Hugo Routing work

Routing rules are used to describe situations you wish Hugo to detect. When he encounters these situations, he can then trigger the action of your choice, giving you flexibility in all kind of workflows. Hugo is a next-generation AI

Crisp Knowledge Base

A quick checklist before you ship a rule

A good routing rule should pass every item on this checklist:

• Built on a durable signal?
  Does the rule rely on customer attributes, language, intent, channel, or another stable signal instead of a fragile keyword?
• Has clear priority?
  If multiple rules could match the same conversation, is it obvious which one wins?
• Is purpose documented?
  Could someone new to the team understand why the rule exists and when it should apply?
• Includes a fallback path?
  If the rule does not match, or no rule matches at all, is there a default destination for the conversation?
• Avoids unnecessary overlap?
  Is the rule distinct from other rules, rather than duplicating logic that already exists elsewhere?
• Can be measured?
  Will you be able to see whether the rule is assigning conversations correctly?
• Is part of a review process?
  Will this rule be reviewed regularly so it does not quietly become outdated?

Creating routing rules in Crisp

Crisp runs routing on two layers that answer different questions. Hugo, the AI agent, reads what the customer means. Your routing rules read who the customer is. Each layer handles what the other cannot.

The AI layer: Hugo reads intent

• Every conversation starts with Hugo. With the AI agent active, new conversations land in the Automated inbox. Hugo answers what it can, and your team is not notified by default.
• Routing rules written in plain language. In AI Agent > Guidance > Routing, you describe a situation, not a keyword: "The user is requesting a demo call to discover our product." When Hugo detects it, it moves the conversation to a sub-inbox, starts a workflow, or escalates.
• Escalation on its own terms. Hugo escalates when it is not confident, when a person is needed, or when an escalation rule fires. That rule can run a workflow first, to check an order or tag the account, before an agent takes over.

The human layer: rules read structured signals

• Sub-inboxes decide where a conversation lives. Conditions on channel, language, country, segments or customer data send each new conversation to one sub-inbox. Order sets priority, so the most specific inboxes sit on top.
• Operator Routing decides who owns it. Rules run top to bottom. Crisp picks an online agent from the first matching rule and moves to the next rule only when nobody there is available. Each rule targets one operator or an Operator Team.
• A fallback rule catches everything else. A simple-condition rule assigned to a Triage team, placed at the bottom, picks up conversations no rule matched and conversations whose matching rule had nobody online.
• Reassignment keeps ownership current. "Re-assign if the current assignee is offline" and "Re-assign stale conversations" stop a conversation from stalling on someone who cannot answer.

How the two layers work together

Hugo filters, rules place. Hugo resolves the routine and reads intent on the rest, so only conversations that genuinely need a person reach your rules. Your rules then apply what is certain: the account tier, the language, the team on shift. Hugo never needs to know your org chart. Your rules never need to predict how a customer phrases a refund request.

For the customer, the split is invisible. They get an instant answer when one exists. When it does not, they reach the right person, who already has the full conversation in front of them. No repeating themselves, no bouncing between queues.

Routing rules do not fail because automation is unreliable. They fail because nobody maintains them. Keep Hugo's situations sharp, keep your rule set short, and review both every quarter.

Ready to build a customer service routing experience that lasts?

Frequently asked questions about routing rules

How many routing rules is too many?

There is no universal number, but legibility is the functional limit. If your rule set cannot be explained to a new team member in under ten minutes, it is too complex to maintain reliably.

What is the difference between routing rules and assignment rules?

Routing rules determine where a conversation goes — which team, queue, or agent receives it. Assignment rules can operate at a more granular level, determining which specific agent within a team handles a conversation, often based on workload, availability, or skill specialization.

How do I know if my routing rules are actually working?

The primary metric is your reassignment rate — the percentage of conversations that are transferred after their initial routing assignment. A low and stable reassignment rate indicates that conversations are landing in the right place. A high or rising reassignment rate indicates drift. Secondary signals include: time-to-first-response by team (if one team's queue is consistently backed up, they may be absorbing misrouted volume), and fallback queue volume (a growing fallback queue means the rule set has gaps).

Should I use AI routing from the start, or build static rules first?

Build the structured layer first — attributes, channel, language. These signals are reliable regardless of conversation volume, and they cover a significant portion of routing decisions cleanly. Layer in AI intent routing for the high-ambiguity residual once you have baseline data on where your static rules fall short.

How often should I review and update routing rules?

A quarterly review cadence is the minimum for teams with stable volume. Teams experiencing rapid growth — headcount, product expansion, new channels — should review monthly.

Sources

Gartner, Effortless Experience: Conquering the New Battleground for Customer Loyalty, https://www.gartner.com/en/customer-service-support/insights/effortless-experience

Gartner, First Contact Resolution Research: The Impact on Customer Loyalty, https://www.gartner.com/en/customer-service-support/topics/first-call-resolution

Statista, Share of Customers Who Switched Brands Due to Poor Customer Service Worldwide, https://www.statista.com/statistics/1420073/customers-switching-brands-poor-service/

McKinsey & Company, The Value of Getting Personalization Right — or Wrong — Is Multiplying, https://www.mckinsey.com/capabilities/growth-marketing-and-sales/our-insights/the-value-of-getting-personalization-right-or-wrong-is-multiplying

Salesforce, State of Service Report (6th Edition), https://www.salesforce.com/resources/research-reports/state-of-service/

Harvard Business Review, Stop Trying to Delight Your Customers, https://hbr.org/2010/07/stop-trying-to-delight-your-customers