A phone call may feel like a single event, but the software around it rarely is. Audio processing, transcription, classification, booking, notifications, and human follow-up all happen in separate systems. Any one of them can time out and retry.
That is healthy distributed-system behavior. The operational problem begins when a retry looks like new work. A business can end up calling the same lead twice, creating two calendar events, or sending repeated notifications about one conversation.
The safest design is to treat follow-up as an idempotent workflow with an explicit state machine.
Start with one stable call identity
Assign a durable call ID as soon as the call enters the system. Carry it through transcription, analysis, webhooks, and downstream tasks. Provider event IDs are useful evidence, but they should not become the only business identity: providers can emit several events for the same call.
Every derived object should record both the stable call ID and its own purpose. A callback task might use a key such as call:{callId}:callback . A booking attempt might use call:{callId}:booking:{requestedSlot} .
The key answers a simple question: if this command arrives again, is it new work or the same intent repeated?
Model the work, not just the webhook
A useful follow-up state machine is small:
-
Received: the completed call and its outcome are recorded.
-
Classified: the system has decided whether the call needs a callback, booking, message, or no action.
-
Assigned: one owner or queue has accepted responsibility.
-
Acknowledged: a human or downstream system has confirmed the action.
-
Resolved: the action is complete, cancelled, or intentionally closed.
Transitions should be conditional. Moving from classified to assigned succeeds only if the record is still classified. If two workers race, one wins and the other reads the already-updated state instead of creating a second task.
Put idempotency at every side-effect boundary
Preventing duplicate queue messages is not enough. Each external side effect needs its own protection.
-
Callbacks: create at most one active callback task per call and reason.
-
Calendar bookings: send an idempotency key when the provider supports one; otherwise store the attempt before calling the provider and reconcile uncertain results.
-
SMS or email: record a notification intent and its provider message ID.
-
CRM updates: use an upsert keyed by the source call and activity type.
Do not mark an action complete before the external system confirms it. Also avoid blindly retrying after an ambiguous timeout. The request may have succeeded even if the response was lost.
Use leases for ownership, not permanent locks
Human follow-up needs ownership, but workers and browsers disappear. A short lease is safer than an indefinite lock. Store the owner, lease expiration, and attempt count. Renew while work is active. If the lease expires, another worker can recover the item without inventing a new task.
The user interface should show the same state: who owns the item, when it was assigned, and whether a retry or reassignment occurred. Hidden queue mechanics become understandable operations when the audit trail is visible.
Reconcile uncertain outcomes
Retries alone cannot repair every partial failure. Run a reconciliation job that compares internal intents with provider reality.
Examples include a booking attempt stuck in pending while the calendar already contains the event, a notification marked sending when the provider delivered it, or a callback task whose underlying call was already completed. Reconciliation should repair state, not duplicate the side effect.
Measure duplicates as an operations signal
Useful metrics include duplicate-command rate, prevented side effects, time spent in each state, expired leases, reconciliation repairs, and manual reopenings. A rising duplicate-command rate often points to an upstream timeout or webhook-delivery issue even when customers never see duplicate work.
Keep the prevention metric. If the system quietly blocks 200 duplicate commands, that is not “nothing happened”; it is evidence that a boundary is absorbing retries correctly.
Roll out in stages
-
Log stable identities and proposed idempotency keys without changing behavior.
-
Create the state record alongside the existing workflow.
-
Enforce uniqueness for one low-risk side effect, such as an internal callback task.
-
Add provider reconciliation before enforcing booking or notification deduplication.
-
Review prevented duplicates and false merges with operators.
The goal is not to eliminate retries. Retries are necessary. The goal is to make repeated delivery safe and observable.
A product context
AI receptionist products sit directly on this boundary between a real-time conversation and slower business operations. SkipCalls is one example of a product designed around capturing calls and turning their outcomes into useful follow-up. Regardless of the implementation, the same rule applies: one caller intent should produce one accountable piece of work.
When identity, state, ownership, and reconciliation are explicit, operators can trust automation without losing the ability to understand what happened.