Why SOPs matter, and what it actually costs a business when they don't exist.

The short answer. SOPs matter because they take a business off one person's memory.

The importance of SOPs comes down to one thing: they let a business run correctly when the person who usually does the task is sick, on leave, promoted, or gone. Without a written process, that knowledge lives in one head, and every hire, holiday and resignation puts it at risk. With one, the task survives the person. It's the same underlying problem process mapping solves at the level of a whole workflow rather than a single task, and the two usually get tackled together.

That sounds like a compliance concern until you put a number on it. The National Association of Insurance Commissioners has found that 71 percent of small businesses report being dependent on one or two key individuals for organisational success. Most founders already know this intuitively about themselves. Fewer have mapped how far it extends through the rest of the team.

How it works in practice. Where the cost of not documenting actually shows up.

The cost rarely arrives as a single dramatic failure. It shows up in five smaller, recurring ones.

• Onboarding takes longer than it should. A new hire without a written process learns by shadowing and asking, which means ramp time depends entirely on how much time a busy colleague has to explain things, usually badly, once.
• Quality drifts. Two people doing the "same" task without a written standard will do it two different ways within a month. Neither is necessarily wrong. Both make it impossible to know why one customer got a different experience than another.
• The founder becomes the ceiling. Every process that only the founder or one senior person knows is a process that has to route through them, which caps how much the business can take on regardless of demand.
• Key-person risk compounds. Mercer Marsh Benefits' Five Pillars of People Risk report found 67 percent of employers think it is likely a key person departure will affect their business within three years, and 55 percent say that impact would be high. Undocumented processes are exactly what turns a resignation into a crisis rather than a handover.
• The business is worth less to a buyer. Anyone who has been through diligence on a sale or investment knows the question that always comes: what happens if you're not here. A business that can only answer "I do it" is discounted against one that can hand over a folder.

None of this shows up on a profit and loss statement until the moment it does, a resignation with no notice, a busy season with a new starter who has no reference to work from, a diligence process that stalls because nothing is written down. By then it is expensive to fix under pressure rather than cheap to prevent in advance.

A worked example makes this concrete. A ten-person marketing agency I've seen in this exact position had one account director who handled every client handover personally, walking each new account manager through it verbally, each time slightly differently. When she left with four weeks' notice, three handovers were mid-flight with nothing written down. Two clients noticed the drop in consistency within a month. The fix afterwards took a single afternoon: a one-page SOP covering the handover checklist, the information a new account manager needs on day one, and who signs off before a client is told the change is happening. That afternoon should have happened a year earlier, not the week after the resignation letter.

The pattern holds even where the stakes are far higher than a marketing handover. Fluke Corporation's 2025 survey of 600 senior manufacturing decision-makers found unplanned downtime costing the sector an average of 1.7 million dollars an hour, and 70 percent of respondents said critical process knowledge held only in people's heads is at risk of being lost as experienced staff retire. A founder-led services business doesn't have a 1.7-million-dollar production line, but the underlying failure is identical: knowledge that exists in one person's head, with no written backup, disappears the moment that person does, and the size of the bill is the only thing that changes.

What good looks like. Deciding what to document first, not documenting everything.

The businesses that get this right don't start with a blank folder and a plan to write down everything. That project never finishes. They start by ranking processes on two axes: how often the task happens, and how much damage it does if it's done wrong or not at all. High-frequency, high-risk tasks get written up first, client onboarding, refund handling, anything touching money or a first impression. Low-frequency, low-risk tasks can wait, or never get formally written at all.

My rule when a founder asks where to start is simpler still: write down the next process that goes wrong. Whatever breaks, gets missed, or gets done differently by two people this week is the one to document this week, not a theoretical top ten drawn up in a planning session. It keeps the exercise tied to real pain instead of becoming an abstract project that stalls in month two, and it means the first ten SOPs you produce are the ten you actually needed.

A usable SOP is short: one task, the trigger that starts it, the steps in order, who owns it, and what "done" looks like, the same structure covered in our fuller explanation of what a standard operating procedure actually is. See our guide on how to create an SOP for the full six-step method, part of the wider standard operating procedures work we do with founder-led teams. The mistake is treating length as thoroughness. A four-page document nobody reads protects nothing; a one-page checklist someone actually opens does.

Review dates matter as much as the first draft. Assign an owner and a fixed review point, quarterly for anything client-facing, twice a year for the rest, so the document ages with the business rather than quietly going stale while everyone assumes it's still accurate.

Pitfalls to avoid. Where the case for SOPs gets lost.

The first pitfall is writing SOPs nobody reads because they're written for compliance rather than use, dense, jargon-heavy, formatted like a policy manual instead of a working document. If a new starter can't follow it without asking someone to translate it, it has failed at its one job.

The second is documenting once and never touching it again. A stale SOP is worse than no SOP, because it looks authoritative while quietly describing a process the business stopped using eight months ago. Someone follows it, gets the wrong outcome, and loses trust in the whole system, including the SOPs that are still accurate.

The third is treating SOP creation as a one-off project with a deadline rather than a habit built into how the business already works. The businesses with the best documentation don't run a single big write-everything-down sprint. They write the SOP the week a new hire needs one, or the week a mistake reveals a gap, so the library grows in step with real need.

The fourth is confusing an SOP with a policy or a values statement. A policy says what the business believes or requires in general terms. An SOP says exactly what someone does, in order, for one specific task. Businesses that blur the two end up with long documents that satisfy neither purpose: too vague to follow step by step, too narrow to guide judgement calls.

Last, watch for the founder who says the business is "too small" for this yet. Key-person dependency is highest precisely when the team is small and the founder is doing five roles personally. Waiting for the business to be big enough to justify documentation usually means waiting until the cost of not having it is already being paid.

There's a version of this pitfall that runs the other way too: the founder who wants everything documented before they'll trust anyone to do it, using the absence of a finished SOP library as a reason to keep every decision on their own desk. That isn't caution, it's control dressed up as thoroughness, and it produces the same bottleneck as having no documentation at all, just with better intentions attached. The point of an SOP is to hand a task away safely, not to delay handing it away until the paperwork feels complete enough.