> ## Documentation Index
> Fetch the complete documentation index at: https://docs.voxworks.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Intent Pathways

> Intent pathways listen for what the caller really wants mid-call, confirm it, and redirect them to the right flow and step in your script — with optional open/closed-hours branching driven by a routing endpoint's schedule.

## 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.

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. This runs slightly behind the normal conversational flow, which means the assistant may occasionally cut itself off when an intent is detected and redirect into the relevant pathway.

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 generally better to handle it using the standard [condition routing](/flows/steps-voice) 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 Warm Handoff

| Use                                          | When                                                                                                                                      |
| -------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------- |
| **Intent pathways**                          | The caller should end up at a different flow or step in the *same script*. Nothing is dialled — it is navigation only.                    |
| **Live Handoff**                             | The caller asks for a human at any point and should be warm-transferred to a routing endpoint. Configured in **Settings → Live Handoff**. |
| **[Warm Handoff](/tools/warm-handoff) tool** | A specific step in your flow should transfer the caller to a person, with a private briefing first. Placed explicitly as a tool step.     |

When both could apply on the same caller turn, Live Handoff always wins — see [What happens on a call](#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 three 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](#writing-a-good-trigger).

**3. 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](/routing/endpoints), then fill in the **On schedule** and (optionally) **Off schedule** branch cards.

| Setting                              | Description                                                                                                                                                                               | Default                          |
| ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------------------------------- |
| Title                                | The pathway's name, shown in the list and in the flow editor's step menu. Type `/` to insert a variable as a `{{...}}` tag.                                                               | `New Intent Pathway`             |
| Listen on                            | The flows and steps where the pathway listens for its trigger.                                                                                                                            | None                             |
| Trigger                              | The situation and the exact phrases that activate the pathway. Supports `/` variables.                                                                                                    | Empty                            |
| Routing endpoint                     | Optional endpoint whose [schedule](/routing/schedules) decides which branch is used. Toggle **Use variable** to supply the endpoint id from a variable such as `{{endpoint_id}}` instead. | No endpoint                      |
| On schedule — Flow / Step            | The destination while the endpoint is open — or always, when no endpoint is set.                                                                                                          | None                             |
| On schedule — message                | What to say on this branch. Guides the confirmation offer the assistant makes.                                                                                                            | Empty                            |
| Off schedule — Flow / Step / message | The destination and message when the endpoint is closed.                                                                                                                                  | None — falls back to On schedule |

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.

***

## 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](/flows/steps-voice) 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.

```text theme={null}
When the caller expresses financial distress — "I can't afford my excess", "I can't pay that", "money is really tight"
When the caller wants out of the booking — "cancel it", "I don't want it anymore", "stop the booking"
When the caller signals an emergency — "someone is hurt", "this is urgent", "I need help right now"
```

***

## The confirmation step

A matched trigger never redirects silently. The assistant:

1. Stops whatever it was saying and pauses briefly.
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 up to five seconds for the caller's answer.

| Caller's answer            | Outcome                                                                                         |
| -------------------------- | ----------------------------------------------------------------------------------------------- |
| Accepts                    | The assistant jumps to the branch destination and continues the conversation from that step.    |
| Declines                   | The offer is withdrawn and the assistant carries on at the current step as if nothing happened. |
| Says nothing (\~5 seconds) | The offer is withdrawn and the assistant re-prompts the current step.                           |

The first couple of seconds of the offer are not interruptible, so the caller always hears the question. 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.

***

## On-schedule and off-schedule branches

* **No routing endpoint selected** — the **On schedule** branch is always used.
* **Endpoint selected** — the endpoint's effective [schedule](/routing/schedules) is checked at the moment the trigger fires. Open → **On schedule** branch; closed → **Off schedule** branch. If the Off schedule branch is empty, the On schedule branch is used either way. An endpoint counts as open when it, or an endpoint in its fallback chain, is open.

The check happens once, when the trigger fires — the confirmation wording and the destination both reflect that result, and it is not re-checked when the caller answers. 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:**

```text theme={null}
Trigger:               When the caller asks for support — "can I speak to support", "I need help with my account"
Routing endpoint:      Sydney Support
On schedule → flow:    Transfer to Support (message: "I'll pop you through to our support team.")
Off schedule → flow:   Take a Message (message: "Support is closed right now, but I can take a message.")
```

***

## 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. At most one can match.
3. If a routing endpoint is set, its schedule picks the branch.
4. The assistant interrupts itself, pauses briefly, 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.

Detection is deliberately conservative. It does **not** run:

* while a handoff or transfer is in progress — including the [Warm Handoff](/tools/warm-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. 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; 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 an empty Off schedule branch falls back to On schedule.
* **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 answer window is about five seconds; a long pause withdraws the offer and re-prompts the current step. Ask them to answer the offer directly.
* **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](/routing/endpoints) — The transfer destinations whose schedules drive branch selection
* [Schedules](/routing/schedules) — Control when an endpoint counts as open
* [Warm Handoff](/tools/warm-handoff) — Transfer the caller to a human instead of redirecting
* [Steps Overview](/flows/steps) — The steps a pathway listens on and jumps to