How to write SOPs for a small business: the short answer
To write SOPs for a small business that people use, write one process per page, with the person who does the job. Use numbered steps that each start with a verb. Put a named owner and a review date at the top. Keep the page where the work happens, and review it whenever the software, a supplier or the people change.
This guide is for the owner or operations lead of a 10 to 50 person firm, where how things get done lives in two or three heads. Someone may be leaving. You may want to hire, or to let an AI tool answer staff questions. All three need pages that say how the work runs today.
An SOP, or standard operating procedure, is the written steps for one process: who does it, in what order, and what done looks like. Most firms treat SOPs as a writing project. Someone, or ChatGPT, produces a manual, and the processes count as documented.
A year later the manual describes a company that no longer exists. The writing is the easy part. Upkeep decides whether anyone opens the page again.
We build company knowledge bases with ownership and review built in. Before we automate any process, we map it as it runs today, including the parts nobody wrote down. Below: which processes to write first, which format to use, a one-page template to copy, and a review routine a small team can keep.
Why most SOPs go unused
The most studied process document in the world is a one-page checklist, and it shows the problem. In 2007 and 2008, a team working with the World Health Organization introduced a surgical safety checklist in eight hospitals in eight cities. The death rate after surgery fell from 1.5 to 0.8 percent, and complications in hospital fell from 11 to 7 percent.
Ontario then made the checklist mandatory in its hospitals. A study of 101 of them found no significant fall in deaths or complications: the adjusted death rate went from 0.71 to 0.65 percent.
One explanation offered is that Ontario's rates were already low. Lucian Leape, in an editorial beside the study, gave another: a checklist works when a team adapts it, trains on it and uses it together. A mandate does none of that. The WHO itself encourages hospitals to modify the checklist for local use. Either way, the page alone didn't change the work.
The UK's Health and Safety Executive lists why people skip procedures, in its guidance on revitalising procedures. The procedure is wrong or out of date. It is hard to follow. It isn't to hand. There is an easier way to do the task.
HSE wrote that guidance for major hazard sites such as chemical plants, and says it is relevant to other industries too. In a 20-person office the list reads the same.
Which processes to write first
Start with the processes that cost most when they go wrong, happen rarely, or live in one person's head. The daily routine everyone knows can wait, because people correct each other on it.
| Write it first when | Why | Example in a 20-person firm |
|---|---|---|
| Only one person knows how | Their holiday or notice period becomes your deadline | Month-end close, payroll changes |
| It happens a few times a year | Nobody remembers the steps, and there may be nobody to ask | Year-end stock count, renewing a licence |
| A mistake is expensive or hard to undo | One page costs less than one mistake | Changing a supplier's bank details |
| The law expects it in writing | An inspector or regulator may ask to see it | Health and safety policy, food safety, data breaches |
| People keep asking how | Every repeated question costs two people's time | Booking leave, raising a purchase order |
Three legal cases apply to many small firms in the UK and EU. HSE says that if you have five or more employees, you must write down your health and safety policy. It should say who does what, when and how.
Food businesses must keep procedures based on HACCP principles. Article 5 of Regulation 852/2004, which the UK kept after Brexit, requires the documents describing them to be "up-to-date at all times".
A data breach procedure is the one most offices lack. Under UK and EU GDPR, you must report a notifiable breach to the regulator within 72 hours of becoming aware of it. You must also record every breach, reported or not. That is rare and urgent: exactly the task nobody remembers the steps for.
To find the rest, ask each person one question: what would go wrong if you were away for three weeks?
Checklist or step-by-step: choose the format by the task
Most small-firm processes need a checklist rather than a manual. HSE's guidance includes a decision chart with a plain rule. Use full step-by-step instructions when the task is safety-critical, complex or rarely done, or when the person is new to it. For everything else, use a job aid: a checklist, a diagram or a flowchart.
| Format | Use it when | Example |
|---|---|---|
| Checklist | People know the task but skip or forget steps | Opening and closing checks, sending a quote |
| Numbered steps | The task is rare, complex or risky, or the person is new | Month-end, changing bank details, a data breach |
| Flowchart or decision table | The next step depends on an answer | Refunds: inside 30 days, after 30 days, damaged on arrival |
| Screen recording | The task happens on screen and the clicks matter | Adding a new user to your accounting software |
HSE also separates procedures from manuals. A manual is a reference set, usually too long "to take to, or to use on, the job". Keep a long version for training if you need one, and put the one-page version where the work happens.
One process can have two versions, as HSE notes: a full one for new people and a checklist for old hands. That works if both have the same owner and change on the same day. Two versions with two owners drift apart, and each one looks right on its own.
How to write the page, with the person who does the job
Write the page with the person who does the work, while they do it. HSE puts it plainly: users should always be involved in writing procedures. An owner writing from memory records how the work was designed, which is rarely how it runs.
- Sit beside them for one real run. Note every step, including the ones they do without thinking: the second tab they check, the colleague they message.
- Ask for their private notes. HSE calls them "black books", the notebooks of key information staff carry. Today they are sticky notes, a personal Google Doc or a WhatsApp message to themselves, and they often hold the real procedure.
- If two people do the job, write both versions side by side before you choose. The difference is often small and early. Say one checks the customer's account before printing the label and the other checks after. Pick one order and write down why.
- Write one action per step, starting with a verb: "Check that the PO number matches the invoice."
- Put each warning before the step it applies to, and say what happens if it goes wrong. HSE gives the same rule: warnings explain, steps instruct.
- Name the handoffs: where the input comes from and where the output goes, by system and by role. "Orders arrive in the sales inbox." "Send the signed form to the bookkeeper." A reader can check the steps in front of them. They can't check a handoff, and handoffs change without anyone touching the page.
- Give the reason for any step that looks optional. People skip steps they don't understand.
- Hand the draft to someone who has never done the task, and watch them follow it. Every place they stop is a missing step.
Writing it down is also the cheapest process review you will ever run. A step nobody can explain is a candidate for deletion. Our rule before automating anything applies here too: map first, delete second. Automating a broken process makes it break faster, and documenting one makes it permanent.
A one-page SOP template to copy
Copy this into your wiki or shared drive and fill it in. If the steps run past one page, you have more than one process, so split it.
PROCESS: [the result, e.g. "Refund a customer order"]
Owner: [one named person]
Last reviewed: [date] Next review: [date]
Status: current / draft / out of date
WHEN TO USE IT
Starts when: [the email, the date, the request]
Done by: [role]
Not for: [cases that go somewhere else, and where]
YOU NEED
Access to: [systems, by name]
Input from: [where it comes from, and who sends it]
STEPS
1. [Verb first. One action per step.]
2. WARNING: [what happens if the next step goes wrong]
3. [...]
DONE WHEN
[What is true at the end, and who receives the result]
IF SOMETHING LOOKS WRONG
Ask: [name or role]. Note it in: [where]
LINKS
Policy this follows: [link]
Next process: [link]
Change history: [link, kept off this page]
Four fields do most of the work. The owner answers for the page being right. The review date shows at a glance which pages nobody has checked. "Not for" stops people stretching the page over cases it wasn't written for.
The change history lives on a separate page. A process page full of notes like "Update, March: ignore step 4" has outgrown its container. Readers who find three stale notes stop trusting the steps that never changed.
Owners and review dates: how SOPs stay true
An SOP stays true when one named person owns it, it carries a review date, and any change to the work triggers an early review. The UK's Food Standards Agency builds all three into Safer food, better business, its pack of procedures for small food businesses in England and Wales.
The pack's introduction names a person who takes charge of it, with a table for each review date and who reviewed it. Its procedures "need to be reviewed regularly and updated if your food operations change", and the pack stays at the business.
A daily diary records anything that went differently, and a 4-weekly review looks for problems that keep coming back. The FSA even cut the jargon: you won't find the word HACCP in the pack.
That is a regulator's design for a small team, and it moves to an office almost unchanged.
- Give every page one owner: the person who would be asked anyway. When they leave, their pages get a new owner before their last day.
- Put a review date on every page, and check once a month for pages past their date. The monthly routine in our guide to a company second brain works for process pages too.
- Review early when something changes: new software, a new supplier, a mistake, or a new starter who gets stuck.
- Review by watching someone use the page, then confirm it, edit it or retire it. Re-reading a page at your desk finds typos, not drift.
- Keep a diary, as the FSA does: one shared log where people write "did it differently today, because...". Those lines are next month's edits.
- Move retired pages where nobody finds them by accident. HSE asks for a formal way to remove out-of-date procedures. In a small firm, that is an archive folder that search doesn't cover.
Using AI to write and read your SOPs
AI helps with both halves: drafting pages and answering questions from them. It can't decide which version of a process is the right one.
For drafting, screen-capture tools such as Scribe and Tango record each click and turn it into a step-by-step guide with screenshots. ChatGPT or Copilot can turn a transcript of someone talking through a task into a first draft.
Both capture how one person did the task once. Neither records why a step exists, the exception that happens once a month, or the handoff to a colleague. Treat the output as the notes you would take sitting beside someone, then work through steps 2 to 8 above.
For reading, AI assistants that search your documents answer from whatever they find. One process per page helps: the tool retrieves the page that matches the question, and the whole answer sits on it. A 40-page manual gets cut into passages, and a passage like "then send it to Anna" means nothing out of context. Our guide to RAG for business owners explains how that retrieval works and where it fails.
The risk is a stale page. A new starter reading an old SOP may notice something off. An assistant answers from it and cites it, so owners and review dates matter more once software reads the pages. Check who can open what before you connect anything. A process page that holds supplier bank details becomes an answer anyone can get by asking.
When not to write an SOP
Some work doesn't need a page, and a page won't help it.
- The task happens once. Write a short note of what you did and why, and stop.
- The process still changes every week. Write it when it settles, or the page will be wrong before anyone reads it.
- The work is judgement. You can't write steps for deciding whether an angry customer gets a refund. Write the principles, the limits and who decides, the same line we draw in what not to automate with AI.
- The system can enforce it. "Remember to add the PO number" belongs in a required field. HSE's first advice on compliance is to design the task so the correct way is hard to avoid.
- Nobody will own it. An unowned page is next year's wrong answer, so settle the owner before anyone writes.
If most of your processes fall into these groups, you don't need an SOP project, and you don't need us for one.
Where to start this week
Ask each person on your team what would go wrong if they were away for three weeks. Pick the answer that worries you most. Sit beside the person who does that job during the next real run, and write one page with an owner and a review date. Then hand it to someone else and watch them use it.
Questions
What's the difference between a policy, an SOP and a checklist?
A policy states the rule and the reason: refunds after 30 days need the owner's approval. An SOP says how to carry it out, step by step, and who does each step. A checklist is the short form of an SOP, used at the point of work by someone who already knows the task. Keep them as separate pages and link them, because they change at different speeds.
Should staff sign to confirm they've read each SOP?
Only where a regulator or a client expects a record, such as the staff training record in the FSA's food safety pack. A signature proves someone opened the page. It doesn't prove they can do the task. Watching them do it once, with the page in hand, proves more and finds the page's gaps at the same time.
Do we need dedicated SOP software?
Not to start. A shared drive or the wiki your team already opens will do for your first pages, if every page shows its owner and review date. Dedicated tools add sign-off tracking, reminders and version history, which help once you have many pages or an auditor to satisfy. Whatever you use, check that you can export the pages as ordinary files.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.