Designing Call Flows

Effective call flows balance simplicity with functionality. This guide covers patterns, best practices, and common scenarios to help you design flows that work.

Flow design principles

Keep it short

Phone calls should be brief and focused:

  • Get to the point quickly

  • Limit menu options (3-4 max)

  • Provide an easy exit

  • Total call time: 30-60 seconds for simple messages

Handle every outcome

Every node should have paths for all possible results:

Dial
├── onAnswer → Continue flow
├── onVoicemail → Leave message or hangup
├── onNoAnswer → Hangup (retry later)
├── onBusy → Hangup (retry later)
├── onRejected → Hangup
└── onError → Hangup

Fail gracefully

When things go wrong, don't leave the caller confused:

  • Always have error paths

  • End with a polite hangup message

  • Log errors for debugging

Common patterns

Simple notification

Just deliver a message, no interaction needed:

Collect a response and branch:

Key considerations:

  • Repeat the menu if no input received

  • Handle invalid inputs gracefully

  • Provide a "repeat" option if menu is complex

Confirmation flow

Get explicit confirmation before proceeding:

Information collection

Gather multi-digit input:

Use multi_digit mode for account numbers, PINs, etc.

Conditional messaging

Different messages based on contact data:

Working with audio

Sequencing audio items

Audio items play in order:

Result: "Hello! Your balance is one thousand five hundred dirhams."

Dynamic content

Reference contact data for personalization:

Barge-in

Let users skip ahead by pressing a key:

Use barge-in for:

  • Long messages users might have heard before

  • Menu prompts where users know their choice

  • Time-sensitive situations

DTMF collection tips

Single digit menus

Keep it simple:

Best practices:

  • Use "1" for the most common action

  • Use "0" for operator/help

  • Use "*" for repeat

  • Use "#" for main menu

Multi-digit input

For account numbers, PINs, etc.:

Always tell users:

  • How many digits to enter

  • What key ends input (usually #)

  • What happens if they make a mistake

Retries

Give users multiple chances:

After max retries, route to a helpful ending—not a dead drop.

Answering machine detection

AMD helps you handle voicemails appropriately:

Voicemail options:

  • Leave a brief message

  • Hang up and retry later

  • Hang up with no message

Recording responses

Capture voice input when DTMF isn't enough:

Tips:

  • Keep max duration reasonable (30-60 seconds)

  • Play a beep before recording

  • Confirm recording was received

Testing your flows

Ad-hoc calls

Test with a single call before launching campaigns:

Test each path

Make sure you test:

  • Answering and completing the flow

  • Letting it ring (no answer)

  • Rejecting the call

  • Invalid DTMF input

  • Timeout scenarios

Check reports

Review the call report for details:

Look at the execution path to verify the flow behaved as expected.

Debugging common issues

Flow stops unexpectedly

  • Check that all nodes have outputs defined

  • Verify output node IDs exist

  • Look for typos in node references

Wrong audio plays

  • Confirm audio IDs are correct

  • Check audio was successfully uploaded

  • Verify variable references resolve correctly

DTMF not collecting

  • Increase timeout value

  • Check allowed digits match what users press

  • Verify barge-in isn't consuming the input

Condition always takes one path

  • Test with known data values

  • Check operator is correct

  • Verify variable reference syntax

Best practices summary

  1. Plan before building - Sketch the flow on paper first

  2. Start simple - Get basic flow working before adding complexity

  3. Handle all outcomes - Every node needs proper outputs

  4. Test thoroughly - Try every path before production

  5. Keep messages short - Respect your recipients' time

  6. Use descriptive labels - Future you will appreciate it

  7. Document complex logic - Use node descriptions

Next steps

Last updated