2026-07-22

How to spot key-person risk in your small business

"What if Maria's out sick" is not a plan. It's a background worry that most small business owners carry about one specific person — the one who knows how the Friday payroll run actually works, or the only one who can find last month's invoices without asking.

Key-person risk is what happens when a process only runs because one named individual knows how to do it. It's not about how good that person is. It's about what happens to the process the day they're not there.

What key-person risk actually looks like day to day

It rarely shows up as a dramatic failure. It shows up as small, quiet tells:

A task gets pushed to "when [name] is back" instead of getting done
Someone else attempts the task and gets a visibly different (usually worse) result
The process lives in one person's head, a personal notebook, or a spreadsheet only they understand
Onboarding a replacement for that task would take weeks, not a afternoon

None of these are emergencies on their own. Together, they're a pattern.

The 3-question test to find your single points of failure

You don't need a formal audit to find these. Three questions, asked honestly about each recurring process, will surface most of them:

Question	What a "yes" means
If this person took two weeks off with no notice, would this task get done correctly?	If the honest answer is "probably not," this step is at risk.
Could someone else do this today, using only what's written down?	If the answer relies on "they'd have to ask [name]," nothing is actually documented.
Has this task ever been late or wrong specifically because the usual person wasn't available?	A "yes" here means the risk isn't hypothetical — it's already happened once.

Run this test against your three or four most recurring processes — invoicing, scheduling, payroll, membership renewals, whatever eats the most repeat time. You'll usually find one or two clear single points of failure, not a dozen. That's normal. The point isn't to find everything at once — it's to name the one or two that matter most.

What to do once you've found one

Once a dependency is named, there are really only three honest options:

Mitigation	What it looks like in practice	Typical tool
Document it	Write the steps down as a runbook, plain enough that someone else could follow it cold	A shared doc, a wiki page, a checklist in Notion or Google Docs
Cross-train it	A second person shadows the task, then runs it solo while the first person is still reachable	A shared calendar for practice runs, a recorded screen-share walkthrough
Remove the dependency entirely	Replace the manual step with something that doesn't need a specific person to run it	A small script (a short Python or Google Apps Script routine), a no-code automation (Zapier, Make), or a rule-based check built into an existing tool
Accept the risk, deliberately	For low-frequency, low-cost tasks, sometimes the honest answer is "we'll live with it"	No tool needed — just write down that this was a conscious choice, not an oversight

The important part is picking one on purpose, not defaulting to "we'll deal with it if it happens."

Why "just hire a backup" isn't always the right fix

The instinctive fix is often "train someone else to do exactly what they do." That works for some tasks. But if the underlying process is genuinely inefficient — three manual steps that could be one — training a second person just doubles the number of people doing something slow, instead of fixing the actual bottleneck.

Before cross-training a process, it's worth asking the same question a Quick Check is built to answer for one workflow at a time: is this task hard because it's genuinely complex, or hard because nobody's written down the rule yet? Those have different fixes — and only one of them needs a second person.

If you want a structured way to map one process like this and see exactly where it depends on you (or on any one person), book a call and we'll walk through what a Quick Check on that specific workflow would look like.