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.
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.
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
Seen in the wild
A support team whose drafted replies stop, discovering the manual process nobody has used for a year.
Tidio LyroAn automation that quietly stops running, where the failure is noticed by its absence rather than an alert.
MakeA drafting assistant becoming unavailable, which is genuinely inconvenient and not a continuity event.
ChatGPT
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.
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.
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.
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