Operations · Processes
How to Write an SOP Your Team Will Actually Follow
Most standard operating procedures die in a shared drive. Here is how to write one short enough to use, specific enough to trust and easy enough to keep current.
- (Author)
- Nadia Holloway
- (Published)
- (Reading)
- 4 min
- (Section)
- Operations
In this guide 6 sections
A standard operating procedure, or SOP, is just a written answer to the question "how do we do this here?" Small companies usually need them at the exact moment they have the least time to write them: when the person who knows how to run payroll, or process returns, or reorder stock is about to go on holiday. The result is a long, rushed document that nobody opens twice.
The fix is not more detail. It is a smaller, stricter format. The steps below are the ones we used to document around sixty recurring tasks at a 40-person online retailer, and the rules that kept those documents alive for years afterwards.
Step 1: Pick the task that hurts most
Do not start by documenting everything. Start with the task that causes the most damage when it goes wrong or when its one owner is away. Month-end invoicing, supplier reorders and refunds are common first picks. A useful test: if this task were skipped for two weeks, who would notice, and how much would it cost?
Step 2: Write it while someone does it
Sit next to the person who does the task, or share their screen, and write down each action as it happens. People who do a job every week skip steps when they describe it from memory, because those steps have become automatic. Watching catches the small things: the filter that has to be set before the export, the second tab that has to be checked.
Record it first
A screen recording with narration takes ten minutes and gives you something to write from later. Keep it linked at the top of the SOP for anyone who prefers to watch.
Step 3: Use one format for every SOP
Consistency is what makes a library of procedures usable. Every SOP we kept had the same five parts, in the same order:
| Part | What goes in it |
|---|---|
| Purpose | One sentence: what this task achieves and why it matters. |
| Trigger | When it happens: a date, an event or a request. |
| Steps | Numbered actions, each starting with a verb. |
| Done when | The check that proves the task is finished. |
| Owner and review date | Who keeps this current, and when they next look at it. |
Steps should be short enough to tick off. "Export the open orders report" is a step. "Check the orders and sort out any problems" is a wish. Where a step needs judgement, say what the judgement is based on: "If the refund is over £200, ask the operations lead before approving."
Step 4: Test it on a newcomer
Hand the draft to someone who has never done the task and watch them follow it without help. Every time they hesitate or ask a question, the document has a gap. This is the single most useful step in the process and the one most teams skip. It usually takes two rounds before someone can complete the task cold.
If a new starter can follow it on a Monday with nobody to ask, it is finished. If they cannot, it is a draft.
Step 5: Give every SOP an owner and a date
Procedures go stale when software changes, suppliers change or someone finds a faster way and never writes it down. Put a named owner and a review date at the top of each document, and put the review dates in a calendar. Quarterly is enough for most tasks. Anything tied to a tool should also be reviewed when that tool changes; our guide to moving from spreadsheets to a project tool covers how to keep process docs and task lists in step.
Where to keep them
The best place is wherever your team already looks. A shared drive folder with a simple index works for most companies under twenty people. Larger teams often move SOPs into a wiki so they can link between them. What matters more than the tool is a single, obvious home and a naming pattern people can guess, such as "Finance – Month-end invoicing". Formal quality systems like ISO 9001 go much further, but the core idea of documented, repeatable procedures is the same at any size.
Once the first few are written, the same habit carries into the rest of the business: onboarding new starters gets faster, and handing a task such as warehouse coordination to someone else stops being a risk.
