Pathway Builder Guide

Overview

Pathway Builder is the workspace where you define what Alex says, listens for, and does at each point in a conversation, which is why it is the core control center for call, SMS, and chat outcomes. A clear pathway turns intent into predictable service quality, so your team can scale responses without losing consistency.

How it works

• When you map a conversation on the canvas and connect each node intentionally, Alex follows that logic in sequence, so callers experience consistent routing and messaging instead of ad-hoc responses.
• When Global Prompt guidance, node-level instructions, and variable extraction align, Alex can interpret context accurately, which reduces repeated questions and improves completion rates.
• When you validate drafts in Chat & Test, then publish and assign the right pathway, you catch logic gaps before live traffic, so production interactions stay reliable.

Important fields

• Pathway: The full conversation flow Alex runs on a call, SMS, or chat.
• Node (step): One action in the flow — for example, Speak, Wait for Response, IVR, or Transfer.
• Canvas: The visual workspace where you arrange and connect nodes.
• Draft: Your work-in-progress copy. You can edit it freely without affecting live calls.
• Published: The live copy that real calls and messages use today.
• Production version: The published snapshot callers hear right now. Older numbered versions stay saved for rollback.
• Global Prompt: Business-wide instructions that apply on every step — tone, rules, and guardrails.
• Extract variable: A detail Alex remembers from a caller's answer — for example, their name or preferred day.

Tips

• Good to know: keep your first draft simple and expand once each branch behaves as expected, because stable foundations make later edits safer.
• Good to know: published versions power live channels, so draft changes are safe for iteration until you intentionally release them.

1. The Pathway Canvas

The pathway canvas is the visual map of your conversation system, and it matters because every branch you draw becomes runtime behavior for Alex. A readable layout lowers review friction, so teams can spot logic problems before publishing.

Next, define what caller details should be captured so downstream nodes can act on reliable context.

• When nodes are positioned in conversational order and connected by clear paths, dependencies become obvious, so both editors and reviewers can validate intent quickly.
• When each node is configured from the edit panel and saved into draft, your structural map and node logic stay synchronized, which prevents hidden behavior mismatches.
• When teams maintain spatial consistency across pathways, future updates take less time, because orientation and branch purpose are immediately recognizable.
• Flow Builder tab: The design view where you arrange nodes and branches.
• Node dock: The bottom toolbar where you add steps — Speak, Wait for Response, IVR, Transfer, Webhook, Knowledge, and End Call.
• Start node: The single entry point where every conversation begins.
• Edit panel: The right-side panel where you configure the selected node.
• Good to know: consistent left-to-right flow reduces review mistakes, especially when multiple people maintain the same pathway.

2. How to Capture Caller Details

Extract variables are structured values Alex stores from caller input, and they matter because reusable context drives accurate routing, responses, and handoffs. Capturing the right detail once prevents repeat prompts later in the same interaction.

Next, align Global Prompt guidance so extracted values are handled with the right tone and policy constraints.

• When variable extraction is attached to the node where the caller provides information, Alex can normalize that response immediately, so later nodes reference a clean value instead of raw language.
• When variable names and extraction prompts are specific, ambiguity drops, which improves reliability for conditions, transfers, and external integrations.
• When extracted values are validated in Chat & Test, edge-case phrasing is caught early, so production paths remain stable under real caller variation.
• Variable name: A short label for the captured detail — for example, caller_name or preferred_day.
• Type: The kind of answer you expect: text, number, yes/no, decimal, or list.
• Extraction prompt: Plain-language instructions for what to pull from the caller's answer at this step.
• Variables tab: A pathway-wide list of every detail you collect and which node captures it.
• Good to know: concise variable names and strict types make webhook mapping and reporting cleaner over time.

3. Global Prompt

Global Prompt is the persistent instruction layer that shapes Alex behavior across all nodes, and it is critical because it enforces consistent tone, policy, and safety boundaries. Strong global guidance reduces per-node repetition while protecting brand and compliance requirements.

Next, refine Welcome and Speak messaging so opening language reflects your Global Prompt standards.

