A customer asks to change a delivery. The assistant times out. A support agent picks up the request, while a background retry wakes up and sends a second answer—or repeats the change. The visible failure was a silent chatbot; the operational failure is that nobody can prove what was received, promised or completed.
For customer-service continuity owners in Belgium and the Netherlands, recovery needs a separate workflow from ordinary ticket routing. Keep intake, ownership, business actions and message delivery independently traceable. The goal is not merely to make the model respond again: it is to resume service without losing requests or contradicting work already done.
First establish which part has failed
Separate the customer channel, your intake endpoint, the model provider, downstream tools and outbound delivery. A model outage can leave message receipt working normally. A broken webhook can mean your application never received the request. A successful CRM update followed by a failed reply is a third situation, requiring reconciliation rather than another update.
Use application-level probes alongside provider status pages. Test whether a synthetic request reaches durable storage, whether a worker claims it, and whether a test reply produces the expected receipt. Do not use real customer data in probes. Review the selected provider's current status, applicable availability contract, retry limits and exclusions; an SLA is not evidence that an individual request arrived.
Twilio's service-level agreement is an example of the contract to review, not a promise about your complete support service. Your channel, model, CRM and staff coverage have different failure boundaries. Assign one incident owner to decide the current operating mode.
A degraded-service state diagram the team can operate
Use the following state path as a reusable operating artifact. Each transition needs a named owner and evidence, not a model's opinion:
- Normal → degraded: intake or processing probes fail, or delivery uncertainty exceeds the agreed threshold. Pause automated business actions and open an incident.
- Degraded → manual-owned: durable requests remain visible; staff claim individual conversations before replying. Automatic workers cannot act on those claims.
- Manual-owned → recovery review: dependencies pass probes; reconcile message receipts, completed actions and unowned backlog items.
- Recovery review → limited restart: the incident owner authorises a small, monitored queue with safe actions only.
- Limited restart → normal: reconciliation and quality checks pass. Any renewed ambiguity returns the system to degraded mode.
Keep an independent degraded-service notice available where feasible. Say whether receipt is confirmed, what remains unavailable, and which staffed alternative exists. Never display “we saved your request” unless durable intake succeeded. Prepare complete English, French and Dutch notices and test routing to the correct language queue. An acknowledgement is not a promised resolution time.
Preserve intake before asking AI to do anything
Persist a verified inbound event before acknowledging it to the provider, within that provider's timeout contract. Capture the channel event ID, conversation ID, tenant, receipt time, language, permitted request content and processing state. Validate webhook authenticity and restrict attachment handling. Keep model execution outside the acknowledgement path.
Deduplicate repeated deliveries using the provider's stable event identity within the correct account scope. Do not use message text alone: a customer can legitimately ask the same question twice. Twilio's webhook documentation describes configurable timeouts and retry policies, including an idempotency-related header. Verify the semantics for your exact product; do not assume a retry header is the permanent business-request identity.
If storage fails, follow the provider's documented failure response and retry contract, and alert the incident owner. Do not return success just to clear an alert. If the channel itself is unavailable, use an independently hosted status notice or a genuinely available alternative; no application can guarantee capture of messages that never reach it.
Give each conversation one effective owner
Make manual takeover an atomic claim in the system of record. Record owner, claim time, incident, ownership version and permitted actions. Every automatic worker must recheck that version immediately before an external action. A worker that began before takeover must not retain authority after it.
A claim timeout alone does not prove that a human stopped working. Reassign abandoned work through an explicit supervisor decision or a controlled lease protocol. Expiring ownership while an agent is composing a reply can recreate the race you intended to prevent.
The agent view should show the original request, latest customer-visible reply, pending delivery attempts, completed business actions and unresolved uncertainty. This complements ordinary AI helpdesk triage and routing: outage recovery is about preserving authority and evidence, not predicting the best ticket category.
Reconcile replies separately from business actions
Use an action ledger and an outbound-message ledger. Give each intended business action a stable key, such as the request plus a specific approved amendment. Store the downstream transaction reference and read back its outcome. Give each reply its own attempt record, provider message ID and delivery state. Never treat “the API accepted it” as “the customer received it”.
Twilio's outbound status documentation distinguishes queued, sent, delivered and failure states, with channel-specific behaviour. Not every channel supplies the same evidence. Authenticate callbacks, tolerate duplicate and late events, and avoid letting a stale callback overwrite a later confirmed state.
After a send timeout, mark the outcome uncertain. Query by the stored provider reference or reconcile callbacks before retrying. If no reference exists and the provider offers neither lookup nor idempotent sending, isolate that item for human review. A second blind send is not recovery. Likewise, if a booking succeeded but its confirmation failed, restore communication about that booking instead of making another booking.
Do not promise universal exactly-once delivery. Amazon SQS documents at-least-once delivery for standard queues and advises idempotent consumers. Even a queue with stronger guarantees does not automatically make a separate CRM write or customer message exactly once.
Drain the backlog without restarting every conversation
Build a recovery view with four groups: already completed; manual-owned; safely replayable; uncertain. Suppress completed actions, leave owned conversations with their agents, and review uncertain outcomes before any replay. Recheck deadlines and the latest customer message: a request to cancel can supersede an earlier request to book.
Replay a small batch with rate limits and stop conditions. Check current permissions, entitlements and downstream records again; a pre-outage model answer may now be stale. Keep automatic refunds, contractual changes and security-sensitive disclosures disabled until the responsible human authorises them. Restore broader operation only after the incident owner reviews both backlog integrity and fresh traffic.
A practical replay drill and measurement plan
Before launch, run this drill in a sandbox with synthetic English, French and Dutch conversations. These are proposed acceptance checks, not claimed customer results:
- Repeated inbound event: deliver it twice; expect one durable request and no duplicate action.
- Model unavailable: verify truthful acknowledgement, visible backlog and manual claim.
- Action succeeds, response times out: recover the existing transaction reference without repeating the action.
- Late delivery callback: reconcile the first reply before permitting another send.
- Human takeover during processing: reject the old worker's authority before its next side effect.
- Restart followed by another failure: stop the replay batch and retain every item's state.
Baseline normal and incident-period volumes separately. Measure durable-intake success, time to detect failure, oldest unowned request, time to a meaningful human response, uncertain sends, duplicate replies, duplicate business actions and backlog age by language. Count unresolved items explicitly; excluding them makes recovery appear faster than it was.
For a first Belgian or Dutch rollout, choose one channel, one staffed queue and a narrow action set. Have customer operations own the runbook, engineering own receipt and action reconciliation, and the privacy lead review retained content, access, processors and deletion rules. Set observation periods and thresholds before the drill. A duplicate customer-impacting action or cross-account exposure should stop the release, not disappear into an average.
Where this approach works—and its limits
This works when the channel provides stable event references, intake is durable, manual staff have capacity, and downstream actions can be reconciled. It cannot reconstruct undelivered inbound messages, guarantee human coverage outside agreed hours, or prove a customer's understanding from a delivery receipt. Minimise stored personal data and define retention for both operational ledgers and transcripts; a continuity plan is not permission to archive everything indefinitely.
Evaluate conversational AI services against this recovery contract rather than demo response speed. Teams in the Netherlands and Belgium can start with one replay drill and one accountable queue. Discuss your continuity boundary with Intyb before expanding automated authority.