Your AI Manual Fallback Needs a Capacity Test

Agentic Business Design

30 October 2026 | By Ashley Marshall

We can always do it manually is not a continuity plan. It is a capacity claim that most teams have never tested.

A manual fallback is a service promise, not a sentence

Your AI assistant stops processing customer requests. Someone says the team can do the work manually. That sounds reassuring until you ask how many requests the team can complete, which customers go first, and what happens to everything already halfway through the workflow. A manual fallback is only credible when those questions have answers. The problem is not whether a person can perform one task. It is whether the business can maintain an acceptable service while new work keeps arriving.

The Office for National Statistics reported on 8 October that 30% of businesses used at least one AI technology in September 2026. Among businesses with 250 or more employees, the proportion was 51%. These are survey estimates, classified as official statistics in development, not proof that every adopter runs critical operations through AI. They do show why leaders should identify where an optional assistant has quietly become a dependency. See the ONS bulletin and its methodological qualifications.

Start with a customer-facing outcome rather than a model name. For a maintenance company, the outcome might be acknowledging urgent repair requests and assigning an engineer. For an accountancy practice, it might be capturing incoming documents without losing a filing deadline. Drafting a polished acknowledgement is less important than ensuring that the right person sees the request and accepts responsibility for it.

Write a reduced-service promise for each important workflow. State what continues, what waits, who owns the decision and what customers will be told. Do not promise normal throughput if you have only tested a single employee handling a single example. The fallback should describe an operating mode the organisation can actually sustain, not an optimistic paragraph copied into a continuity document.

Measure demand against available human capacity

The simplest useful capacity test uses three inputs: incoming items per hour, minutes required to complete an item manually, and staff time genuinely available during disruption. Include checking, record updates and customer communication in the handling time. Excluding these activities creates a comforting number that the team will never achieve. Use representative work, including awkward cases, rather than the cleanest examples from a demonstration.

Consider an illustrative service desk receiving 60 requests an hour. Four available colleagues can each complete six requests an hour after allowing time for the full task. Combined manual capacity is 24 requests an hour, leaving 36 additional requests waiting every hour. After a four-hour interruption, the new backlog is 144 requests, before any unfinished work from the automated process. These numbers are a worked example, not a claim about a client or an industry benchmark.

What this means in practice is that 'everyone will help' is not a capacity plan. Colleagues may already be answering phones, handling exceptions or covering absence. Count only the hours that an accountable manager can release. Test the arrangement with ordinary staffing and again with a key person unavailable. The result should show how long the reduced service can continue before deadlines or customer commitments become unrealistic.

Agree thresholds using the business consequence of delay. An urgent safety-related request should not share a waiting limit with a routine brochure enquiry. Monitor the oldest unresolved item as well as the item count, because a small group of neglected cases can be more serious than a large group of recent ones. Revisit the calculation when automation increases demand or staff are reassigned. An old manual baseline does not remain valid simply because the software configuration is unchanged.

Design a smaller service before an incident forces one

A good fallback does not necessarily reproduce the automated workflow by hand. It preserves the most important outcome with fewer steps. You might stop generating personalised summaries, suspend non-urgent enrichment and use a standard acknowledgement while people classify urgent cases. The aim is controlled degradation: customers receive a narrower, clearly explained service instead of an unreliable imitation of normal operation.

The NCSC's business continuity guidance published on 1 October 2026 says organisations should identify critical services, assess feasible workarounds, prepare the resources needed and prioritise restoration. It explicitly recognises that full business as usual may not be possible during a disruptive cyber incident. Applying that principle to AI service interruption is an operational design choice, not a claim that every model outage is a cyber attack.

For an AI-supported order desk, create three temporary lanes. The first covers orders with an immediate contractual or safety consequence. The second covers work that can wait within an agreed period. The third covers optional activities that can pause completely. Give each lane an owner and a plain-language entry rule. Make the rules available outside the affected assistant so staff do not need the failed system to discover how to continue.

What this means in practice is that a supervisor can reduce demand as well as add people. A clear website notice, an honest revised response time and a pause on non-essential automated campaigns can prevent avoidable contacts. Keep necessary access controls in place: an emergency spreadsheet should not become an unrestricted copy of the customer database. Decide where temporary records live, what fields are necessary and how they will be transferred back. A smaller service still needs accurate records and clear responsibility.

Another model is useful, but it is not the whole fallback

The strongest counterargument is straightforward: why retain a manual route when another AI provider can take over? For some tasks, an approved alternative is an excellent way to maintain capacity. The mistake is treating a second subscription as a tested substitute. The alternative must be able to access approved inputs, perform the actual task and meet the same checking requirements. Otherwise you have changed the interface without restoring the service.

September reporting offers a useful caution against assuming that different brand names guarantee uninterrupted availability. MarketScale's September report, drawing on CIO coverage, described ChatGPT, Claude and Grok experiencing outages within hours of one another on 3 September. That reporting does not establish a shared technical cause. It does underline why a continuity plan should test its assumptions rather than simply count suppliers.

