Call Routing Rules (Flow State)

A Call Routing state is a special node/state type that routes a call to a specific destination based on rules you define, instead of leaving the choice to the AI. It is the right tool whenever the destination must be exact — dialing the correct regional rep, sending VIPs to a priority queue, or forwarding by ZIP code. Use it when you need deterministic routing, not a best guess.

When to Use Call Routing

You have a list of destinations (extensions, phone numbers, or other states) and a deterministic way to pick between them.
The cost of routing to the wrong destination is high (wrong sales rep, wrong support queue, wrong location).
You want a fallback when none of the rules match, without falling back to AI guesswork.

If your routing is "send them wherever sounds right," a plain state with transitions is fine. Reach for a Call Routing state when the decision needs to be rule-based.

What a Routing State Contains

A Call Routing state is configured through its own panel, not the regular prompt + tools editor. It has four parts:

1. Inputs

The pieces of information the rules will match against. Each input has a source:

Ask caller — the agent prompts the caller for the value ("What ZIP code are you calling from?").
Caller ID — read directly from the incoming number, no question asked.
Flow state — reuse a value collected earlier in the call (a name, an account number, a lead-qualification answer).

2. Rules

Each rule is an "if input matches this, go to that" pair. Rules are evaluated in order, so put the most specific ones first. Matches are deterministic — exact match, list match, or simple pattern — not free-form LLM judgement.

3. Destinations

Every rule points at one of three destination types:

Extension — internal handoff within your domain.
Phone number — external transfer.
Node — another state in the same flow, so routing can lead into info collection, scheduling, or any other flow branch.

4. Fallback

The destination used when no rule matches. Always configure this. A routing state without a fallback is a trap door.

Two options shape how the state behaves at runtime:

Auto-route if possible (on by default) — if the rules return a single unambiguous match, the agent transfers immediately instead of re-confirming.
Confirm before transfer (on by default) — read the destination back to the caller before connecting.

Example: Regional Sales Router

Input: ZIP code (source: ask caller).

Rules:

ZIP starts with 0, 1, or 2 → Extension 101 (East rep).
ZIP starts with 3, 4, or 5 → Extension 102 (Central rep).
ZIP starts with 6 or 7 → Extension 103 (South rep).
ZIP starts with 8 or 9 → Extension 104 (West rep).

Fallback: Extension 100 (main sales queue).

Result: 40 reps, four buckets, deterministic routing on every call.

LLM-Assisted Resolver (Optional)

For inputs that are fuzzy in practice — a caller saying "the Charlotte office" when your list uses "CLT" — the routing state can be configured with an optional LLM resolver. It normalizes the caller's answer against your known list before the rules run. The rules themselves stay deterministic. Use this sparingly; if the list is short, it is usually cleaner to just phrase the question more narrowly.

The point of a routing state is to take the decision away from the AI. If your rules are right, your routing is right — every call, every time.

Tips

Put the most specific rules at the top. First match wins.
Always set a fallback. A quiet transfer to nowhere is worse than an awkward one.
Use Caller ID inputs when you can — no question, no misheard answer.
When collecting input by asking, phrase it tightly: "What is the five-digit ZIP code for your location?" beats "Where are you?".

Still have questions? Submit a ticket and we will help you design your routing state.