Your model provider has an outage. A connector stops working. The one person who knows how the bots are set up quits. What happens on Monday?
What it is
Business impact analysis (BIA) is the first step of business continuity planning. For each important process, it asks:
- What does it depend on? Systems, suppliers, people, data, locations.
- What happens if it stops? Lost sales, late shipments, missed deadlines, legal problems.
- How fast does it hurt? An hour? A day? A week?
- How long can we tolerate it? The maximum tolerable downtime.
- How fast must we recover? The recovery time objective.
The output is a ranked list of processes by how much and how fast an outage hurts, and what each depends on.
Why it matters for bots
Bots add new dependencies that often aren't on anyone's list:
- The model provider. Outages, price changes, a model being retired.
- Connectors. A change on the other side breaks them quietly.
- The setup knowledge. Who knows how the skills, routines and folders fit together?
- The skills themselves. Where are they stored? Are they backed up?
And the bot may have replaced the people who used to know how to do the work by hand.
Why people skipped it
A BIA takes interviews with every department and a lot of follow-up. Small companies rarely do one until after a bad week.
How a bot does it
- Give it the process map, the tool list, the bot list and the RACI.
- Have it list every dependency for each process, including bots, models and connectors.
- Have it estimate impact over time: 1 hour, 1 day, 1 week. Marked as guesses for people to correct.
- Have it find single dependencies: one supplier, one person, one model, with no fallback.
- Have it propose a fallback for each.
- Process owners correct the impacts and pick the fallbacks.
The bot brief
Draft a business impact analysis.
Inputs: process map [file], tool and connector list [file], bot and routine list [file],
RACI [file], supplier list [file].
For each process: list every dependency (systems, suppliers, model providers,
connectors, people, data, files).
Estimate impact if unavailable for 1 hour / 1 day / 1 week (None/Low/Medium/High),
marked ESTIMATE for the process owner to correct.
Flag every dependency with no documented fallback.
Flag every task now done only by a bot that no current person knows how to do by hand.
Propose a fallback for each flagged item. Rank processes by impact at 1 day.Starting point only. Test it on your own data and model, and adjust as needed before you rely on it.
An example
| Process | Dependency | 1 day out | Fallback today | Proposed |
|---|---|---|---|---|
| Quoting | Model provider | High | None | Second provider tested quarterly; estimator can quote by hand |
| Quoting | Price list file | High | Backup nightly | OK |
| Weekly report | Email connector | Low | None | Report saved to folder; owner reads it there |
| All bots | Setup knowledge | High | One person | Write the setup into a playbook; second person trained |
The last row is the one most small setups miss. The bots are documented in their skill files. The setup of the bots often lives in one person's head.
Where bots differ
A BIA for people asks "who can cover?" For bots, the question is also "can a person still do this by hand?" If nobody can, an outage stops the work completely. Keep the manual method written down, even if nobody uses it day to day. See Knowledge that survives the night.
What this means for you
- List what each process depends on, including models and connectors.
- Have a bot draft impacts and find single points.
- Keep a fallback for anything that hurts within a day.
- Make sure a person can still do the critical jobs by hand.