SOPs and Operations Manuals: Writing Procedures People Follow
The test of an SOP is whether a new hire can follow it alone
Every business has procedures. The question is where they live. In most small companies they live in one or two people's heads, which works until those people are on holiday, leave, or are simply busy on the day something unusual happens.
A standard operating procedure moves that knowledge into a form other people can use. Its usefulness has one honest test: can a competent new starter complete the task correctly, without interrupting anyone, using only the document? Most SOPs fail that test, and they fail for predictable reasons.
Key takeaways
- Write for the person who does the work, not for an auditor. If both need serving, write for the doer and add an audit appendix.
- One task per SOP. A document covering "customer onboarding" end to end will not be followed; five short ones will.
- Record the decisions, not just the clicks. The valuable content is the judgement: what to do when the usual answer does not apply.
- Every SOP needs an owner and a review date. ISO 9001 calls this controlling documented information; the principle applies whether or not you are certified.
- Capture SOPs by recording the work, not by scheduling a writing project that never starts.
SOP, process map and operations manual are not the same thing
| Artefact | Scope | Answers | Read by |
|---|---|---|---|
| Process map | End to end, across roles | How does work flow between us? | Managers, improvers |
| SOP | One task, one role | How do I do this correctly? | The person doing it |
| Work instruction | One step in detail | Which button, which field? | New starters |
| Operations manual | The whole function | How does this department run? | New managers, buyers, auditors |
Confusing these produces the two classic failures: a 60-page manual nobody opens, or a pile of click-by-click instructions with no explanation of why any of it matters.
The template that actually gets used
The two blocks people leave out are the two that matter most:
- Decision points. Real work branches. "If the customer has an outstanding balance, do X; otherwise Y." An SOP with no branches is describing an idealised version of the task that nobody actually encounters.
- Exceptions and escalation. What to do when the procedure does not fit, and who decides. Without this, every unusual case becomes an interruption to a senior person — which is the cost the SOP was supposed to remove.
Write the definition of done as something observable: "the record shows status Approved and the customer has received the confirmation email". "Complete the onboarding" is not checkable, so it will be interpreted differently by every person who reads it.
Capturing SOPs without starting a writing project
Documentation projects fail because writing is scheduled separately from doing. The reliable method is to capture while the work happens:
- Record the next real instance. Screen recording with narration, done once, while someone performs the task normally.
- Transcribe and structure into the seven blocks. This is where AI assistance is genuinely useful — converting a rambling transcript into numbered steps is exactly the kind of reformatting it does well.
- Have a second person follow it without help. Every question they ask is a gap.
- Fix the gaps and publish. Total elapsed time is usually under two hours per procedure, against the several days a writing project consumes.
Step three is not optional. An SOP validated only by its author documents what the author believes they do, which reliably differs from what they actually do.
Which procedures to document first
| Priority | Type of procedure | Why first |
|---|---|---|
| 1 | Bus-factor-one tasks | One person knows it; the risk is immediate |
| 2 | High-frequency, multi-person | Inconsistency compounds daily |
| 3 | Money or compliance touching | Errors are expensive and auditable |
| 4 | Onboarding-critical | Every new hire pays the cost of its absence |
| 5 | Rare but high-stakes | Nobody remembers; incident response, year-end |
| Later | Everything else | Document on demand, when someone asks twice |
Version control and review
The quality-management standard ISO 9001 uses the phrase "documented information" and requires that it be controlled: available where needed, adequately protected, and managed through change with identifiable versions. You do not need certification to borrow the discipline, which reduces to four habits:
- One canonical location. If a procedure exists in a shared drive and an email attachment, the attachment will be the one someone follows.
- Visible version and date on the document itself.
- A named owner per procedure, not a department.
- A review interval proportionate to risk — annually for most, after every change for anything regulated.
Add "does this change an SOP?" to your change checklist, the same way you would add it to a release checklist. Procedures do not go stale gradually; they go stale on the specific day someone changes a system and tells nobody.
Assembling the operations manual
The manual is not a longer SOP — it is the context that makes a stack of SOPs navigable. A workable structure:
- How this function works — a page of orientation and vocabulary.
- Roles and decision rights — who can approve what, up to which limit.
- The process map — one diagram showing how the SOPs connect.
- The SOP index, grouped by role rather than alphabetically.
- Systems and access — what tools exist, who administers each.
- Calendar — recurring obligations: month end, filings, renewals.
- Escalation and continuity — who to call, and what happens if a key system is unavailable.
Two audiences make this worth doing properly beyond onboarding: an acquirer performing diligence, and an insurer or regulator asking how you control a risk. Both read the operations manual as evidence that the business is a system rather than a set of habits.
Frequently asked questions
How long should an SOP be?
One page for the procedure itself, with links out to detailed work instructions where a step needs click-by-click guidance. If it will not fit on a page, you are almost certainly documenting several procedures at once, and splitting them will make each more likely to be followed. Length is the enemy of adherence: a document that takes longer to read than the task takes to do will be ignored.
Should we use video or written SOPs?
Both, for different jobs. Video is excellent for capture and for showing an unfamiliar interface; written steps are better for someone mid-task who needs to check one thing without scrubbing a timeline. The practical pattern is to record once, transcribe into written steps, and keep the video as a supporting link. Video alone is also difficult to search, version and audit.
Do we need ISO 9001 to benefit from documented procedures?
No. Certification is a separate decision driven by customer or regulatory requirements. The underlying discipline — a canonical location, visible versions, named owners and scheduled review — is worth adopting on its own merits at any size, and it happens to leave you much closer to certifiable should you ever want that. Adopt the habits, decide on the certificate separately.
Who should write our SOPs?
The person who does the work should be the source, but not necessarily the author. The most reliable division is: the practitioner performs and narrates, someone else structures it into the template, and a third person tests it by following it unaided. Having the practitioner write it alone tends to produce documents full of assumed knowledge, because expertise makes its own steps invisible.
How do we get people to actually use them?
Make the SOP the fastest route to doing the task correctly, and put it where the work happens rather than in a document library. Link it from the tool, the checklist or the ticket template. Then close the loop: when someone asks a question the SOP should have answered, treat that as a defect in the document and fix it rather than answering privately. Procedures earn adherence by being useful, not by being mandated.
Sources
- ISO, ISO 9001 quality management — requirements for controlling documented information, including versioning, availability and review.
- ISO, ISO 30401 knowledge management systems — framework for capturing and maintaining organisational knowledge.
Keep reading
All articles →
Innovation Culture and Technology Adoption
Innovation Culture and Technology Adoption: The Competitive Advantage Most Businesses Underestimate Most leaders don’t lose market share because they “lack tech...
Mar 03, 2026 · 11 min read
Pilot Programs: Testing Technology Before Commitment
Pilot Programs: Testing Technology Before Commitment Digital transformation is full of high-stakes decisions: new platforms, new processes, new vendors, and oft...
Feb 24, 2026 · 11 min read
Platform Business Models and Technology
Platform Business Models and Technology: Turning Digital Transformation into Scalable Growth Traditional businesses grow by adding more inventory, hiring more p...
Apr 06, 2026 · 11 min read