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 → HangupFail 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:
Menu with options
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
Plan before building - Sketch the flow on paper first
Start simple - Get basic flow working before adding complexity
Handle all outcomes - Every node needs proper outputs
Test thoroughly - Try every path before production
Keep messages short - Respect your recipients' time
Use descriptive labels - Future you will appreciate it
Document complex logic - Use node descriptions
Next steps
Audio Management - Prepare your audio files
Call Flows Reference - Complete node documentation
Building Your First Campaign - End-to-end example
Last updated

