Plan a useful fallback when an AI service is unavailable

An unavailable AI service need not make every part of a business workflow unavailable. Separate essential work from optional assistance before an outage occurs. A useful fallback lets users continue safely, explains what is missing, and keeps the system from compounding the original failure through repeated calls or uncertain actions.

Decide what must continue

Map the workflow into independent steps. Users may still be able to open source documents, enter required information, and submit a manual request when generated suggestions are unavailable. Identify which steps depend on the model and which can proceed without it. Preserve the user’s entered content before displaying an error.

Do not replace an unavailable answer with a plausible default that appears authoritative. Label reduced functionality and provide the approved alternative. For a document assistant, that alternative may be direct search or a source link. For a drafting assistant, it may be a blank editable form containing the user’s original inputs.

Stop repeated failing calls

Microsoft’s Circuit Breaker pattern temporarily blocks calls after failures reach a threshold, rather than repeatedly invoking an operation likely to fail.[8] Its guidance distinguishes this mechanism from retries intended for transient faults.[8] Select the behavior according to the dependency failure, not merely the desire to hide an error message.

Give model requests a bounded waiting period and a controlled retry policy. Explain when the request remains pending and when the user should take the manual path. Switching providers is a separate design decision. Do not automatically send customer content to another provider without checking its permissions, data handling, and task behavior.

Fallback readiness checks

Exercise these conditions with the people who operate the workflow. A fallback that exists only in a technical document is not enough for a busy service desk.

• Preserve entered information when a model request times out.
• Show whether any external action occurred or whether its result remains unknown.
• Provide a manual route with a responsible team and required context.
• Limit retries and make dependency health visible to operators.
• Test recovery without duplicating pending messages, bookings, or record changes.

Hypothetical example: a service intake form

A hypothetical maintenance business uses AI to suggest a fault category from a customer’s description. During an outage, the form still accepts the description and contact details. It marks classification as pending and routes the request to staff instead of inventing a category.

When the service returns, the application does not overwrite a category already chosen by an employee. If notification delivery was uncertain, it checks the delivery record before sending again. Pending classification and pending notification remain separate states because they require different recovery decisions.

Recover with a deliberate handoff

Assign ownership of pending work and define when automated assistance may resume. Compare incoming demand with the manual team’s capacity and communicate longer handling times where needed. A fallback can preserve a useful minimum service, but it may offer less convenience or slower throughput. Make that limitation explicit before users rely on it.