Map the dependencies that the alternate route still needs. Your second model might use the same identity provider, internet connection, integration platform or customer system as the primary model. If that shared component fails, switching model providers will not retrieve the work. Equally, an alternate service may not have approval to receive the same personal or commercially sensitive information. Disruption is not permission to bypass procurement and data-handling decisions.

Test substitution with representative inputs before making it part of the operating plan. Record which tasks it can handle, what review it needs and when it must refuse or hand over. Keep the manual route proportionate: a low-impact internal drafting tool may only need a pause-and-resume instruction, while an urgent customer process needs an available human owner. Resilience comes from choosing a workable combination of alternatives, reduced service and manual capacity, not insisting that every process always needs two models.

Rehearse the switch and the return to normal

The difficult moment is often not the outage itself but the transition. An agent may have prepared a reply without sending it, updated one system but not another, or scheduled a retry that will execute after staff have already completed the work. If people start a manual process without understanding those states, customers can receive duplicate messages, conflicting appointments or repeated payment requests. The recovery plan must cover unfinished work as carefully as new arrivals.

Run a controlled exercise on a non-critical workflow or with test records. Declare the assistant unavailable, pause its actions and give the team the actual fallback instructions. Observe how long it takes to identify the owner, reach the work list, classify urgent items and complete the first safe transaction. Do not count a successful tabletop conversation as proof that staff can access the necessary systems. Both discussion and practical testing have a role.

Define a single record of what was handled during disruption. Each item needs a stable reference, current owner, action taken and completion state. On restoration, reconcile this record against the automated queue before restarting retries. The technical method will vary by platform, but the business rule is constant: an uncertain action should be investigated before it is repeated. Assign someone the authority to approve restart rather than letting a green status page trigger it automatically.

The NCSC recommends regular testing and exercising to expose gaps and validate assumptions. Osborne Clarke's 28 October regulatory outlook also highlights continuity, people, technical recovery and critical decision-making in its discussion of the new guidance. Neither source turns this article into a universal legal checklist for AI. They support a practical lesson: record what the exercise revealed, fix the weak points and repeat the relevant part after material changes.

Make fallback evidence part of workflow approval

Before expanding an AI-supported process, ask for a short fallback record alongside the normal performance results. It should identify the minimum acceptable service, the measured demand and handling rate, available people, activation conditions, temporary record location and restart owner. Include the date of the last exercise and the defects still unresolved. Keep it short enough for an operations manager to use without finding a specialist author.

Give the evidence a sensible expiry trigger. Recheck when volumes rise, staffing changes, a critical connector is replaced or the assistant gains the ability to send messages and change records. These changes affect recoverability even if the underlying model stays the same. A process that was easy to pause when it only produced drafts may be much harder to stop cleanly once it books appointments or issues customer instructions.

Keep investment proportionate. A business owner does not need a dedicated continuity platform to start. Existing approved case-management tools, a controlled work list and a rehearsal with the people who own the service can answer the essential questions. Where your wider business continuity plan already covers the workflow, extend that plan rather than creating a separate AI document that nobody maintains. The useful output is tested operating knowledge, not another dashboard.

For your next pilot review, replace 'we can always do it manually' with a concrete statement: under the tested staffing assumption, we can complete this many priority items per hour for this long, while lower-priority work waits under an agreed communication plan. That is evidence a director can use when deciding whether to scale. AI can remove routine effort and improve service. Its benefits become more dependable when the organisation knows precisely what it will stop, preserve and restore when automation is unavailable.

Frequently Asked Questions

Does every AI tool need a manual fallback?

No. Low-impact internal tasks may safely pause. Prioritise workflows where interruption threatens customer commitments, deadlines, safety or important records.

How do I estimate manual processing capacity?

Measure complete handling time on representative work, then divide genuinely available staff minutes by that handling time. Compare the resulting hourly rate with incoming demand and record the staffing assumptions.

Should we buy a second AI subscription?

Only if the alternative is suitable, approved and tested for the work. Check shared identity, network and integration dependencies before assuming that a different model restores the service.

What should trigger the manual process?

Define workflow-specific triggers such as sustained failures, excessive waiting time or unreliable outputs. Assign a named owner to activate reduced service and pause conflicting automated actions.

What happens to requests already being processed?

Record their current state, identify completed actions and prevent automatic retries from duplicating manual work. Reconcile uncertain cases before restarting the automated workflow.

How often should the fallback be tested?

Use a schedule proportionate to service importance and test after material changes to demand, staffing, dependencies or action permissions. The NCSC recommends regular testing but this article does not prescribe a universal interval.

Is the NCSC guidance an AI-specific legal requirement?

No. The cited guidance concerns disruptive cyber incidents. Its continuity principles are useful for AI-dependent operations, but legal and regulatory obligations depend on your sector, contracts and circumstances.

Do we need a new continuity platform?

Usually not to begin. Extend existing business continuity arrangements, use an approved work list and run a controlled exercise with the people responsible for the service.