Most small business SOPs fail in one of two ways. Either they're never written, because writing them feels like a project. Or they're written beautifully, stored somewhere nobody looks, and go stale within a year — which is worse, because now there's a document that's confidently wrong.
An SOP library that works has three properties: procedures are short, they're stored where the work happens, and there's an owner and a review date on every one.
Where the library lives
01 Admin/
SOPs/
00 INDEX.md
100 Sales/
200 Delivery/
300 Finance/
400 Marketing/
500 Admin & IT/
900 Archive/Number by hundreds, matching the department. Individual SOPs take numbers within their block:
200 Delivery/
201 New client onboarding.md
202 Project kickoff call.md
203 Weekly client update.md
204 Project handoff and close.mdThe numbers do real work. They give every procedure a stable identifier you can reference in a checklist, a job description, or a training document — "follow 201" is unambiguous forever, even if the title changes. Gaps between numbers let you insert procedures without renumbering.
Keep SOPs in the same drive as the rest of the business, not in a separate app. Separate apps require a separate login, a separate habit, and a separate subscription, and they're where documentation goes to be forgotten. If you already run a wiki or knowledge base that people genuinely use daily, use that instead. If you don't, a folder of markdown or documents beats a tool nobody opens.
The one-page format
Every SOP uses the same template. Copy it, fill it, done.
# 201 — New Client Onboarding
Owner: Priya
Last reviewed: 2025-04-08
Review every: 6 months
Trigger: A proposal is marked Won
## Purpose
Get a new client from signed contract to first working session
with nothing missed.
## Steps
1. Copy _TEMPLATE Client folder, rename to client name
2. Save signed contract to 01 Contracts
3. Add client to the contract register
4. Create client in invoicing system, set payment terms
5. Send welcome email (template: 05 Marketing/Templates/welcome.md)
6. Schedule kickoff call within 5 business days
7. Send intake questionnaire 48h before kickoff
8. After kickoff, save notes to 02 Briefs & Notes
## Watch out for
- Don't start work before the contract is countersigned
- If the client is in the EU, use the EU version of the agreement
## Related
- 202 Project kickoff call
- 301 Setting up a new client for invoicingFive elements, and each is doing a job.
Owner — one named person. Not a department. Unowned SOPs go stale invisibly.
Last reviewed and review interval — this is what makes the library trustworthy. An SOP with a review date from three years ago is telling you not to trust it, which is useful information.
Trigger — the event that means someone should be reading this. Most SOP libraries are written as reference material, but people don't browse reference material. They act when something happens. Naming the trigger connects the document to the moment.
Steps — numbered, imperative, one action each. If a step needs three paragraphs of explanation, it's probably two steps, or it needs its own SOP.
Watch out for — the exceptions, the thing that went wrong last time, the case that isn't obvious. This section is where the real value is, and it's the part generic templates leave out. It's also the easiest to write, because it's just the things you already tell people verbally.
Write the ones that hurt, in the right order
Don't try to document everything. Write in this order:
- Things that go wrong repeatedly. The recurring error is the highest-return SOP in the business.
- Things only one person knows. Every single-point-of-failure process, starting with the ones where that person is you.
- Things you do more than monthly. High frequency multiplies the return on any small improvement.
- Things a new hire would need in week one. These pay off the moment you hire, and they're the hardest to write under time pressure later.
Most small businesses need somewhere between fifteen and forty SOPs total, and about eight of them account for most of the value. Write eight and stop; write more when something breaks.
Keep them short enough to be updated
The strongest predictor of whether an SOP stays accurate is how painful it is to edit. A one-page text procedure gets corrected in thirty seconds by whoever notices the error. A twelve-page illustrated document with screenshots requires a project, so it doesn't get updated — it gets ignored.
This is the argument against screenshot-heavy documentation for most small businesses. Screenshots are genuinely clearer, and they're wrong within months because software interfaces change constantly. If you use them, use few, and describe the action in text as well so the words still work when the picture is stale.
Screen recordings are the same trade-off with a worse search problem: you can't skim a video, and you can't fix one line of it. They're excellent as a supplement — record once, link from the SOP, and let the text carry the load — and poor as the primary format.
The index
00 INDEX.md is one table:
Number | Procedure | Owner | Last reviewed
201 | New client onboarding | Priya | 2025-04-08
202 | Project kickoff call | Priya | 2025-02-11
301 | Monthly bookkeeping close | Dana | 2024-09-30 ← overdueSortable by last-reviewed, which turns the index into a maintenance queue. When you open it and see three entries from two years ago, that's the work.
Reviews: twice a year, thirty minutes
Put it on the calendar. Open the index, sort by review date, and for anything overdue, the owner does one of three things:
- Still accurate — update the date, nothing else.
- Slightly wrong — fix the wrong lines, update the date.
-
No longer done this way, or no longer done at all — move it to
900 Archivewith a note at the top saying what replaced it.
Archiving rather than deleting matters. When someone asks in a year why a process changed, the archived version with a dated note is the answer.
Two things that make the library stick
Reference SOP numbers in the actual work. Your client onboarding checklist says "see 201." Your new hire plan says "read 201, 202, 203 in week one." A number that appears in daily work gets maintained; a document that only appears when someone goes looking does not.
Let whoever runs the process write it. Not the owner of the business, not the most senior person. The person doing the work knows the exceptions, and writing it themselves means they'll actually follow it. Your job is to insist on the template and the review date, not to write the content.
The test of an SOP library isn't whether it's comprehensive. It's whether the last person you handed a task to needed to ask you a question.
Next in this series: How to Organize Digital Product Files for an Online Shop