Somewhere in a Google Drive folder, there’s a 47-page SOP library nobody has opened in six months.
Someone spent real time building it. The intention was right: document the processes, create consistency, reduce founder dependency. The outcome was a folder the team doesn’t reference because finding the right document takes longer than just asking the founder or figuring it out themselves.
Documentation isn’t the problem. The scope of it is.
The instinct to document everything comes from the right place. But a comprehensive SOP library isn’t the goal. The goal is a business that runs more consistently with less founder involvement. Documentation is one tool toward that goal, and like any tool, it’s only useful when applied to the right problems.
Why “Document Everything” Produces Libraries Nobody Reads
When the instruction is to document everything, the result is a volume problem.
Team members who need to look something up are looking for a specific answer to a specific situation. When the documentation library contains 60 equally-weighted documents, finding the right one requires knowing what it’s called, where it’s saved, and whether it covers the exact variant of the process they’re running. Most people find it faster to ask someone who knows.
There’s also a maintenance problem. A comprehensive SOP library requires ongoing maintenance as the business changes. Processes evolve. Tools change. Team structures shift. A document that was accurate six months ago may be actively wrong today. The more documents there are, the higher the maintenance burden and the faster the library becomes unreliable.
The businesses with documentation that actually gets used tend to have less of it, not more. A focused set of documents covering the processes that matter most, kept current, formatted to be usable in the moment rather than comprehensive in the abstract.
The question isn’t how to document everything. It’s how to identify what actually needs to be documented.
The Criteria for What Actually Needs a SOP
Not every process benefits from documentation. These are the signals that one does.
It’s recurring. A process that happens once doesn’t need a SOP. The time spent documenting it exceeds the value the documentation would produce. A process that happens weekly, monthly, or every time a new client onboards is worth documenting because each recurrence benefits from the standard.
It’s consequential. A process where getting it wrong costs the business something real: a client experience that suffers, a delivery that misses standard, a compliance issue, a financial error. Low-stakes processes can be handled informally. High-stakes ones need the consistency that documentation creates.
It relies on individual knowledge rather than judgment. If running the process correctly depends on knowing a specific sequence of steps, a specific tool configuration, or specific account details, that knowledge can be documented. If running it well depends on exercising judgment in a situation that changes each time, documentation of steps isn’t what’s needed.
The process would break if the person holding it were unavailable. If one team member is the only one who knows how to run a particular process, that’s a key person dependency. Documentation is how you make the process transferable so it survives a departure, a leave, or a role change.
It produces inconsistent outputs when different people run it. If the same process produces different quality results depending on who handles it, there’s no shared standard. Documentation is how you create one.
When a process meets two or more of these criteria, a SOP is worth building. When it meets none, it probably isn’t.
Three Categories of Processes and How to Treat Each
Not all processes need the same response. Grouping them helps clarify what to build and what to leave alone.
Routine processes: document them.
These are the recurring, step-based processes where consistency matters and the steps are knowable in advance. Client onboarding. Invoice processing. Weekly reporting. Delivery handoffs. These are the processes where a SOP produces real value: anyone on the team can run them to the same standard, and the founder doesn’t need to be involved in quality control.
For routine processes, the SOP should be written by the person who actually runs it, not by the founder based on how they think it should work. The person running it knows the real sequence, the edge cases, the points where things typically go wrong. Their version will be more accurate and more usable.
Judgment-heavy processes: define decision authority, not steps.
Some processes can’t be reduced to a checklist because the right action depends on reading the situation. Handling a difficult client conversation. Making a hiring recommendation. Deciding whether to escalate a delivery issue. Documenting the steps for these doesn’t help. What helps is clarity on who has the authority to make the call and what principles should guide it.
For judgment-heavy processes, the document isn’t a SOP. It’s a decision framework: what factors to consider, what the escalation path is, and who owns the outcome. That’s more useful than a checklist that doesn’t survive contact with a real situation.
One-off processes: don’t document them.
A process that happened once, or that exists specifically to respond to a situation that won’t recur, doesn’t need documentation. The time spent documenting it is time that could go toward the processes that do recur and do cost the business when they’re inconsistent.
This is a place where the “document everything” instinct creates the most waste. One-off projects, unique client situations, and ad-hoc responses to unusual circumstances don’t belong in the SOP library. Note what was decided and why, then move on.
The Prioritisation Question
Given limited time and a business that’s already running, where do you start?
The right question is: which undocumented process is costing the business the most right now?
Cost shows up in three ways. Errors: a process where mistakes are frequent and the cost of those mistakes is real. Time: a process that takes significantly longer than it should because each person runs it differently or has to figure it out from scratch. Founder involvement: a process the founder is personally quality-controlling because there’s no documented standard to delegate against.
The process that scores highest across these three is the one to document first. Not the one that feels most comprehensive. Not the one that looks most impressive in a process library. The one that’s creating the most operational drag today.
Building the SOP library in priority order, one process at a time, produces a usable set of documents within weeks. Building it comprehensively from the start produces an ambitious project that rarely gets finished and rarely gets used.
Common Documentation Mistakes
Even when the right processes are identified, the documentation often doesn’t produce what it was designed to.
Documenting aspirational processes instead of real ones. The SOP describes how the process should work, not how it actually works. The team reads it, sees the disconnect from reality, and stops using it. Documentation should capture the current real process, with a note about where it’s being improved, not an idealised version that doesn’t match what anyone is doing.
Writing SOPs for processes that need redesigning first. If a process is broken, documenting it creates a reliable way to run a broken process. The design work comes before the documentation. Fix the process, then document the fixed version.
Treating documentation as a substitute for ownership. A SOP doesn’t own itself. Someone needs to be accountable for running the process, for updating the documentation when it changes, and for catching when the team isn’t following it. Documentation without ownership reverts to the informal approach within a few weeks.
Making the SOP too long to use in the moment. A 12-page document for a process that takes 20 minutes isn’t a useful reference. If the person running the process can’t scan the SOP and find their answer quickly, they’ll stop using it. Short, clear, formatted for use rather than for comprehensiveness.
What “Done” Actually Looks Like
A documented process is complete when someone who has never run it before can run it correctly without asking a question.
That’s the test. Not whether every step is captured, not whether it covers every edge case, not whether it’s been reviewed by the right people. Whether a new team member, handed the document, can produce the right output.
If they can, the documentation is working. If they get halfway through and have to stop to ask something, there’s a gap. Find the question they had to ask and answer it in the document.
This test also reveals when a process isn’t ready to document yet. If the process is inconsistent enough that you can’t predict what “running it correctly” looks like, the design work needs to happen first. You can’t document a moving target.
For a closer look at how systems connect to the broader operating structure, read [how to build business systems your team will actually use].
Frequently Asked Questions
How do I decide where to store process documentation?
It should live where the team already goes to do the work. A SOP in a folder nobody opens is functionally the same as no SOP. If the team uses a project management tool, the SOP belongs there. If they use a wiki, it belongs there. Accessibility matters more than organisation.
How often should process documentation be updated?
Whenever the process changes materially. Assign ownership for each SOP to the person who runs the process most often. Their job includes keeping it current. A quarterly review of the most-used documents catches drift before it becomes a reliability problem.
Should the founder write the SOPs?
Rarely. The founder’s version of a process often describes how they think it works rather than how it actually works in practice. The person running the process writes it. The founder reviews it for accuracy and completeness. This produces better documentation and builds the team’s ownership of the process.
What’s the difference between a SOP and a checklist?
A SOP describes the full process: context, steps, decision points, outputs, and who is accountable. A checklist is a compressed version designed to be run through in real time to confirm each step was completed. Complex processes usually need both: the SOP for learning and reference, the checklist for execution.
We have no documentation at all. Where do we start?
Identify the three processes where inconsistency is costing you the most right now. Document those first. Don’t try to build the full library. Three well-documented, actively-used processes are more valuable than thirty that nobody reads.
See Where Documentation Gaps Are Slowing Your Business Down
The Business Diagnostic Quiz gives you a clear picture of where your operating structure has gaps, including which undocumented processes are creating the most drag.