• When business rules are centralized in Global Prompt, node content can stay focused on local intent, so pathway maintenance is faster and less error-prone.
• When guardrails define restricted topics and escalation behavior, unsafe or off-policy responses are less likely, which improves trust and reduces operational risk.
• When global instructions are reviewed alongside pathway edits, tone and policy drift is detected early, so published behavior remains predictable.
• Global Prompt field: Your main instructions for how Alex behaves on every turn of the conversation.
• Guardrails: Topics Alex must not discuss — for example, exact pricing or medical advice.
• Brand voice: How Alex should sound — formal or casual, and whether emojis are okay on SMS or chat.
• Good to know: updating shared policies in one Global Prompt change is safer than duplicating policy text across many Speak nodes.

4. Welcome and Speak Nodes

Welcome and Speak nodes define what Alex says at each conversational moment, and they matter because wording quality directly affects caller confidence and response clarity. Precise prompts reduce misunderstandings and improve branch accuracy.

Next, place Wait for Response nodes after key prompts so Alex can capture intent before routing.

• When your first Speak node sets context and asks a single clear question, callers know what to do next, so Wait for Response nodes receive cleaner input.
• When static phrasing is used for regulated or approved language, messaging stays compliant, while AI Prompt mode supports adaptive responses where flexibility is beneficial.
• When each message is tested for brevity and intent alignment, the flow feels natural, which lowers abandonment and repeated clarification loops.
• Title: The label shown on the canvas — for example, Welcome or Offer Appointment Slots.
• Static message: The exact words Alex delivers every time. Best for approved or regulated wording.
• AI Prompt: Instructions for Alex to generate a response based on the conversation so far.
• Speech Settings: Optional voice override for this step only.
• Good to know: short prompts with one intent per node improve response quality more than long multi-question scripts.

5. Wait for Response Nodes

Wait for Response nodes capture caller input and pause progression until meaningful signal arrives, which is essential because routing quality depends on what Alex hears next. Well-tuned response handling creates smoother, less repetitive conversations.

Next, add IVR nodes where external phone systems require keypad navigation before the conversation can continue.

• When a Wait for Response node follows a focused Speak prompt, caller intent is easier to classify, so branch logic can trigger with less ambiguity.
• When silence limits, timeout behavior, and fallback routing are configured deliberately, stalled conversations recover gracefully, which prevents dead ends.
• When keyword rules and branch connections are tested against real phrasing variation, route accuracy improves, so escalation and self-service paths activate more reliably.
• Timeout (seconds): How long Alex waits before moving to the fallback node.
• Max Silence (seconds): How much quiet time passes before Alex treats the caller as done speaking.
• Keywords: Quick phrases Alex watches for — for example, yes, no, or representative.
• Fallback node: Where the conversation goes when the caller does not respond clearly.
• Good to know: balance timeout and silence settings carefully, because aggressive limits can cut off callers while long limits can feel unresponsive.

6. IVR Nodes

IVR nodes send DTMF input to automated phone systems, and they matter because many transfers and partner workflows depend on successful menu navigation. Correct IVR timing prevents failed handoffs and repeated retries.

Next, configure Transfer nodes so callers can be handed to the correct destination after IVR navigation.

• When IVR nodes are inserted at points where external menus block progress, Alex can continue the workflow autonomously, so callers avoid manual redial loops.
• When DTMF sequences include realistic pauses, menu prompts are met at the right moment, which improves successful option selection.
• When IVR paths are validated on real calls, timing differences across providers are exposed, so production transfers remain dependable.
• Title: The label shown on the canvas — for example, Navigate Billing IVR.
• DTMF sequence: The keypad tones Alex sends — for example, w1# to wait, press 1, then pound.
• Type: Fixed to IVR for steps that navigate automated phone menus.
• Good to know: production IVR behavior often differs from sandbox assumptions, so live call validation is the safest way to finalize sequences.

7. Transfer Nodes

Transfer nodes move callers from Alex to a person or external line, and they are critical because escalation quality influences caller trust and issue resolution speed. Choosing the right transfer mode keeps context intact during handoff.

Next, add Webhook nodes where live system data is needed before confirming next actions.

