Chatbot Routing Rules: Sales, Support and VIP

What routing rules are actually deciding

A routing rule looks like a technical artefact: a condition, a destination, a priority number. What it actually encodes is a promise about who answers whom and how fast. When a rule sends every message containing the word 'invoice' to finance, it has committed finance to a response time nobody asked them about.

This is why routing is the part of the build that most often has to be redone. The rules are usually written by whoever configured the bot, working from a reasonable guess about how the company is organised. Three months later the guess has collided with reality: sales does not work Fridays, the support lead left, VIP customers turn out to mean something different in each region, and nobody has updated the table.

So the first move is not to open the rule editor. It is to write down, in plain sentences, who answers what and within how long — and to have the people who will answer agree to it. The rule table is then a transcription of an agreement, and it can be defended when somebody's queue grows.

Priority order is the whole design

Almost every routing system reads rules in priority order and stops at the first match. That single behaviour is where most routing bugs live, because a rule that looks correct in isolation can be unreachable in context.

The practical consequence: order your rules from most specific to most general, and treat the general ones as the floor rather than the plan. A broad rule placed too high swallows the specific rules underneath it, and it does so silently — nothing errors, the conversations simply stop arriving where they should.

1. 1Safety and compliance firstAnything that must never be automated regardless of who is asking: legal threats, safety issues, regulated advice. These belong at the very top, because a lower rule matching first would bypass them entirely.
2. 2Then identityA recognised high-value customer, an open incident, a contract in negotiation. Identity beats topic: a VIP asking a routine question is still a VIP, and routing them into the general queue is the failure people remember.
3. 3Then explicit intentWhat the person actually said they want — a human, a refund, a quote. Explicit statements outrank inferred ones, always. A classifier that overrides a customer's own words will be wrong in the most visible possible way.
4. 4Then inferred topicSales, support, billing, logistics, derived from the message and the page. This is where most conversations are decided, and it is also the layer that needs the most maintenance.
5. 5Then timeWorking hours, holidays, the out-of-hours path. Time is applied late because it modifies the destination rather than choosing it: the same conversation goes to a different place at 23:00, not to a different team.
6. 6Then the catch-allOne rule at the bottom that matches everything and names a real destination with a real owner. If your table has no catch-all, your system has an undefined behaviour and you will meet it at the worst possible moment.

Writing the decision table

A routing table stays maintainable when every row has four things: a condition anyone can read, one destination, a priority, and a named owner. Rows that lack the fourth are the ones that rot.

• Condition — expressed in business language, not regex. 'Customer has an open order and mentions delivery' is maintainable; a keyword list of eleven synonyms is not.
• Destination — exactly one team, queue or person. A rule with two destinations is two rules, and writing it as one hides a duplicate-notification bug.
• Priority — an explicit number, not implied by position in a file. Implicit ordering breaks the first time somebody inserts a row in the middle.
• Owner — a named person who is accountable for what lands there. Unowned destinations become silent queues, and silence in a queue is indistinguishable from success until a customer complains.
• Fallback — what happens if the destination is unavailable, full or out of hours. A rule without a fallback works right up until the day it matters.

Keep the table short enough to read on one screen. Every routing system in trouble has the same history: it started with eight rules, grew to forty as exceptions accumulated, and nobody can now say what a given conversation will do without running it.

Sales, support and the line between them

The sales-support split causes more misroutes than every other condition combined, because the signal that separates them is not the topic — it is whether the person is already a customer.

The same sentence, 'does this work with our warehouse system?', is a pre-sales question from a stranger and a support question from a customer whose integration just broke. Topic classification cannot tell those apart. Customer recognition can, which is why matching the conversation to an existing record should happen before topic routing, not after.

• Recognised customer + product question → support. Selling to an existing customer mid-problem is the fastest way to lose them.
• Unrecognised + pricing, comparison or capability question → sales.
• Recognised customer + explicit buying signal (more seats, another location, an upgrade) → sales, but with the account history attached. This is the highest-value route in most businesses and the one most often mishandled.
• Unrecognised + an order number or account reference → support. They are a customer whose record simply was not matched; routing them to sales makes the system look like it has amnesia.
• Ambiguous → ask one clarifying question rather than guessing. One question is cheaper than one misroute.

