Most agencies I work with have a folder full of SOPs that nobody reads, nobody updates, and nobody enforces. Buried somewhere on their shared drive - in a folder called something like "Process Docs v3 FINAL" - gathering dust.
They were written with good intentions. Someone spent a Friday afternoon documenting how to onboard a client, manage a campaign handover, or handle a supplier purchase. Then they uploaded it, sent an email saying "FYI I've written this up," and never thought about it again.
And that's where most SOP programmes end. Not with a decision to stop. Just with silence.
The thing is, SOPs genuinely matter. They reduce reliance on individual knowledge, make onboarding faster, and give you a foundation for consistent delivery. But only if they're actually used.
So why do so many agencies get this wrong - and what does it actually take to get it right?
Someone's got to own it
When an SOP fails, the instinct is to blame the document itself. Too long. Too vague. Out of date. But in most cases, the document isn't the problem. The ownership model is.
There are two camps agencies tend to fall into, and both get it wrong in different ways.
The first is the ops-led model. The operations team writes the SOP, formats it beautifully, and hands it down to the team. The problem? The people closest to the process had no hand in writing it. They don't feel accountable to it and eventually ignore it the moment it gets in their way.
The second is the practitioner-led model. The person doing the work writes the SOP. Closer to reality, sure. But it's inconsistently formatted, rarely updated, and without anyone overseeing the bigger picture, nobody notices when it's drifted from best practice.
The answer isn't to pick one camp. It's to split the responsibility clearly.
Ops sets the standard and the template. The practitioner writes the first draft, owns the updates, and flags when something no longer reflects reality. Neither owns it alone - but both are accountable.
This matters more than most people realise. Ownership isn't just about who writes the document. It's about who feels responsible for its accuracy, who notices when it's being ignored, and who has the standing to do something about it. Without a named owner, an SOP has no advocate - and documents without advocates don't survive.
Where it goes wrong
Even with the right ownership model in place, SOPs can still fail. In most agencies, the same four problems come up again and again.
SOPs are written once and never revisited. The process changes, the SOP doesn't, and eventually the gap between what the document says and what actually happens becomes so wide that people stop consulting it entirely. At that point it's not just useless - it's actively misleading.
They're stored somewhere nobody navigates to. If finding the SOP requires three clicks through a folder structure that made sense to whoever built it two years ago, people will just ask a colleague instead. Accessibility isn't a nice-to-have. If people can't find it quickly, it doesn't exist.
There's no feedback loop. Nobody ever asks whether it's still accurate. Nobody flags when a step no longer applies. The SOP becomes a snapshot of a process that no longer exists. Good SOP culture means creating a habit of questioning - is this still right? Does this still reflect how we actually work?
And there's no enforcement. Not in a disciplinary sense - but when someone deviates from the process, nobody notices, nobody asks why, and nothing changes. If there are no consequences for ignoring an SOP, people will ignore it. Enforcement doesn't have to be heavy-handed. It just has to exist.
Getting buy-in from the team
You can write the best SOP in the world, assign a clear owner, and store it somewhere logical - and still have nobody follow it, because the team never bought into it in the first place.
Buy-in doesn't happen by announcing that SOPs are now important. It happens through involvement. When people have a hand in writing and shaping a process, they feel ownership over it. When they're handed a finished document and told to follow it, they feel managed.
A few things that make a real difference here.
Involve the team early. Before you write anything, talk to the people doing the work. Ask them how the process actually runs, where the pain points are, and what a good outcome looks like. You'll write a better SOP, and they'll feel consulted rather than dictated to.
Explain the purpose, not just the process. People are much more likely to follow a process when they understand why it exists. An SOP that explains the reasoning behind each step gets followed more consistently than one that just lists instructions.
Make it easy to challenge. If someone thinks a step is wrong or outdated, there should be a clear and easy way for them to flag it. SOPs that can't be questioned become SOPs that get ignored. A simple note at the bottom - "if something here doesn't reflect reality, flag it to [name]" - goes further than you'd think.
And finally, lead by example. If senior people in the agency aren't following the SOPs, nobody else will. It sounds obvious, but it's one of the most common reasons SOP programmes quietly die.
How to write an SOP people actually follow
Assuming you've got the ownership and buy-in right, the quality of the document still matters. A confusing, badly structured SOP will undermine even the best-intentioned process.
Start with the outcome, not the steps. Before you describe what to do, be clear about what good looks like. What does success look like when this process is done well? That context shapes everything that follows.
Write for a smart newcomer, not an expert. The expert already knows what to do - the SOP is for the person who doesn't yet. Write it so that someone joining the team next week could pick it up and follow it without needing to ask anyone for help.
Include the "why" behind key decisions. When people understand the reasoning, they make better calls when the situation doesn't fit the script. A rigid list of instructions breaks down the moment something unexpected happens. A well-reasoned process holds up.
Keep it as short as possible. The fewer pages, the more likely someone will actually read it. If it's running long, that's usually a sign it needs to be broken into multiple SOPs rather than padded into one unwieldy document.
Build in a review cadence. Every SOP should have a named owner and a review date. Quarterly for fast-moving processes, annually for stable ones. A review date on the document itself signals to the reader that this is a living document - not a historical record.
Why documentation is getting easier
One of the biggest reasons SOPs go stale is the friction involved in creating and updating them. If keeping one current means reformatting a Word document from scratch, most people won't bother. That's not laziness - it's a rational response to a bad system.
Tools like Scribe have largely removed that excuse. It records your screen as you complete a process and automatically generates a step-by-step SOP from what it captures - screenshots included. Updates are just as quick: re-record the relevant steps rather than rewriting the whole document. What used to take an hour now takes minutes.
Tango works in a similar way. Trainual goes further, turning SOPs into interactive training modules that can be assigned to team members and tracked. That's when an SOP starts to have real weight behind it - when there's a record of who's read it and when.
Beyond the time saving, these tools make SOPs genuinely better to use. They're more visual, more interactive, and a lot more engaging than a static Word document. If the barrier to reading an SOP has always been that they're dry and hard to navigate, these tools go a long way to fixing that too. An SOP that's actually enjoyable to follow is one that gets followed.
A final word
I'm a big fan of SOPs. It's not fair to blame someone for not following a process if there isn't a documented process for them to follow in the first place.
But writing one is only the start. Someone needs to take responsibility for it, someone needs to enforce it, and it needs to actually be used. Most importantly, it has to be under constant review - because an SOP that no longer reflects reality is a pointless document.
