The calendar works and the form loads, but the AI provider does not answer. If the whole enquiry disappears, the intelligent layer was coupled too tightly to intake. A degraded mode keeps the essential process alive without pretending the unavailable step succeeded.
Define the minimum service first
| Function | During outage | Later |
|---|---|---|
| Accept enquiry | Always store it | Classify later |
| Notify customer | Neutral receipt | Skip personalisation |
| Book appointment | Pause if needed | Review manually |
| Create summary | Keep raw input | Generate later |
The worst fallback says everything is complete. A better message is precise: “We received your request. Our team will review it.” The customer gets certainty without a false promise.
Timeouts, retries and queues are one design
- A short timeout instead of a spinner lasting minutes.
- Limited retries with backoff, never endless hammering.
- One transaction ID to prevent duplicate execution.
- A visible queue showing age and status.
- An alert only when a threshold requires action.
On recovery, do not resend every old task blindly. Check whether the target action may have completed despite the timeout. That is where duplicate-action protection and reconciliation meet degraded operation.
You can test this without waiting for a real outage: delay a response, return an error and cut the connection. Every enquiry must then be either completed correctly or visible to a person. “It is in a log somewhere” is not a fallback.
Sources
FAQ
What is degraded mode?
A deliberately reduced service that preserves essential work while an AI function or external provider is unavailable.
Should the system retry automatically?
Yes, within strict limits, with backoff and a unique transaction ID.
What should the customer see?
An honest confirmation of what was actually saved and a realistic next step.
How can an outage be tested?
Simulate timeouts, error responses and disconnected services in a controlled environment.