Where recognition is not possible — anonymous website chat, a new phone number — accept the ambiguity and design for it. A single question, 'is this about an existing order or something new?', resolves nearly all of it and costs one conversational turn.

VIP routing without inventing a hierarchy

VIP routing fails in a predictable way: somebody defines a tier, nobody maintains the list, and within a year the tier means 'customers who complained loudly in 2025'. If you cannot say where the VIP flag comes from and who updates it, you do not have VIP routing — you have a stale list.

A workable definition comes from a system that is already maintained for another reason. Contract value in the CRM, plan level in billing, an account-manager assignment, an open enterprise deal. Each of those is kept current by somebody whose job depends on it, which is exactly what a routing flag needs.

• Derive the flag, do not hand-maintain it. A nightly sync from billing or the CRM beats a spreadsheet that one person edits.
• Route to a named person where one exists, and to a prioritised queue where one does not. 'Route to the VIP team' is only meaningful if that team is staffed at the hour the conversation arrives.
• Decide what VIP actually changes: queue position, response-time target, whether the AI answers at all, or whether a specific person is notified. All four are legitimate; conflating them is not.
• Define the out-of-hours behaviour explicitly, because it is the case the flag exists for. A VIP routed into an empty queue at midnight has received worse service than an ordinary customer who was told to expect a morning reply.

One more rule worth writing down: a VIP asking a trivial question should still get the fast path. Adding a condition like 'VIP and the question is important' reintroduces exactly the judgement call the flag was meant to remove.

Out of hours, overflow and the fallback path

Most routing tables are written for a Tuesday afternoon. The interesting cases are the other ones, and they are where customer-facing damage actually occurs.

1. 1Out of hoursDecide per destination, not globally. Support might queue for morning; a sales enquiry might get a scheduled callback; a safety issue might need a real escalation path that exists at 03:00 or does not exist at all. One global 'we are closed' message treats all three identically.
2. 2Nobody respondsEvery queue needs a timeout and a second destination. The failure mode without one is not an error — it is a conversation sitting unread for two days, which nobody notices because nothing is broken.
3. 3Destination full or unstaffedHolidays, illness, a team on an offsite. If routing depends on a rota, it needs to read the rota. If it cannot, it needs a manual switch somebody can flip in ten seconds.
4. 4The AI itself is unavailableDecide what happens if the model or the API is down. The correct answer is that conversations fall back to a human path or a plain acknowledgement, not that they disappear.
5. 5Nothing matchedThe catch-all, which should be a real queue that is actually read. Sending unmatched conversations to a shared inbox nobody owns is the most common way a routing system loses messages.

Test the fallbacks deliberately, on a schedule. They are the only part of the routing system that is exercised exclusively when something else has already gone wrong, which means they are also the part most likely to have silently broken since the last time anyone looked.

What has to exist underneath

Routing rules depend on data that has to be available at the moment the conversation arrives. Missing inputs are the root cause of most misroutes, and they are far cheaper to fix than the rules themselves.

• Customer recognition on a stable key — phone number or email — including the formats customers actually use rather than the canonical one.
• A tier or value flag derived from a maintained system, as described above.
• Intent classification good enough to separate four or five categories. Do not build a taxonomy of thirty intents; nobody can route on thirty, and the classifier will be wrong more often than it is useful.
• Working hours and holidays as data the rules can read, per team rather than per company.
• Destinations that receive and acknowledge: a queue, a group notification, a CRM assignment. A destination that only writes to a log is not a destination.
• A log of which rule fired. Without it, debugging a misroute is guesswork, and the first question after every incident is exactly this one.

The last item is routinely skipped and routinely regretted. When a customer asks why their message went to the wrong team, the difference between a two-minute answer and a two-hour investigation is whether the system recorded the rule that matched.

Metrics that expose bad routing

Routing quality is invisible in aggregate statistics. Four numbers make it visible, and all four require someone to record a verdict rather than relying on the system's own optimism.

