Building call flows
Write prompts for the ear, store what callers enter, branch on it, and call your own systems while the caller waits.
Writing for the ear
A phone call has no screen. Everything the caller knows, they heard once.
- At most four or five options. By the sixth, the first is forgotten.
- Say what silence means. Before an API call or a transfer, tell them: "One moment while I check that."
- Confirm what you captured. "I have four-two-one-nine. Press 1 if that is right."
Prompts are either Text to speech or Uploaded audio from the workspace audio library. Only spoken text is filled in with variables; an uploaded recording plays exactly as it was made.
Variables
Collect Input stores the caller's answer under a variable name you choose. Read it back in any spoken prompt:
Collect Input → variable: accountNumber
Play Message → "Thanks. Looking up {{state.accountNumber}} now."| Write | To read |
|---|---|
{{state.accountNumber}} | A value collected or set earlier in the call |
{{input}} | What the caller just entered |
{{session.from}} | The caller's number |
Outbound flows also start with variables already set: whatever the trigger sent. See Outbound calls and Variables.
Branching
Menu (voice) branches on a keypress, with one handle per option.
Router branches on a condition, and is what you use for anything that is not a keypress. Write conditions as rules, not JavaScript: the call engine does not run JavaScript in conditions, so a branch written that way never matches, and the canvas flags it as an error.
Date & Time → Router
├─ open ─→ Main Menu
└─ else ─→ After-hours MessageFilter continues only when a condition holds.
Calling your own systems
The API node runs mid-call. The caller is on the line, so:
- Keep it fast. Play "one moment" first.
- Wire its failure path. An API that times out must not leave the caller in silence: send them to a person, or apologise and offer the menu again.
Responses land in variables and can be spoken straight back.
Retries and timeouts
Menu (voice) and Collect Input both retry before giving up:
- If they press something else: plays a correction and asks again.
- If they press nothing: the same, for silence.
- After the retry limit, the flow takes the corresponding exit.
On the Menu node, Wait for input (seconds) defaults to 5 and Retries before giving up to 2.
Correction prompts should say what to do, not what went wrong: "Please press 1, 2 or 0" beats "invalid selection".
Business hours
The usual shape, and worth building early:
Incoming Call → Date & Time → Router
├─ open ──────→ Main Menu
└─ closed ────→ After-hours Message → Record (voicemail) → End CallUse Date & Time to get the current time and Record in voicemail mode to take a message.
Validating as you build
The canvas checks the flow as you work and lists errors and warnings. Examples:
- Incoming Call, Collect Input or a menu option that goes nowhere
- A menu with no prompt, no options, or the same key twice
- Collect Input with no variable name
- Nodes that are never reached
- Capability mismatches with the carrier on the number's route, such as speech input on a carrier without speech recognition
Publishing also compiles the flow and refuses one the call engine cannot run. See Testing and deployment.