• When transfer destinations are explicit and validated, routing failures decrease, so callers reach the intended team with fewer retries.
• When warm transfer mode is used for high-context escalations, Alex can brief the receiving agent first, which shortens resolution time and reduces repeated questioning.
• When fallback behavior is defined for no-answer outcomes, conversations still close with direction, so callers are not dropped into uncertainty.
• Transfer number: The phone number or variable Alex dials to reach your team.
• Transfer type: Cold transfer connects immediately. Warm transfer lets Alex brief the agent first.
• SIP REFER transfer: Optional handoff mode for cold transfers on SIP calls.
• Warm transfer prompts: What Alex says to the agent, the caller, and voicemail if nobody answers.
• Good to know: a brief pre-transfer announcement reduces confusion, especially when callers are moved between systems or departments.

8. Webhook Nodes

Webhook nodes connect Alex to external systems during live conversations, and they matter because real-time data turns generic scripts into operational workflows. Integrated calls enable accurate confirmations, lookups, and downstream automation.

Next, incorporate Knowledge nodes for open-ended questions that should be answered from trusted documents.

• When webhook requests include validated variables from earlier nodes, external systems receive complete context, so responses can be used immediately for next-step decisions.
• When success and failure branches are both configured, system outages and edge responses remain manageable, which protects caller experience under degraded conditions.
• When response fields are mapped into pathway variables, later nodes can reference fresh data, so Alex can confirm outcomes without manual intervention.
• Method & URL: How Hello Alex contacts your system and which web address to use.
• Request body: The information Hello Alex sends — you can include details Alex captured earlier.
• Response data: Which parts of your system's reply Alex should remember for later steps.
• Speech while waiting: What Alex says while your system is working.
• Good to know: start with a narrow success path first, then expand branches once response payloads are proven stable.

9. Knowledge Nodes

Knowledge nodes answer caller questions from approved documents, and they matter because retrieval-based responses improve factual consistency and reduce hallucinated answers. Document-scoped search keeps guidance aligned with your source material.

Next, finalize End Call behavior so successful and fallback paths close with clear summaries.

• When relevant document sets are attached to a Knowledge node, Alex can retrieve grounded answers, so callers receive information tied to your approved content.
• When fallback text is defined for low-confidence retrieval, unresolved questions still move toward a clear next action, which prevents conversational dead ends.
• When knowledge scope is curated by topic, retrieval quality increases, so answers remain specific rather than overly broad.
• Sources: Which uploaded document sets Alex can search during this step.
• Cite Sources: When enabled, Alex can reference which document informed the answer.
• Fallback Text: What Alex says when it cannot find a good answer — for example, offering a transfer.
• Good to know: focused source sets outperform mixed libraries, because tighter scope improves retrieval relevance and confidence.

10. End Call Nodes

End Call nodes explicitly terminate interactions and record outcomes, and they matter because clean closure protects caller confidence and reporting accuracy. Defined endings prevent loops and keep post-call systems synchronized.

Next, validate the full draft in Chat & Test to confirm branches and variable carryover before publishing.

• When each logical branch routes to an End Call node, callers receive a definitive outcome, so interactions do not linger in ambiguous states.
• When summaries include key captured variables, teams can act without replaying calls, which shortens follow-up cycles.
• When after-call notifications are configured, CRM and operational tools update automatically, so downstream workflows stay aligned with conversation results.
• End Reason: How the conversation ended — for example, completed or transferred. Shows in call history.
• Summary Template: The recap text saved after the call. You can include details Alex collected.
• After-Call Webhook URL: A web address Hello Alex notifies when the call ends.
• Send Summary Email: Emails the recap to addresses you configure for your team.
• Good to know: concise end summaries with only actionable details are easier for teams to process and triage quickly.

11. Chat & Test

Chat & Test simulates conversations in-text against your current pathway draft, and it matters because rapid iteration exposes routing gaps before phone testing. Fast feedback cycles reduce publishing risk and speed up refinement.

Next, run a live Test Call on the published version to confirm voice, pacing, and transfer behavior on real telephony.

