How to Write an SOP Your Team Will Actually Use
Most SOPs are written once and never opened again. Here's how to write one short enough to follow and specific enough to matter.
How to Write an SOP Your Team Will Actually Use
Somewhere in your shared drive there's a folder called Processes. It has eleven documents in it. Nobody has opened nine of them since the person who wrote them left, and two are still titled "DRAFT".
That folder isn't a failure of discipline. It's what happens when you write a procedure as a record of how things should work, rather than a tool for the person doing the job on a busy Tuesday.
A useful SOP is closer to a pilot's checklist than a policy manual. And the evidence for checklists is better than most people in agencies realise.
Why a Boring List Works
In 2009, a team working with the World Health Organization tested a simple surgical checklist in eight hospitals around the world. Major complications fell from 11% to 7%, and inpatient deaths after major operations fell from 1.5% to 0.8%, across 7,688 patients.
These weren't untrained people. They were surgeons, and they didn't suddenly learn more surgery. The checklist caught the steps that experts skip when they're tired, rushed or sure they've already done them.
There's a caveat: that study compared before and after, with no control group, so it can't prove the checklist did all the work. And your agency isn't an operating theatre. But the mechanism travels. Expertise doesn't protect you from forgetting. If anything, it makes you more confident that you haven't.
The same failure shows up in agency work as the client who never got the kick-off notes, or the file that went out at the wrong size. Small misses, and they add up. In Setup's 2023 Marketing Relationship Survey, clients ranked dissatisfaction with value and with delivery as their top two reasons for ending an agency relationship. Agencies ranked those same two reasons eighth and ninth.
So the thing clients leave over is the thing agencies assume is fine. Consistent delivery is what an SOP is for.
Pick the Right Process First
Don't document everything. You'd spend a month writing and end up with a bigger Processes folder.
Start with work that meets at least two of these tests:
- It repeats. Monthly reports, client onboarding, content sign-off.
- A mistake is expensive. Anything that goes public, or goes to a client, without a second pair of eyes.
- One person holds it in their head. If they had a week off, the work would stop.
- New people keep asking about it. Every repeated question is a missing document.
If you can only write one, write the one where a mistake reaches the client. That's usually onboarding or the final approval step.
The Seven Parts of an SOP
You don't need a template with a revision history table and a page of definitions. You need these seven things, and most of them are a line or two.
1. What this covers and what it produces
Two or three sentences. Name the output. "This process takes a signed client to a live account with tracking confirmed and a kick-off held" is useful. "This document outlines our approach to client success" isn't.
2. When to start it
The trigger, as a real event: "when the contract is countersigned", not "when appropriate". If nobody knows when a process starts, it starts late.
3. Who owns it
One name or job title. Not a team. When a process has two owners it has none, and you'll find that out the first time something slips.
4. The steps
This is the document. Each step should have a verb, a person, a tool and an output, and a table handles that better than paragraphs:
| # | What to do | Who | Where | You've finished when |
|---|---|---|---|---|
| 1 | Request ad account access | Account Manager | Google Ads | Access accepted |
| 2 | Record baseline numbers | Analyst | Shared sheet | Sheet saved in client folder |
Keep it to between eight and twelve steps. Longer than that, and you're probably describing two processes.
5. The quality check
Five or six yes-or-no questions that someone can answer without opinion. "Is it good?" fails that test. "Does every link in the report open?" passes it.
6. What goes wrong, and what to do then
The most valuable part, and the part most people skip. What happens when the client goes quiet? Who decides when the deadline slips? Write down the failure you've already lived through once.
7. When it gets reviewed
A date and a name. A process that was accurate in March can be quietly wrong by October, and a wrong SOP is worse than none, because people trust it.
How to Write It Without It Becoming a Project
The best method takes an hour and doesn't start with a blank page.
- Catch someone doing the work. Sit with the person who does it best, the next time they do it for real, and write down each step as it happens.
- Write the draft in plain words. If a step needs a paragraph of explanation, split it into two steps.
- Hand it to someone who's never done the job. Ask them to follow it without asking you anything. Every question they ask is a gap.
- Fix the gaps and use it next time. It'll be wrong somewhere. Correct it straight after the job, while you remember.
Step three is the one that matters. It's also the one everyone skips, because it's slightly embarrassing to watch someone get stuck on a document you thought was clear.
A quick test: if your SOP needs a meeting to explain it, it isn't finished yet.
Where SOPs Go to Die
A few patterns kill these documents, and you'll recognise most of them.
Written for an auditor. Long, formal, and full of phrases like "shall ensure". People stop reading at the second paragraph.
Too vague to fail. "Review the work carefully" gives nobody anything to do. Replace it with what to check.
Filed where the work doesn't happen. If the team lives in Slack and Asana, a document in a folder four levels deep doesn't exist. Link the SOP from the recurring task that triggers it.
No owner after launch. The person who wrote it moved on, and now it describes a tool you cancelled last year. We wrote about what walks out of the door when someone leaves, and undocumented process is a large part of it.
The Honest Trade-off
SOPs have a real cost, and it isn't the writing. It's the rigidity.
If you're a team of two who sit next to each other and do something different every week, a stack of procedures will slow you down. Creative work in particular shouldn't be scripted: write SOPs for the steps around the creative thinking, such as the brief, the review and the delivery, and leave the thinking alone.
A procedure also won't rescue a broken process. If your approvals take three weeks because nobody can decide who approves, writing that down just makes the problem official. Fix it first, then document the fix.
Start With a Draft
The blank page is the hardest part, so don't start there. A rough first version that someone corrects is much faster than one they write from nothing.
Generate a free SOP for your agency
Treat whatever you get as a first draft. Check it against how your team really works, then run the test above.
An SOP doesn't need to be complete. It needs to be opened. Write the shortest version that would stop your last mistake from happening again, put it where the work happens, and improve it every time it fails.
