AI Call Routing: Intent, Time and Caller Type

The menu is not the problem

Everyone dislikes phone menus, so the obvious pitch for voice AI is that it removes them. That is true and it is the least interesting part. A menu is a routing mechanism that makes the caller responsible for classification, and callers are bad at it — they press whatever gets them to a human fastest, which is why option four is always overloaded.

Removing the menu moves the classification into the system, which is better for the caller and harder for you. The rules are now invisible, they interact, and a call that lands in the wrong place produces no error — it produces a person in the wrong queue with a customer who has already explained themselves once.

So the work is not the voice interface. It is a routing table that is short enough to reason about, ordered so specific rules are reachable, and testable before a real caller meets it.

Order: safety, identity, intent, time

Voice routing rules are read in priority order and the first match wins. That single behaviour is where most routing defects live, because a broad rule placed too high makes every specific rule beneath it unreachable — silently, with no error at all.

1. 1Safety firstAnything that must never wait or be automated regardless of who is calling: an emergency in your sector, a safety report, a regulated situation. These sit at the very top because a lower rule matching first would bypass them entirely.
2. 2Then caller identityA recognised high-value account, an open incident, a contract under negotiation. Identity beats topic: a key account calling with a routine question is still a key account, and sending them to the general queue is the failure people remember.
3. 3Then explicit intentWhat the caller actually said they want — an operator, a refund, a booking. Explicit statements outrank inferred ones without exception. A classifier that overrides a caller's own words fails in the most visible way available.
4. 4Then inferred intentSales, support, billing, logistics, derived from what the caller described. Most calls are decided here, and this layer needs the most maintenance.
5. 5Then timeWorking hours, holidays, the out-of-hours path. Time is applied late because it modifies a destination rather than choosing one: the same call goes somewhere different at 23:00, not to a different team.
6. 6Then the catch-allOne rule at the bottom matching everything, naming a real destination with a real owner. A table with no catch-all has an undefined behaviour, and you will meet it at the worst possible time.

Worked examples

Rules are easier to argue about as concrete cases. Four that most tables get wrong.

• A recognised customer says 'I want to buy more licences' at 19:00. Identity says account manager; intent says sales; time says out of hours. Correct outcome: capture the request, notify the named account manager, schedule a morning callback — not a general sales queue and not a generic closed message.
• An unrecognised caller says 'my order has not arrived'. Topic reads as support and identity is unknown. Correct outcome: support, because an order reference implies a customer whose record simply was not matched. Routing them to sales makes the system look amnesiac.
• A caller says 'just give me a person' as the first thing. Explicit intent outranks everything below it. Correct outcome: transfer immediately with no qualification, and if nobody is available say so honestly with a concrete alternative.
• A caller describes a safety issue at 03:00. Safety is above everything, including time. Correct outcome: the escalation path that genuinely exists at that hour, or an honest statement that it does not and exactly when it will.

Transfer mechanics that callers notice

Routing decides the destination; transfer decides the experience. These are the details callers actually judge you on and they are usually configured by default.

• Warm or cold. A warm transfer where the receiving person hears the context first is slower and far better; a cold transfer to someone who knows nothing restarts the conversation.
• What the caller hears during the transfer. Silence reads as a dropped call and produces a second inbound call within a minute.
• Whether the conversation so far travels. If the person picking up cannot see what was said, the customer repeats themselves and the automation added a step.
• What happens if the destination does not pick up. Every transfer needs a timeout and a second destination, or the call quietly dies in a ring group.
• Whether the caller can get back to the agent if the transfer fails, rather than being left on a dead line.
• Whether the number is preserved for a callback. A dropped transfer with no recorded number is a lost customer with no trace.

Fallbacks: the half nobody configures

• Out of hours, decided per destination rather than globally. Support may queue for morning; sales may get a scheduled callback; safety needs a path that exists at night or should not be routed there at all.
• Nobody answers: a timeout and a second destination, or the call sits in a queue that closes at six with somebody still in it.
• Destination unstaffed — holidays, illness, a team offsite. If routing depends on a rota it must read the rota, and if it cannot, somebody needs a switch they can flip in ten seconds.
• The AI itself unavailable. The correct design is that calls fall through to your existing routing rather than failing, and this must be tested rather than assumed.
• Concurrency exceeded at a peak: decide whether the overflow is a queue with a stated wait, a callback offer, or a different destination entirely.
• Nothing matched: the catch-all, which must be a real queue somebody reads.

What to measure

1. 1Misroute rateCalls transferred at least once after the initial routing, as a share of all routed calls. Recording it must be one click for the person transferring, 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 calls reach the catch-all. A rising figure means the world changed and the table did not; near zero on high volume usually means a broad rule is matching too much, too high.
4. 4Transfer completion rateTransfers where the caller actually reached a person. This is distinct from misroutes and it is where dropped transfers hide.
5. 5Repeat calls within an hourThe clearest signal that a transfer failed, and it is visible in the call log without anyone recording a verdict.

How routing works in Vexvon

Routing is built from three pieces configured separately and combined: time policies, destinations and rules. Rules are read in priority order and the first match wins — which is exactly the behaviour that makes the ordering discipline above matter, rather than a detail to discover later.

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 above applied to the real table rather than to a mental model of it, and it is the fastest way to find a rule made unreachable by a broader one above it.

For the identity layer, phone numbers are detected through a five-stage process and matched against existing customer records shared across every channel, so a caller who wrote on Instagram last week is the same record rather than an unknown number. That is what makes 'recognised customer' a usable routing condition rather than an aspiration.

Mid-call the agent can transfer to an operator, end the call or search the knowledge base, and a customer asking for a person raises an operator notification. Lead assignment runs in one of four modes — manual, round robin, by channel or by load — and every assignment and status change is written to an activity log covering ten action types, which is the record that makes a misroute investigation short.

Frequently asked questions

1. 1Does AI call routing remove the phone menu?Yes, and that is the least interesting part. A menu makes the caller responsible for classification and they are bad at it. Removing it moves classification into rules that are invisible, interact with each other and need to be testable.
2. 2What order should routing rules be in?Safety, then caller identity, then explicit intent, then inferred intent, then time, then a catch-all. Rules are read in priority order and a broad rule placed too high silently makes everything beneath it unreachable.
3. 3Why does identity come before topic?Because a recognised customer asking a product question is usually a support conversation even though the topic reads like sales, and a key account with a routine question is still a key account.
4. 4What should happen when nobody answers a transfer?Every transfer needs a timeout and a second destination. Without one the call dies quietly in a ring group, and the only evidence is a repeat call an hour later.
5. 5What happens if the AI service is down?Calls should fall through to your existing routing rather than failing. This is the fallback most often assumed and least often tested, and it should be exercised deliberately.
6. 6How do you know routing is working?Misroute rate, time to first human response broken out by destination, unmatched rate, transfer completion rate and repeat calls within an hour. Aggregate response time hides all five.

Trace twenty calls against your table

Before writing a single new rule, take twenty real calls 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 call the table does not cover at all.