• When you test representative caller intents in chat, branch transitions become visible immediately, so misrouted logic can be corrected before release.
• When difficult scenarios are replayed with alternate wording, extraction and fallback behavior are stress-tested, which improves resilience to real-world language variation.
• When draft edits are revalidated in short loops, confidence rises quickly, so only stable logic moves to published versions.
• Chat Test tab: A free text simulation of your current draft. No call credits required.
• @alex mentions: Ask for help improving wording or debugging a branch during a test session.
• Active node highlight: The blue glow on the canvas shows which step Alex is on right now.
• Good to know: intentionally test unclear and contradictory caller language, because edge phrasing is where routing defects usually appear.

12. Test Call

Test Call places a real phone call using your published pathway, and it matters because voice, timing, and telephony behavior can differ from text simulation. Live validation confirms production readiness before customer exposure.

Next, review how versions move between Staging and Production so the flow you just validated is the one callers receive.

• When you test the published version over an actual phone connection, audio pacing and handoff behavior are evaluated in realistic conditions, so final release decisions are evidence-based.
• When voice, version, and duration settings are selected deliberately, comparisons across iterations stay meaningful, which helps isolate changes that improve or degrade quality.
• When transcript and recording review follows each test, subtle breakdowns are captured quickly, so the next draft revision targets concrete issues.
• Your phone number: Where Hello Alex places the test call. Use a mobile you can answer right away.
• Voice: Which voice callers will hear on this test.
• Version: Which published snapshot to test. Production is the live default.
• Max duration: Caps how long the test call can run while you iterate.
• Good to know: run one final call after major transfer or IVR updates, because those behaviors are most sensitive to real network timing.

13. Versions, Staging, and Production

Every saved pathway keeps a numbered version, and each version sits in one of three places: your working draft, Staging, or Production. Separating where a change lives from what the change is means you can keep editing safely while callers stay on the version you already trust.

Next, use version history to compare what changed between two versions before you deploy.

• When you edit a pathway you are always working on the draft, so nothing you type reaches callers until you deploy it, which lets you rework a flow mid-day without interrupting live calls.
• When you deploy to Staging, that version becomes the one you can rehearse against with Chat & Test and Test Call, so behavior is proven on the exact snapshot before anyone answers it.
• When you deploy to Production, the version callers hear changes, which is why the Production card always names the version and the date it went live — so you can tell at a glance what is answering right now.
• When a pathway is created — from a script, the AI wizard, an interview, or a duplicate — it records its first version immediately, so version history is available from the very first save rather than appearing only after your first publish.
• Draft: Your unsaved and unpublished edits. Only you see them, and callers are unaffected.
• Staging: The version you rehearse against. Shows its version number, name, and when it was created.
• Production: The version callers actually hear, with the date it went live.
• Deploy to staging: Sends your current draft to Staging so you can test it end to end.
• Deploy to production: Makes a version the live one. Take this step after a Test Call on Staging looks right.
• Good to know: deploying to Staging costs nothing and changes nothing for callers, so it is the safe place to rehearse a rewrite before it goes live.
• Good to know: check the version number on the Production card before troubleshooting a reported issue, because the behavior someone described may belong to an older version than the one you are editing.

14. Version History and Compare

Version history lists every version a pathway has had, where each one currently sits, and what it was built from. Being able to read that trail matters because most pathway questions are really questions about what changed and when.

Next, publish or re-publish confidently and assign the validated pathway to your target number, campaign, or widget.

• When you compare two versions, the differences are grouped by Global Prompt, nodes, and connections, so a wording tweak is easy to tell apart from a change that re-routes the conversation.
• When you compare Staging against Production before deploying, you see exactly what callers are about to experience differently, which turns a deploy decision into a review rather than a guess.
• When an earlier version was better, you can restore it as your working draft and deploy from there, so recovering from a regression does not mean rebuilding the flow by hand.
• Branch: The version's name, and a marker showing whether it is currently on Staging or Production.
• Source: What the version was created from — a save, a duplicate, a restore, or a deploy.
• Updated: When the version last changed.
• Version actions: Rename a version so its purpose is obvious later, duplicate it to try an alternative, or remove one you no longer need.
• Good to know: rename versions with the reason for the change rather than a date, because 'shorter opening question' tells a colleague more in six months than 'v4' does.

Next step

Next, review the canvas layout so your baseline node flow is easy to audit before deeper logic changes.