Skip to main content

​
What are Intent Pathways?

Intent pathways let your assistant recognise, mid-call, that the caller wants something a different part of your script handles — and offer to take them there. You choose the steps where a pathway listens, write its trigger as situational words — the situation plus the phrases a caller uses to express it — and pick a destination flow and step. When a caller’s words match the trigger, the assistant pauses, offers the redirect, and on a “yes” jumps straight to the destination. A pathway redirect is pure navigation within your script. The call is never transferred or dialled anywhere — everything the assistant has learned so far comes along to the new step. The check runs on the caller’s turns on a listening step. By default, when the detour finishes the caller is returned to the exact step they left — including when that step was inside a sub-flow. You can instead name a main-flow step for the caller to land on (see When the destination ends), and you can limit a pathway to calls where certain variables hold (see Only active when). Intent Pathways can be found under: Scripts → (your script) → Settings → Intent Pathways Good fits:
  • Sentiment detection — catch the words of a distressed, angry, or vulnerable caller (“I can’t afford that”, “I need help right now”) wherever they surface in the call, and redirect to a flow designed to handle it
  • Escaping the wrong branch — a caller deep in the booking flow says they actually want to cancel
  • Hours-aware detours — send callers to a transfer flow during business hours and a message-taking flow after hours

​
Deep Listen

Intent Pathways operate using our proprietary Deep Listen system. It checks each caller turn alongside the assistant’s reply, so when an intent is detected the assistant can stop the reply it was about to give and make the redirect offer instead. For this reason, we recommend using intent pathways as a backup mechanism. Where a particular intent is commonly expected at a specific step, it is better to handle it using the standard condition routing within that step — conditions are evaluated in the normal flow of the conversation, so the caller gets a smoother experience. Intent pathways then catch the intents that surface where you didn’t expect them.

​
Intent Pathways vs Live Handoff vs the Handoff tool

When both could apply on the same caller turn, Live Handoff always wins — see What happens on a call.

​
Creating an Intent Pathway

Open your script and go to the Settings tab, then choose Intent Pathways in the sidebar. The section is a card described as “Map pathways to flows and steps, then define routing conditions”. Before you add anything it reads: No intent pathways yet. Click New to add one. Click New. A pathway named New Intent Pathway is added and expands, ready to configure. Each pathway is a collapsible row — the header shows its title, how many flows it listens on, and its on-schedule destination. The delete icon removes a pathway immediately (there is no confirmation), though nothing is stored until you save the script. Expanding a pathway reveals four numbered steps: 1. Listen on — Steps where this pathway watches for the trigger below. Every flow in your script is listed. Tick a flow to attach it, then pick the steps with the searchable step picker (or use Select all). The header of each flow row shows a running count, e.g. 3/12 steps. 2. Trigger — What the caller does to activate this pathway. The situation plus the words callers use to express it. See Writing a good trigger. 3. Only active when — Optional checks against call variables, all of which must pass before the trigger above is even considered. No rows = always active. See Only active when. 4. Send the caller to — Optionally branch by a routing endpoint’s schedule, then pick a destination step for each branch. Choose an optional routing endpoint, then fill in the On schedule and (optionally) Off schedule branch cards. Each branch also has a When that destination ends choice — see When the destination ends. A pathway only takes part in calls once it has a trigger, at least one listening step, and an on-schedule destination that still exists. Incomplete pathways save without error but are simply skipped at call time.

​
Only active when

Some pathways only make sense for certain callers or at certain points in a call — an “existing booking” detour is pointless for a caller who has no booking. Only active when lets you say so. Each row is a check against a call variable, and a pathway with rows only listens for its trigger when every row passes. With no rows it reads No conditions — this pathway is always active. Click Add condition to add a row, then fill in: The checks are made on each caller turn with the call’s current values, so a variable a step writes during the call can switch a pathway on or off from then on. Example — only offer the booking-change detour to callers who have a booking:
Here {{custom.booking.reference}} is a custom variable field holding the caller’s booking reference (string, e.g. BK-20931), filled from your records or by an earlier step. Callers without one never hear the offer. A second row such as {{custom.booking.status}} equals confirmed (string) narrows it further: both rows must pass.

​
When the destination ends

