The person, spreadsheet, or supplier your business quietly can't run without
What a single point of failure actually is
A single point of failure is any one person, piece of knowledge, system, or supplier whose loss or unavailability would halt or seriously disrupt your business, because nothing and no one can stand in for it. The phrase comes from systems engineering, where it names the one component that takes everything else down with it. In a growing business the dangerous versions are rarely servers. They are far more human: the only person who knows how the pricing really works, a spreadsheet no one else can read, a workflow held together by a single login, one supplier with no backup behind it.
Not the same thing: A bottleneck and a single point of failure are easy to confuse, because both sit at a pinch point in the work. The difference is severity. A bottleneck slows the work down. A single point of failure stops it altogether.
Single point of failure examples: the four surfaces where they hide
Once you know what you are looking for, single point of failure examples tend to cluster onto four surfaces: people, knowledge, systems, and suppliers. None of these ranks above the others, and the surfaces are worth treating as parallel categories rather than a sequence. The knowledge surface is the one most owners underrate, because capturing what lives in one person's head rarely feels urgent until that person is unavailable. Here is what each surface looks like in an ordinary working week.
People: the person who cannot be replaced this week
The only one who knows how invoicing or payroll actually runs, down to the quirks nobody wrote down. The sole holder of your main client relationship, whose departure would take the account's history and goodwill with them. When one person carries a function like this, a fortnight of leave becomes a fortnight of held breath.
Knowledge: what exists only in one head or one inbox
A process that lives entirely in a single email thread. The undocumented reason a decision was made, so nobody dares reverse it. The spreadsheet only one person can read. This is tacit knowledge, the tribal sort, and it walks out of the door the moment its owner does.
Systems: the tools with no second driver
The shared spreadsheet everyone edits and no one truly controls. The integration or script one person wrote years ago that quietly moves your data every night. The login only one person holds. Each works fine, right up until it doesn't, and nobody else knows how to put it right.
Suppliers: the outside party you depend on completely
The developer who built your site and then went quiet. The single wholesaler for a part your product cannot ship without. The platform you have built on that could raise its pricing, change its terms, or be acquired tomorrow.
Most businesses do not have one of these. They have a live example on every surface at once.
The reality check: you are probably one of them
The four surfaces are worth turning on yourself. Work out your bus factor: the number of people who would need to disappear before the work stops. When it is one, a single resignation, illness, or holiday can halt operations. Run it honestly and the answer often points back at the owner.
Bus factor of one: When the answer is one, and that one is you, the business does not run on process. It runs on your being reachable. A real holiday stops being a rest and becomes a risk you quietly manage.
This is what insurers call key man risk, or key person risk: the concentration of knowledge, relationships, and decisions in one irreplaceable individual. It matters because that individual is often the owner, the person who cannot go off the grid for a week without quietly worrying that something will stall. The holiday you half-dread is the clearest symptom.
The reassuring part is that a person is only one instance of the pattern you have already met. The same find, rank, and remove method applies to you as to any spreadsheet or supplier. Naming yourself as a single point of failure is not an admission of weakness. It is the first step you take to stop being the person everything depends on.
How to find them: the two-week holiday test
To find the single points of failure in your business, pick any one person, system, or supplier and ask what would stop, slow, or silently go wrong if it were unreachable for two full weeks.
The two-week window is what makes the test honest. A day off can be winged, and a week can be patched with goodwill and a few delayed decisions. Two weeks outlasts the patches. It runs long enough to catch the invoices falling due, the payroll that has to go out, the renewal that quietly lapses, and the client who needs a real answer rather than a holding one. Run it against every surface, one at a time.
It is the same question asked across every surface from the examples above, which is what makes it repeatable rather than a one-off. Write down every honest answer, and pay attention to the word silently. Some failures announce themselves at once. The worse ones accumulate quietly, and a fortnight is long enough to surface them. What you write down becomes the first draft of a runbook.
How to rank them: blast radius times likelihood
The holiday test leaves you with an honest list, and an honest list is uncomfortably long. Ranking turns it into something you can act on. Two factors do the work. Blast radius asks how much of the business stops if this failure lands, for how long, and at what cost: a login nobody else holds might freeze invoicing for a fortnight. Likelihood asks how probable that failure actually is within the next year, given how the person, system, or supplier is behaving right now. Keep the scoring light. High or low on each factor is enough, and an elaborate rubric only delays the fixing. Mark each item, then read it off the grid.
| Blast radius | Likelihood | Priority |
|---|---|---|
| High | High | Fix first |
| High | Low | Plan for |
| Low | High | Watch |
| Low | Low | Accept |
Fix the high-blast-radius, high-likelihood items first, because those are the ones that both hurt and are coming. Cost the top items in your own numbers, a week of stalled invoicing against your weekly billing, not a borrowed downtime figure. What you are doing here, informally, is what larger and regulated firms formalise as business continuity and operational resilience under ISO 22301 and the FCA's operational resilience rules. Your written-down list is a working risk register, and three ranked items are actionable where thirty are paralysing.
How to remove them: build the process into the system
The durable removal method is to stop relying on memory. A person who remembers the steps will one day forget one, leave, or be unreachable when the step is due. A system that will not let a step be skipped removes the dependency instead of documenting it. A booking system that enforces the sequence beats the person who holds it in their head, because the sequence survives the person.
| Area | Old way | Better way |
|---|---|---|
| Quoting or invoicing | One person remembers to chase, apply the discount, add the VAT | The system will not close the job until each step is done |
| Handovers | The outgoing person tells the next what they can recall | The next task is assigned automatically with its checklist attached |
| Credentials | Logins live in one person's browser and memory | Shared in a password manager the business controls |
| Supplier knowledge | Terms and contacts sit in one inbox | Recorded where the whole team can read them |
On the knowledge surface, the fix is documentation: runbooks and standard operating procedures. To capture what lives only in one head, have that person record their screen while doing the job and narrate each decision. A screen-recording tool like Loom turns it into a transcript, and the transcript becomes a runbook's first draft. Documentation decays the moment the process changes, which is why encoding the step into a system beats writing it down.
On the people surface, cross-train and keep one more trained person than you strictly need. Engineers call this N+1: one above the bare minimum, so losing one is survivable. This is where cross-training and documented handovers earn their keep.
On the systems surface, redundancy and failover translate out of the data centre: a spare, a tested backup, credentials in a password manager like 1Password or Bitwarden so no login dies with one person. For anything critical, treat it as redundancy and failover built into the infrastructure rather than hoped for.
On the supplier surface, own your data and your code, keep your own credential access, and ask about escrow. If the relationship ended tomorrow, you should be able to walk away with what is yours.
Key person insurance: A real UK product, sold by Aviva, Legal & General and LV= among others. It covers the money, not the operational hole: useful for the financial shock of losing someone, not a replacement for removing the dependency. Succession planning is the same discipline over a longer horizon.
Where to start
Single points of failure sit on four surfaces: people, knowledge, systems, and suppliers. Find them with the two-week holiday test, rank them by blast radius times likelihood, and remove the worst by building the process into the system rather than one person's memory. That is a single loop you can run this week: pick the surface that worries you most and start there. The owner is usually the biggest dependency, and the same method applies to you. Once no one person, system, or supplier can stop the business, scaling without the chaos becomes the natural next step, and a proper break stops being a risk.
Remove the thing everything depends on
We build the systems that carry your processes, so no one person has to hold the business together.
Start with your biggest dependency →