Building a Sequential Outbound Call Waterfall After a Missed Call — Looking for Architecture Advice

I’m building an inbound + outbound voice AI system and need help with the outbound piece.

The flow:

Client misses a call
Inbound agent picks it up, summarizes the call, and sends an SMS — this part is done
After the summary goes out, an outbound agent needs to work through a list of workers one by one until someone picks up

The waterfall logic:

Call Worker A
If no answer, call Worker B
If no answer, call Worker C
The moment any worker picks up, stop the chain, brief them on the call summary, and end

What I’m trying to figure out:

Where/how to store the worker list (and what’s the best approach for a client-managed list they can update themselves)
How to handle the call status detection — what’s the cleanest way to detect a no-answer and trigger the next call in the sequence
Any recommended tools or platforms for orchestrating this kind of sequential outbound waterfall

What’s the best way to architect this? Open to hearing what stack others have used.

Retell won’t do the waterfall for you, so that logic sits outside it.

Worker list. Airtable. One row per worker with name, mobile, priority order and an active toggle. Give the client a filtered view and they can reorder people or switch someone off without touching your automation. A Google Sheet does the same job for less. Move to Supabase once you are running this for more than a few clients.

No-answer detection. Use the webhook, not polling. If a call never connects, call_started does not fire but call_ended still does, so you always get an event back. Branch on disconnection_reason: the ones that matter are dial_no_answer, dial_busy, dial_failed, user_declined and voicemail_reached.

Set voicemail detection to hang up rather than leave a message, otherwise the agent briefs a voicemail box and your chain stops there. Worth handling answered-but-declined too. Have the agent set an accepted yes/no and keep the chain moving on a no.

Orchestration. n8n, built as a state machine rather than a loop. Workflow A creates an escalation record and dials worker 1, passing escalation_id in metadata and the summary in retell_llm_dynamic_variables. Workflow B catches the webhook, checks the record is still open, then dials the next worker or closes it out. Holding state in the record instead of a Wait node means a redeploy mid-chain does not lose the escalation.

One thing to flag with your client: there is no documented ring timeout, so each unanswered leg runs to the carrier default, around 25 to 30 seconds. Three workers is roughly 90 seconds before anyone speaks.

What are you using for the SMS piece?

Russell
amplifyautomation.ai

Hello @jessekstrachan1

1. Storing the Worker List

Store the worker list in your own backend (database, CRM, etc.). Retell doesn’t manage contact lists natively. For client-managed lists, expose a simple CRUD UI/API on your side. When triggering each outbound call, pass the current worker’s number dynamically via the Create Phone Call API.

2. Waterfall / No-Answer Detection

This can be handled using Retell’s native call events. Trigger the call to Worker A, then listen for the call_ended webhook. When a call doesn’t connect, the webhook includes a disconnection_reason. Check for dial_no_answer, dial_busy, or user_declined, which have call_status: not_connected. If there’s no answer, trigger the next call to Worker B, and continue the sequence. If the call is answered and completed, such as with user_hangup or agent_hangup, stop the chain.

3. Passing the Call Summary

Use retell_llm_dynamic_variables when creating each outbound call to pass the inbound call summary into the outbound agent’s prompt:

retell_llm_dynamic_variables: {
  call_summary: "Caller John asked about invoice #1234..."
}

Then reference {{call_summary}} in the outbound agent’s prompt.

4. Voicemail Handling

Configure voicemail_option: { action: { type: "hangup" } } on the outbound agent so it automatically hangs up when voicemail is detected. The resulting voicemail_reached disconnection reason can then be handled by your webhook in the same way as a no-answer.