How to write an SOP your team will actually use
How to write SOPs that actually get used at a small agency - the lightweight template that works, how to keep SOPs current, and the mistake that kills 90% of process docs.
Part of the systemise your agency guide
Why most SOPs sit unused
Almost every agency has a folder of SOPs nobody opens. The documents exist; they're just useless at the moment of doing the work. The reason is consistent: they were written for an auditor (long, prose-heavy, hedged) instead of for a busy person about to start the task who needs to know exactly what to do next. Useless SOPs aren't a discipline problem - they're a writing problem.
The good news is the fix is small. A short, skimmable, opinionated SOP that lives where the work happens gets used. A polished one buried in a wiki doesn't. Here's the template that works.
The SOP template that gets used
Keep every SOP to one page if you can. Six sections:
SOP - [Short, action-oriented title]
Owner: Last reviewed:
1. Purpose
One line: what this SOP exists to do.
2. When to use
The trigger - the specific moment this gets opened.
3. Steps
Numbered, imperative. Screenshots for any step
that needs one. No prose paragraphs.
4. Example
A real worked instance, ideally a recent one.
5. Definition of done
How you know it's complete.
6. Common mistakes
The 2-3 things that go wrong most often.Two parts everyone forgets: the owner (a person, not a team - documents without one expire in six months) and last reviewed (so anyone reading it knows if it's current). Add a definition of done so "finished" isn't a matter of opinion, and an escalation path if the SOP doesn't fit the situation.
How to keep them alive
A written SOP is half the work. The other half is making sure it's still right in six months. Three rules:
- Link it from the workflow. Drop the SOP link into the project tool / calendar invite / Slack channel where the work actually happens. If someone has to search for it, they won't.
- Review quarterly. Every SOP gets opened by its owner every three months. Out of date → fix it. Out of use → archive it.
- Trigger an update on the moment it broke. If something went wrong because the SOP was wrong, the fix to the SOP is part of the post-mortem, not a separate task you'll get to later.
The other quiet enemy is over-engineering. Don't write SOPs for processes you do once a year - it's not worth the upkeep. Write them for the dozen things you do every week.
How SOPs fit the bigger picture
SOPs are the unit of an agency operations manual. They underpin every productized service, every clean handoff, and every AI workflow. For the wider picture - how SOPs sit alongside the manual, RACI, and the team hub - see the systemise your agency guide. For AI workflows specifically (which are SOPs in another form), see the AI for agencies guide.
Frequently asked questions
How do you write an SOP for an agency?
Use a short, skimmable template: purpose (one line), trigger (when to use), numbered steps with screenshots where needed, a worked example, a definition of done, and common mistakes. Add an owner and a last-reviewed date. Keep it to one page if you can.
Why don't my SOPs get used?
Almost always because they're written for an auditor - long, prose-heavy, hedged - rather than for a busy teammate about to start the task. Rewrite them as skimmable numbered steps, link them from inside the workflow that needs them, and don't bury them in a wiki.
How do you keep SOPs current?
Give every SOP a single owner who reviews it quarterly, fix the SOP as part of any post-mortem where it was wrong, and archive ones that aren't being used. Documents without owners go stale within six months.
Should every process have an SOP?
No. Write SOPs for the dozen things you do every week, not the things you do once a year. The maintenance cost of low-frequency SOPs usually outweighs the benefit.