By default a pathway is a detour: when the destination flow finishes, the caller goes back to whatever they were doing. Each branch’s When that destination ends choice lets you change that:
  • Return to previous (the default) — the caller returns to the step they were on when the pathway fired.
  • A main-flow step — listed as Name (#id). The steps the caller left behind are discarded, and when the destination flow ends the call lands on the step you named and runs it. The on-screen help puts it as: “Default returns the caller to whatever they were doing. Naming a main flow step instead discards the parked steps and, when the destination flow ends, lands on that step and runs it.”
Use a named step when the detour replaces the rest of the original conversation — for example, after a complaint-handling flow, go straight to the wrap-up step rather than back into the sales pitch. Flow steps can be chosen but are marked — re-invokes its flow on return, because landing on a flow step runs that step, which starts its sub-flow again. As the tooltip says, “Valid, but usually not what you want.”

​
Writing a good trigger

A good trigger uses situational words: name the situation, then anchor it with the actual phrases a caller uses to express it. Detection matches against what the caller says, so an abstract description alone gives it nothing concrete to listen for — the quoted phrases are what make a trigger reliable.
  • Pair the situation with the words that signal it — When the caller expresses financial distress — "I can't afford my excess", "I can't pay that" works. When the caller becomes distressed alone does not — it names a state without the words that reveal it.
  • List the variations — callers phrase the same thing differently, so include the common wordings: "cancel it", "I don't want it anymore", "stop the booking".
  • Reserve triggers for the unexpected — it is not recommended to use pathways for standard step conditioning. Where a phrase is the expected answer at a specific step, handle it with that step’s condition routing instead; pathways are for words that can surface anywhere.
  • Start with the caller — the field’s placeholder, When the caller…, is a good habit. Write what they say, not what the assistant should say.
  • Keep triggers distinct on shared steps — when several pathways listen on the same step, at most one can match per caller turn and there is no priority order. Overlapping phrase lists give unpredictable picks.
  • Leave opening hours out of it — the trigger should be schedule-independent. Open/closed handling belongs in the branches, not the trigger text.

​
The confirmation step

A matched trigger normally offers the redirect before taking it. The assistant:
  1. Stops whatever it was saying.
  2. Offers the redirect with a short confirmation question, worded from the conversation and the branch message — for example, “It sounds like you’d like to change an existing booking. Would you like me to take you there?” If no tailored wording can be drafted, it falls back to: “I’m sorry about the confusion. It sounds like a different option may be a better fit. Would you like me to take you there?”
  3. Waits about five seconds, from the end of the offer, for the caller’s answer.
The offer is spoken in full and cannot be talked over — anything the caller says while it is playing is ignored, so a caller who says “yes” over the top of it needs to answer again once it finishes. If the offer itself fails to play (less than about 60% of it is heard), it is withdrawn and the call carries on at the current step. Write each branch message as the pitch you want made — it shapes both the offer’s wording and what the assistant leads with at the destination. Leave the branch message empty for a silent redirect. A branch with no message is treated as a jump you do not want announced: the assistant says nothing, takes the caller straight to the destination, and carries on from there. Use it when the destination step does the talking, and fill the message in whenever you want the caller asked first.

​
On-schedule and off-schedule branches

  • No routing endpoint selected — the On schedule branch is always used.
  • Endpoint selected — the endpoint’s effective schedule is checked at the moment the trigger fires. Open → On schedule branch; closed → Off schedule branch. If the Off schedule branch is empty, the pathway is switched off while the endpoint is closed — it cannot trigger until the endpoint opens again. To keep a pathway listening at all hours, fill in the Off schedule branch too (it can point at the same step). An endpoint counts as open when it, or an endpoint in its fallback chain, is open.
The schedule is checked when the trigger fires, and again when the caller answers: the offer’s wording reflects the first check, but the destination is taken from the second, so a caller who says “yes” just as the endpoint closes goes to the Off schedule destination. If an Only active when check has stopped passing by the time the caller answers, the redirect is dropped. If the schedule cannot be evaluated, the On schedule branch is used. The endpoint picker shows each endpoint with a live open/closed status dot and its department and destination, plus a shortcut to the Numbers & Routing page. It warns you when a saved endpoint no longer exists, and when an endpoint is broken (its destination cannot be dialled). Example — after-hours message taking:

​
Enabling pathways from the flow editor

You do not have to manage listening steps from the Settings tab. On the Script tab, every step card’s badge menu includes an Intent Pathways submenu:
  • It is greyed out until the script has at least one pathway.
  • When the step is attached to pathways, the menu shows a count, e.g. Intent Pathways (2).
  • The submenu lists every pathway by name with a check mark on the enabled ones — click to toggle this step in or out of a pathway.
Both surfaces edit the same configuration, so changes made on a step card appear in the Settings section straight away, and vice versa.

​
What happens on a call

  1. The caller speaks on a step where at least one pathway is listening.
  2. After the caller’s turn, Voxworks evaluates it — with the recent conversation and the current step for context — against every pathway on that step whose Only active when checks pass. At most one can match.
  3. If a routing endpoint is set, its schedule picks the branch.
  4. The assistant interrupts itself and speaks the confirmation offer.
  5. On a “yes”, the assistant navigates to the branch destination and continues from there. Everything gathered so far is kept, and any data collection pending on the step being left still completes.
  6. When the detour reaches the end of its flow, the caller comes back to the exact step they were on when the pathway fired — including a step nested inside a sub-flow — unless the branch names a main-flow step under When that destination ends, in which case the call lands on that step and runs it.
A destination step with no script of its own — a bare tool step, or a sub-flow that starts with one — is simply run. The assistant does not invent something to say to fill the gap. Detection is deliberately conservative. It does not run:
  • while a handoff or transfer is in progress — including the Handoff tool
  • while Live Handoff is confirming or transferring a call — Live Handoff always wins, and if the caller asks for a human during a pathway confirmation (with Live Handoff enabled and within hours), the pathway is abandoned and the transfer takes over
  • while another pathway confirmation is already pending
  • on the confirmation exchange itself, so a pathway can never re-trigger off its own offer
All doubtful cases fail safe: if a match is uncertain or anything goes wrong, no redirect happens and the conversation simply continues at the current step. Changes to pathways take effect on new calls after you save the script.

​
Limits and edge cases

  • One redirect at a time — only one pathway can trigger per caller turn, and a new trigger cannot fire while a confirmation is pending.
  • No count limit — you can add as many pathways as you like, but a focused set with distinct triggers matches more reliably.
  • Tools — attaching a step that runs a tool means the pathway will continue to work within that tool.
  • Reused flows — a sub-flow used in several places is monitored everywhere it appears.
  • Deleted destinations — if a pathway’s on-schedule destination flow or step is later deleted, the whole pathway is skipped at call time. A return step that no longer exists in the main flow shows as (not in main flow). Review your pathways after restructuring flows.
  • AI Receptionist — the simplified AI Receptionist editor uses transfer routes, which are warm transfers, not intent pathways. The two are separate features.

​
Troubleshooting

  • The pathway never triggers — confirm it has a trigger, at least one listening step, and an on-schedule destination that still exists; check the caller is actually on a listening step; check every Only active when row passes on that call; make sure Live Handoff isn’t claiming the same phrases.
  • The wrong branch fires — check the endpoint’s effective schedule (including public holidays and date overrides) and its fallback chain; remember a pathway with an empty Off schedule branch does not trigger at all while its endpoint is closed.
  • It triggers too often — the trigger is too broad. Narrow the wording, and remove listening from steps where that phrase is an expected answer.
  • The caller said yes but nothing happened — the offer can’t be talked over, so a “yes” said while it was still playing is ignored; the answer window opens when the offer finishes and lasts about five seconds. A long pause withdraws the offer and re-prompts the current step.
  • The caller didn’t go back where they were — check the branch’s When that destination ends setting; a named main-flow step replaces the return.
  • A warning appears on the endpoint — “The selected routing endpoint no longer exists” means it was deleted; pick another. A broken-endpoint warning means its destination cannot be dialled and transfers will follow the endpoint’s fallback.

​
Next Steps

  • Endpoints — The transfer destinations whose schedules drive branch selection
  • Schedules — Control when an endpoint counts as open
  • Handoff — Transfer the caller to a human instead of redirecting
  • Steps Overview — The steps a pathway listens on and jumps to