Documenting Processes When Nobody Has Time to Document Processes

Process documentation is the most agreed-upon, least-done task in small business. Everyone knows the costs of its absence — the business that can't run when one person is away, the training that happens by folklore, the same mistakes rediscovered annually. And yet the manual never gets written, because the version in everyone's head is a six-month project producing a binder nobody reads. That version deserves to die. The version that works is smaller, lazier and far more useful. Here's the 80/20.

Document at the moment of transfer

Forget documenting the whole business. Processes get written when knowledge is about to move anyway: someone's going on leave, a new hire is starting, a task is being delegated, a contractor is taking something over. At that moment, documentation isn't extra work — it's the same work, captured. The handover conversation you were going to have verbally becomes a checklist you keep. Over a year, the moments of transfer cover most of what matters, in exactly the order it matters, with zero standalone "documentation project" ever existing.

The companion rule: when something goes wrong because a step lived in someone's head, the fix isn't just fixing it — it's writing the step down within the day. Incidents are a free, perfectly prioritised list of what needs documenting.

Capture, don't compose

The reason documentation feels heavy is that people imagine writing — prose, formatting, diagrams. Skip it. The fastest process documentation is captured from the doing:

• Record the screen while doing the task once, narrating as you go. A ten-minute recording of "how we run payroll" is created in exactly the time it takes to run payroll.
• Photograph the physical — the machine settings, the storeroom layout, the completed form done right.
• Turn the narration into a checklist afterwards — and here's where modern tools have changed the economics entirely: transcribing a recording into a clean numbered checklist is now a five-minute job, not an evening one.

The standard to hit is not "comprehensive". It's "could a competent person who's never done this follow it without calling anyone?" Numbered steps, the two or three judgement calls flagged ("if X, then ask before proceeding"), and where things live. Ugly and current beats beautiful and stale by a mile.

Store it where the work happens

A process library nobody can find is a process library that doesn't exist. One home — a shared drive folder, a Notion or SharePoint space, even a structured set of pinned documents — with names that match what people actually say ("How to do a stocktake", not "SOP-014 Rev 3"). Link documents from the place the task gets triggered where you can: the checklist inside the recurring calendar event, the guide linked in the job template. The test of the system is whether a new starter finds answers before they find you.

Keep it alive with one habit

Documentation rots, and rot is what makes people distrust the whole library. One habit prevents it: whoever uses a document fixes it. Following the payroll checklist and step four is outdated? You update step four, right then — thirty seconds, no committee. Add a "last used/updated" date at the top of each document and the stale ones identify themselves. An annual half-day review of the dozen most critical documents (the ones whose failure would actually hurt) covers the rest.

Start with the five that matter

If you do nothing else, document the five processes whose failure tomorrow would hurt most — typically: how money comes in (invoicing/billing), how people get paid, the core delivery process, the opening/closing or daily-start routine, and what to do when the key system goes down. Five documents is a weekend of capture, not a six-month project, and it converts your scariest single-person dependencies into ordinary risks. The rest of the library can build itself one transfer at a time — which, it turns out, is the only way libraries like this ever actually get built.

FAQ

Who should do the documenting — me or the team?

The person who does the task, captured in the doing; the owner's job is the system and the standard, not the typing. Bonus: people follow processes they wrote far more faithfully than processes issued to them.

How detailed is too detailed?

If a step never varies and could be misread, it's worth a line. If you're documenting judgement ("use common sense about X"), stop — name who to ask instead. Documents that try to replace judgement become long, wrong and ignored.

What about processes that are genuinely all judgement?

Document the frame instead: the questions to ask, the factors that matter, two worked examples of past decisions. You're not scripting the call — you're shortening the apprenticeship.

---

Single-person dependencies are one of the biggest hidden risks we see in SMEs. Our free Business Health Check will show you yours — it takes five minutes.