Every business has a Sandra. She’s the one who knows the Hendersons don’t get invoiced until the 1st, that the trade counter does you a better price if you ask for Dave, that the booking system lies about Thursdays. None of it is written down anywhere. It doesn’t need to be, because Sandra is at her desk and Sandra knows.
The whole place runs beautifully on this, right up until the morning Sandra isn’t there. Off sick, away for a week, or one day gone for good. Then nobody can find the thing, do the thing, or explain why it was ever done that way.
Software people have a grim little name for it: the bus factor. How many people would have to be hit by a bus before the work stops. For a lot of small businesses the honest answer is one. Quite often, it’s you.
You can’t really hire your way out of this, because the knowledge isn’t sitting in a folder waiting to be handed over. It lives in habits, in a spreadsheet with columns only one person understands, in a hundred small “oh, you just know to…”. It is, at the same time, the most valuable thing the business owns and the least protected.
This isn’t a rare or exotic problem. The government’s own business population estimates put 4.3 million of the UK’s 5.7 million private sector businesses — about three in four — in the “no employees” category, meaning the owner is the whole operation, and you can read the figures yourself in the 2025 statistical release on gov.uk. Add in the firms with two or three people where one of them quietly holds everything together, and the single-point-of-failure shape covers most of the businesses on your high street. It’s normal. That’s exactly why it gets ignored until it bites.
Writing a manual feels like the fix. It mostly isn’t.
The usual reaction is to sit down and document everything. Good instinct, short shelf life. A process document is out of date the first time the process quietly changes, and nobody is reading forty pages of Google Doc at half eight in the morning with a customer holding on the other line. The knowledge that matters is the knowledge you use without thinking, which is exactly the knowledge that never makes it into the manual.
There’s a second problem with the binder. Even when it’s accurate, it sits there as a thing you’re meant to remember to check. Sandra never checks it, because she doesn’t need to. The new person doesn’t check it, because they don’t yet know there’s a question to ask. So the binder ends up documenting the day it was written and nothing since, which is roughly the least useful moment to freeze in amber.
And the parts that matter most are the parts that resist being written down. Ask Sandra to explain how she decides which jobs jump the queue and she’ll struggle, because she doesn’t decide so much as feel it: this customer’s been waiting, that one always pays late, the other one shouts. It’s judgement built up over years, and judgement doesn’t sit still long enough to be typed into a heading. That’s the cruel bit. The knowledge worth protecting is exactly the knowledge a manual is worst at holding.
Counting what the gap actually costs
It’s easy to wave this away as a what-if. So let’s put a rough number on it. Say one person is the only one who can do a handful of jobs, and they’re off about ten working days a year — a fortnight’s holiday, the odd sick day, a funeral, a school thing. On each of those days, a few of those jobs stall: a quote that doesn’t go out, an invoice that doesn’t get raised, a supplier query that nobody else can answer. Each stall costs you something in delay, rework, or work that simply walks.
| Days off / year | Jobs stalled / day | Cost per stalled job | Annual cost of the gap |
|---|---|---|---|
| 10 | 4 | £150 | £6,000 |
Illustrative figures. Ten days, four stalled jobs apiece, forty jobs over the year, £150 a job in delay and lost work: six grand, give or take, for the privilege of having one set of shoulders. The point isn’t the exact total — your numbers will be different — it’s that the gap has a price even when nothing dramatic happens. No bus required. Just a normal year with a normal amount of time off.
Put the know-how in the tools, not in someone’s head
The version that actually sticks is to build the knowledge into the things people already touch to get the job done. Instead of “remember not to invoice the Hendersons till the 1st,” the system simply doesn’t raise that invoice until the 1st. Instead of “Sandra knows the pricing,” the quote screen knows the pricing and won’t let you undercook it. The rule stops being something a person has to carry and becomes something the software just does, the same way every time, whoever happens to be sitting there that day.
This is why we keep pushing back on the binder. A rule that lives in a document is a rule someone has to read, remember, and apply correctly under pressure. A rule that lives in the tool just happens. The Hendersons’ invoice doesn’t go out early because the system can’t send it early. The new starter doesn’t undercharge because the screen won’t let them. You’ve moved the know-how from the most fragile place it can live — one person’s memory — into the one place everyone already touches.
None of this is about replacing Sandra. It’s about Sandra being able to take a fortnight in Spain without her phone going off on the beach. It’s also about the version of your business that can take on the next person, or the next van, without all of it depending on one set of shoulders. The same logic shows up around compliance deadlines and renewals: the dates you can’t afford to miss shouldn’t live in one person’s head either, they should fire on their own.
Where to start
Don’t try to capture everything at once, you’ll stall. Find the single process that would hurt the most if the person who runs it vanished tomorrow, the one with the most “you’d have to ask Sandra” baked into it. That’s usually where the money or the legal risk sits, and it’s the one worth getting out of a head and into something solid first. A fair bit of this overlaps with the dull, repetitive admin that’s quietly eating your week anyway, so you often fix two problems with one job.
Once you’ve picked the process, the work splits into two halves. First, get it out of the head and written down as it really runs — not the tidy version, the actual one with the Dave-at-the-trade-counter exceptions intact. That’s the bit we handle in playbooks and SOPs: the documenting done properly, so the messy real process is captured before anyone tries to build on it. Then comes the second half, where the parts that can be automated get baked into a tool so nobody has to remember them at all.
What we’d build
Much of what we do is exactly this: taking a load-bearing process that currently lives in one person’s memory or one unlabelled spreadsheet, and turning it into a small, reliable piece of software. Then we run it, so it doesn’t just become the next thing that only one person understands. If you’d rather see the shape of it before talking specifics, our solutions pages walk through the kinds of jobs this tends to look like in practice.
If there’s a job in your business that only really works because one specific person is there to make it work, that’s the one to point at. Tell us what it is and we’ll have a proper look at what it would take to get it out of their head.