Your AI Outage Plan Needs a Human Handover

Three AI subscriptions do not tell your team who takes over when the workflow stops. A rehearsed handover does.

An alternative chatbot is not a continuity plan

A business can have three AI subscriptions and still have no workable way to serve a customer when its automated workflow stops. The missing piece is usually not access to another model. It is a clear answer to a much simpler question: who takes over the work, using which information, and with what authority? Buying another assistant does not settle any of those decisions. A team needs a way to continue the service, not merely a different screen on which to ask for help.

The Cloud Security Alliance's 19 September continuity research note describes overlapping disruption across OpenAI, Anthropic and xAI on 3 September 2026, within the same three-hour window. It does not establish one shared technical cause. The useful business lesson is narrower: having more than one provider available on paper does not guarantee that your alternative will be usable when needed.

That distinction matters for a UK service business using an agent to organise incoming enquiries. The website form might still accept requests while the classification step fails. Staff may assume the quiet task board means there is nothing to do. Customers, meanwhile, believe their requests have entered the usual process. The service has not disappeared in an obvious way; its connection to the people doing the work has broken.

Start by defining the smallest useful service you must maintain. That might be acknowledging urgent enquiries, confirming appointments already agreed, and making sure a person sees any safety-related message. Marketing summaries and routine internal reporting can wait. This is a planning recommendation, not a claim that every business needs round-the-clock model availability. Protect the commitments customers rely on before protecting every convenience that automation provides.

Protect the customer commitment, not every automated convenience.

Write a handover card that works without the agent

For each important workflow, create a short handover card in a place the team can access without asking the failed AI system. Use the tools you already operate: an approved shared document, a CRM view, a service desk procedure or a printed copy where appropriate. You do not need a new bespoke continuity platform to write down who owns a customer request. First check whether the current business continuity plan already provides the right location and escalation route.

The card should identify the workflow owner and a deputy, the incoming work source, the customer commitment being protected, and the point at which staff switch to manual handling. It should also explain where the latest reliable work list can be found. Keep credentials out of the card. Refer people to their normal approved access route instead of creating a shared emergency password that nobody can govern afterwards.

Here is a hypothetical example. An installation company normally uses an agent to sort service requests into its CRM. Its handover card tells the duty manager to open the original enquiry inbox, identify urgent requests against written criteria, assign a named colleague, and record the reference in a shared intake list. The colleague does not need to reconstruct a conversation with the agent before responding. The source request and the operating rule are available independently.

In practice, include a specimen completed record. Staff should see what a useful handover looks like: request reference, received time, customer need, known commitment, current owner, next action and any uncertainty. A procedure that only says to continue manually leaves all the hard decisions for the incident itself. Ask a deputy who did not write the card to use it on a sample request. If they need the author to explain the basics, the handover is not yet ready for use.

A handover procedure is ready when someone other than its author can use it.

Plan for reduced capacity, not business as usual

Manual handling will often be slower than the normal AI-assisted workflow. Pretending otherwise creates a second incident: staff accept the usual volume and service promises while working with less capacity. Decide in advance which work continues, which work waits, and which customer messages must change. Business continuity is the ability to maintain an acceptable service through disruption, not a promise that nobody will notice anything has happened.

The NCSC's preparation guidance published on 1 October 2026 sets out four areas: business continuity, people, technical recovery and critical decisions. Although framed around disruptive cyber incidents, that separation is useful for an ordinary supplier outage too. An engineer restoring access and a manager deciding what to tell customers have related but different jobs. Neither should have to guess the other's authority.

Use a simple capacity exercise rather than an unsupported industry percentage. Suppose, purely as a planning example, your team normally receives 40 requests in an afternoon but can manually assess only 15. The question is not how to persuade people to work nearly three times faster. It is which 15 should be assessed first, what acknowledgement the others receive, and when another person is called in. Replace those illustrative numbers with observations from your own rehearsal.

What this means in practice is that the fallback needs a service policy. Acknowledge receipt without promising a completion time the team cannot support. Give urgent cases a clear route to a person. Decide whether routine requests can wait until the next working day. Make any temporary wording accessible and understandable, including for people who cannot use a web form or chatbot. The continuity owner should approve those choices before an outage, then review them as the incident develops. A documented reduced service is more useful than an optimistic plan that nobody has the capacity to deliver.

Reduced capacity needs an agreed service policy, not heroic assumptions.

Keep recovery information outside the failed conversation

An agent conversation can be useful working context, but it should not be the only place your business records a commitment. A colleague taking over needs to distinguish a suggestion from an approved decision, and an intended action from something actually completed. If that distinction lives only inside a chat history that cannot be reached during an outage, the manual team starts by guessing. Continuity depends on accessible business records, not the apparent confidence of the assistant that created them.

Build the ordinary workflow so important facts reach the system your team already treats as authoritative. That may be the CRM for ownership and next actions, the booking system for confirmed appointments, and the service desk for customer updates. Record the source reference and enough context for another person to continue. Do not duplicate every prompt or every personal detail into an emergency spreadsheet. More copies can create confusion about which record is current and increase the amount of sensitive information exposed.

There is a live UK policy discussion here, but its scope needs care. The government's agentic AI resilience factsheet, updated on 3 November 2026, describes proposals for regulated entities, including evidence preservation and post-incident review. These are intended future measures following consultation and parliamentary scrutiny, not a blanket new duty imposed on every small business by that page. A supplier outage is also not automatically an agentic loss-of-control incident.

The practical recommendation is independent of that legislative debate: retain the records needed to understand what happened, under your existing security and retention rules. For a customer request, that means the original request, confirmed commitments, ownership and the next safe action. For an incident, it means a short timeline of the disruption and the decisions made. Keep access limited to people who need it, and agree how temporary working records will be reconciled and removed afterwards.

Your recovery record must distinguish a proposal from a confirmed commitment.

Rehearse the switch back as well as the switch off

The strongest objection to a manual fallback is reasonable: if automation handles substantial volume, surely another approved model is the only realistic alternative. Sometimes it is. A business processing large amounts of time-sensitive work may need a validated secondary provider, an alternative technical route, or contractual support. The mistake is treating that arrangement as self-proving. The second route still needs the right permissions, data-handling approval, task quality and staff familiarity. It must also remain usable when the primary route fails.

Info-Tech's 4 September analysis makes the distinction between overlapping outages and a demonstrated common cause, and highlights the problem of hidden dependencies. You should therefore test the route your people actually use, including sign-in and access to the work list. A backup assistant that shares an unavailable identity service will not help the colleague waiting to serve a customer. Check actual dependencies rather than inferring independence from different brand names.

Run a bounded exercise on non-critical sample work. Make the normal agent unavailable, ask the deputy to find the handover card, and observe whether they can locate the incoming requests, prioritise them, communicate a delay and record progress. Measure time to useful manual operation and the requests left unassigned. These are your own exercise results, not universal benchmarks. Repeat after material workflow changes, and choose a review frequency that reflects the consequence of interruption.

Finally, rehearse returning to normal. The manager needs a clear list of manually handled work, outstanding requests and unresolved uncertainties. Confirm access has recovered, check a small representative task, reconcile the working list with the authoritative system, and let the accountable owner release normal processing. For the separate technical issue of preventing repeated actions, see our guide to AI-agent retries and duplicate business actions. The broader point here is ownership: recovery finishes when the team can explain the state of its customer work, not simply when the provider's status page turns green.

Recovery finishes when the team understands its work, not when a status page turns green.