1. 1Misroute rateConversations transferred at least once after the initial routing, as a share of all routed conversations. This is the headline number. Recording it has to be one click for the person doing the transfer, or it will not be recorded.
2. 2Time to first human response, by destinationAggregate response time hides the destination that is quietly failing. Broken out per queue, the failing one is obvious within a week.
3. 3Unmatched rateHow many conversations reach the catch-all. A rising number means the world has changed and the table has not. A number near zero on a large volume usually means a broad rule is matching too much, too high up.
4. 4Reopen rate after transferConversations that bounce between two destinations. A pair of teams each routing to the other is a rule conflict, and it is invisible in every other metric.

Review the misroutes monthly, in a meeting with the people who received them. Most routing problems are not classification problems; they are disagreements about ownership that only surface when someone is looking at a specific conversation that landed in the wrong place.

Where routing usually breaks

• A broad rule placed above specific ones, silently making them unreachable. The single most common routing defect.
• Routing on topic before checking whether the person is a customer, which produces the sales-to-existing-customer misroute.
• A VIP flag nobody maintains, which degrades into a list of historical complainers.
• No catch-all, so unmatched conversations have undefined behaviour that nobody discovers until a customer follows up.
• Destinations with no owner, which become silent queues indistinguishable from working ones.
• Working hours defined once for the whole company, when teams keep different ones.
• Thirty intents where five would do, producing a classifier that is confidently wrong and a table nobody can reason about.
• No record of which rule fired, turning every misroute investigation into archaeology.

How routing works in Vexvon

On the voice side, Vexvon's routing is built from three pieces that are configured separately and combined: time policies, destinations and rules. Rules are read in priority order and the first match wins, which is the behaviour described above — so the ordering discipline matters here directly.

A rule set can be simulated before it goes live. The panel answers where a given call would land, which is the trace test described earlier applied to the real table rather than to a mental model of it. That is the fastest way to find a rule that has been made unreachable by a broader one above it.

On the messaging side, the same AI engine serves every channel, and the conversation carries a customer record rather than starting anonymous. Phone numbers are detected through a five-stage process and matched against existing customers, so a person who wrote on Instagram last week and calls this week is the same record rather than a new one — which is the recognition step that the sales-versus-support split depends on. A buyer-intent filter decides whether an extracted contact is genuinely a lead before anything is routed, and the company's own numbers are excluded.

Handover to a person has three explicit triggers: a customer asking for an operator raises a notification, an agent typing the stop character pauses the AI on that conversation for thirty minutes, and the AI can be disabled for a conversation outright. Leads are assigned by one of four modes — manual, round robin, by channel, or by load — and every assignment and status change is written to an activity log with ten action types, which is the per-conversation record that makes a misroute investigation short.

Frequently asked questions

1. 1What are chatbot routing rules?They are the conditions that decide which team, queue or person receives a conversation, read in priority order with the first match winning. In practice they encode an agreement about who answers whom and how quickly, which is why they should be written with the receiving teams rather than for them.
2. 2How many routing rules should we have?Few enough to read on one screen. Most organisations are well served by five to ten rules plus a catch-all. Tables that have grown past twenty are usually accumulating exceptions that belong in the conversation design instead.
3. 3Should routing use intent or customer identity first?Identity, after safety. A recognised customer asking a product question is a support conversation even though the topic reads like sales, and getting that order wrong is the most common misroute there is.
4. 4What data is required?Customer recognition on phone or email, a maintained value or tier flag, a small intent taxonomy, working hours per team, destinations that acknowledge receipt, and a log of which rule fired.
5. 5How do we measure whether routing works?Misroute rate, time to first human response broken out by destination, unmatched rate and reopen-after-transfer rate. Aggregate response time hides all four.
6. 6What should happen out of hours?Something different per destination, decided deliberately. Support may queue for morning, sales may schedule a callback, and anything safety-related needs a path that genuinely exists at night or should not be routed there at all.

Start by tracing twenty conversations

Before writing a single new rule, take twenty real conversations from last week and trace, by hand, which rule each would match first and where it would land. The exercise takes an hour and reliably finds two things: a rule that can never fire, and a category of conversation the table does not cover at all.