Skip to content

Glossary

Business continuity

The plan for keeping essential work going when a system is unavailable, which assumes somebody has noticed the work now depends on it.

In plain terms

What everybody does on the morning the thing does not work. For most AI tools the honest answer is that nobody has thought about it, because nobody decided to depend on the tool in the first place; the dependence accumulated while everyone was busy being pleased with it.

01

Why it matters

Because dependence in this category is acquired rather than chosen. A tool introduced as a convenience becomes the way a team drafts, summarises or answers, and no meeting ever approved that transition, so no meeting ever considered what happens without it. The first time anybody assesses the dependence is during the outage.

02

How it works

Continuity and recovery answer different questions and both are needed. Continuity is how essential work continues while something is unavailable; recovery is how the thing itself comes back. A plan that only covers the second leaves people idle while it is executed, which for a daily tool is the expensive half.

The realistic fallback is usually the previous method, and its viability decays. Whatever a team did before the tool arrived is the natural answer, and after a year the people who were fluent in it have stopped practising and some have left, so the fallback that existed at adoption is not the one available now.

Not every use needs a plan, and pretending otherwise produces one nobody reads. A tool helping somebody draft faster can simply be absent for a day; a tool answering customers or sitting inside a process that runs whether or not anyone is watching cannot, and the difference is worth deciding explicitly rather than by default.

A vendor's availability commitment describes their intentions and compensates you rather than continuing your work. Credits arrive later and do not answer the question of what today's team does, which is why the commitment is a procurement detail rather than a continuity plan.

Concentration makes several tools fail together in a way people find surprising. Products resting on the same underlying providers can become unavailable at the same moment, so a fallback that is itself an AI tool may not be a fallback at all, and nothing on either product's page reveals the shared dependency.

Two kinds of unavailable

Two kinds of unavailableThe reason to draw this line before an outage rather than during one is that the two columns feel identical while a tool is working, and the effort of distinguishing them is what makes any plan usable. An organisation that treats every AI tool as critical produces a long document, reviews it annually, and cannot find the relevant page under pressure; one that treats none as critical discovers on a Tuesday that customers have been unanswered for three hours. The sorting question is short: does this tool sit between a customer and an answer, or inside a process that runs whether or not anybody is watching. If neither, the honest plan is that people work more slowly for a day and it is worth saying so explicitly, because writing it down stops somebody drafting an elaborate contingency for a tool that does not need one. The second thing worth doing costs even less. Whatever the fallback is, ask when somebody last actually did it, because a documented manual process nobody has performed since adoption is a description of a capability rather than a capability, and the difference only becomes apparent at the worst possible moment.InconvenientDrafting is slower today.People notice immediately.The work waits and catches up.A continuity eventCustomers are not beinganswered.A process fails with nobodywatching.The backlog grows while youdecide.Both are the same tool beingdown. Only the right-hand columnneeds a plan, and anorganisation that writes onecovering both ends up with adocument too long to be read onthe morning it matters.
The reason to draw this line before an outage rather than during one is that the two columns feel identical while a tool is working, and the effort of distinguishing them is what makes any plan usable. An organisation that treats every AI tool as critical produces a long document, reviews it annually, and cannot find the relevant page under pressure; one that treats none as critical discovers on a Tuesday that customers have been unanswered for three hours. The sorting question is short: does this tool sit between a customer and an answer, or inside a process that runs whether or not anybody is watching. If neither, the honest plan is that people work more slowly for a day and it is worth saying so explicitly, because writing it down stops somebody drafting an elaborate contingency for a tool that does not need one. The second thing worth doing costs even less. Whatever the fallback is, ask when somebody last actually did it, because a documented manual process nobody has performed since adoption is a description of a capability rather than a capability, and the difference only becomes apparent at the worst possible moment.
03

Seen in the wild

  • A support team whose drafted replies stop, discovering the manual process nobody has used for a year.

    Tidio Lyro
  • An automation that quietly stops running, where the failure is noticed by its absence rather than an alert.

    Make
  • A drafting assistant becoming unavailable, which is genuinely inconvenient and not a continuity event.

    ChatGPT
04

Common misconceptions

People assume

The vendor's availability commitment covers us.

In fact

It describes what they aim for and what they pay if they miss. Neither answers what your team does that morning, so it belongs in the procurement conversation rather than in the plan for continuing work.

People assume

The old way is still there as a fallback.

In fact

It decays quietly. A year after adoption the people fluent in the previous method have stopped practising it and some have left, so the fallback assumed at adoption is not the one actually available when it is needed.

05

Questions

Which tools actually need a plan?
The ones inside a process that runs without somebody watching, and the ones customers reach. A tool that helps individuals work faster can be absent for a day at a real but survivable cost, and treating those two categories identically produces a document nobody maintains.
What does a usable fallback look like?
Something somebody has done recently. A documented manual process that nobody has performed for a year is a description rather than a capability, so the test is whether a person could pick it up today rather than whether it is written down somewhere.
Can we rely on a second AI tool as backup?
Only if it does not share the foundation the first one rests on, which is harder to establish than it sounds. Products that compete for your business frequently depend on the same providers underneath, so both can become unavailable together.
06

Key takeaways

  • Dependence here is acquired rather than decided, so nobody assessed it.
  • Continuity is carrying on; recovery is getting the thing back.
  • The old method decays as a fallback while nobody is practising it.
  • A second AI tool is only a fallback if it shares no foundation.
08

Tools that use this

  • Tidio Lyro

    A support team meeting a manual process nobody has used for a year.

  • Make

    An automation stopping, noticed by absence rather than by an alert.

  • ChatGPT

    Genuinely inconvenient to lose, and not a continuity event.

Last checked August 2026

All glossary terms