How outbound dispatch works (queue, calling window, concurrency)
Last updated: September 19, 2026
When your CRM workflow triggers a call, the lead is queued at the head of your agency's outbound queue and dialed immediately — the dial starts right after GodSetter answers your workflow, usually within seconds. A dispatcher running every minute is the safety net: it picks up anything the instant path could not dial (no free slot, a closed window, a transient error) plus every retry and callback that has come due, all under the rules you set — the calling window, the concurrency cap and a set of safety gates checked right before dialing.
Understanding this pipeline answers most "why hasn't this lead been called yet?" questions.
From trigger to queue
Two ingresses feed the same queue: the per-agent webhook URL you paste into a
workflow, and the "Start call cycle" GoHighLevel marketplace action. Either
way GodSetter validates the request and answers
{"status":"enqueued","leadId":"…"} — the lead is now at the head of your
agency's queue and the first call is already being placed. If an activation gate
fails at this entry point (inactive client or no calendar, agent without numbers,
agent set to Inbound, missing consent in strict mode, blocked lead), the
response is skipped with a reason instead, and nothing is queued. See
Wire your CRM workflow to an agent
for the setup side.
Re-triggering a contact who is already in the system restarts their call plan: the first call is queued again and the old plan's parked retries are swept away (callbacks the lead explicitly asked for survive).
In the other direction, a booking — made in-call, or made by the contact outside a call and reported by the appointment webhook or marketplace action — stops the cycle: every scheduled redial for that lead is removed.
What happens every minute
On each tick the dispatcher processes your agency in this order:
- Promote scheduled calls — retries from an agent's retry plan, lead-requested callbacks and calls parked by a closed window that have come due are moved into the queue, so they dispatch in this same tick.
- Calling window — the window is evaluated per agent: an agent inherits the agency window (Settings → Calling window) or defines its own, in a fixed time zone, the sub-account's or the contact's. A lead whose window is closed is parked until that window's next opening — no attempt is consumed and nothing is lost. Two opt-ins escape the window: the agent's "Even outside the calling window" switch for the first call, and "Call at the agreed time even outside the calling window" for callbacks the lead asked for. Retries always respect the window.
- Dial up to the effective concurrency cap — the ceiling is the LOWER of your Maximum concurrency setting and your Retell workspace limit minus the lines Retell reserves for inbound. Inside that ceiling, the Slots reserved for first calls (20% by default) are off-limits to retries, so a backlog of redials can never starve a lead who just filled the form. Dials are paced at your Calls per second (Twilio) rate. Whatever doesn't fit waits for the next minute.
- Final per-lead checks — each lead is re-checked immediately before dialing (table below). The call then goes out from one of the numbers assigned to the dispatched agent.
A tick handles at most 200 items per agency; a larger backlog simply continues on the following ticks.
Dispatch gates at a glance
| Gate | What happens if it fails |
|---|---|
| Agent direction is Outbound | Refused at the entry point (skipped: inbound_agent); an item already queued for an agent flipped to inbound is dropped and raises a queue-drop alert |
| Inside the agent's calling window | The lead is parked until the window's next opening; nothing is consumed |
| Retell connected for your agency | Your agency is skipped entirely this tick |
| At least one active number in the pool | The dispatcher skips the tick; queued leads wait |
| Active calls below the effective concurrency cap | Remaining leads wait for the next minute; retries also wait while only the reserved first-call slots are free |
| Agent has assigned active numbers, registered on Retell | The lead is skipped — fail-closed, never dialed from an unassigned or unregistered number |
| Lead not blocked (Do-Not-Call) | The lead is skipped |
| The lead's client is still active | The lead is skipped — a deactivated client, or one whose CRM sub-account was deleted or uninstalled the app, is never called for (its queued calls are dropped the moment the CRM tells us) |
Every gate that stops a lead is written on the lead itself: the Leads page shows a Skipped: … badge with the exact reason (no number assigned to the agent, missing consent, contact blocked, no registered number assigned, missing phone, client deleted, client not active, no agent for the client, agent deleted). The badge clears as soon as the lead is actually dispatched, so what you see is always the last thing that happened.
This is the dispatch-time view only. For the full step-by-step diagnostic, use Calls are not firing — full checklist.
Transient errors are retried, then alerted
If starting a call fails for a transient reason — for example a brief error from Retell — the lead goes back into the queue and is retried on a later tick, up to 3 attempts. After the third failure the item is dropped and an in-app alert appears on your Dashboard (and by email — to the alert address set in Settings, or the agency owner's email if none is set). This is different from the per-agent retry plan, which reacts to call outcomes like no answer or voicemail; this mechanism handles calls that could not start at all.
Every agency is isolated
Your queue, your scheduled calls and your concurrency counter belong to your agency alone. Another agency's volume never consumes your concurrency or mixes with your leads, and every call is placed — and billed — through your own Retell and Twilio connections.