Most agencies do not have an SOP problem. They have a "the SOP exists but nobody opens it" problem.
Somebody spent a fortnight in year two writing beautiful process documents. They live in a folder. New hires are pointed at the folder during their first week and never return to it, because the documents describe an idealised version of a process that has since changed three times.
The agencies where SOPs actually work do two things differently. The documents are short enough to read while doing the task, and they live inside the tool where the task happens rather than in a separate library.
This guide covers which SOPs are worth writing first, the format that survives contact with a busy team, and how to stop them decaying.
What an agency SOP is, and what it is not
A standard operating procedure is a written description of how one recurring task gets done, specific enough that a competent person who has not done it before produces the same result as someone who has.
That last clause is the test. If two people can follow your document and produce noticeably different output, it is not an SOP. It is a description.
An SOP is not a training manual, a policy, or a knowledge base article about your industry. It covers one task, from a defined trigger to a defined finished state.
Trigger, steps, done. If a document does not have all three, it will not get used, because the reader cannot tell when to open it or when to stop.
Why most agency SOPs fail
They are written for an audience that does not exist. Most SOPs are written as if for a stranger with no context. In practice the reader is a new hire in week three who knows the general shape of the job and needs the specifics: which template, which folder, who approves, what the client hates.
They are too long. A twelve-page document describing a forty-minute task will not be read during the forty minutes. People skim it once and then guess.
They live somewhere separate. If the SOP is in Notion and the work is in your project tool, the SOP is one context switch away, which in practice means it does not exist.
Nobody owns them. Documents without a named owner and a review date drift out of date silently. Then someone follows an out-of-date SOP, gets it wrong, and the team learns not to trust the library.
They were written all at once. A documentation sprint produces thirty documents of uniform mediocrity. Writing one SOP each time something goes wrong produces a library that maps precisely onto your actual failure modes.
Which SOPs to write first
Write in order of blast radius: the tasks where a mistake is most expensive or most visible to the client. For most agencies that ordering is:
1. Client onboarding. The most expensive process to get wrong, and the one most often improvised. Everything from countersigned contract to first deliverable. Our full client onboarding checklist can be lifted straight into this one.
2. Account access requests. Which platforms, which permission level, who asks, and what to do when the client's IT department says no. Mistakes here are permanent in a way most agency mistakes are not, because asset ownership on Meta and TikTok is difficult or impossible to reverse.
3. Client offboarding. Data handover, ownership transfer, revoking access, final invoice. Skipping this is a security and compliance exposure, not just an untidy exit. See the offboarding checklist.
4. Reporting. Where the numbers come from, what goes in the report, what the commentary must address, when it goes out. The most repeated task in most agencies and the one where inconsistency is most visible to clients.
5. Approvals and quality control. What gets checked before anything reaches a client, and by whom. This is the SOP that prevents the errors the other SOPs cannot.
6. Escalation. What counts as urgent, who gets contacted, in what order, and what the client is told while it is being fixed.
7. Handover between team members. Holiday cover and staff departures. Rarely written, always needed at short notice.
Seven documents. That covers the majority of what actually goes wrong at an agency under thirty people. Resist writing the other forty until something breaks that needed one.
A format that survives real use
Keep every SOP to this shape. One page where possible, two at most.
Title. The task, phrased as the person searching would phrase it. "Send the monthly client report", not "Reporting procedure v2".
Owner and last reviewed. A name and a date, at the top. Both visible without scrolling.
Trigger. The specific event that starts this. "The first working day of the month" or "A deal moves to Won".
Prerequisites. What must already be true, and the access or tools needed.
Steps. Numbered, one action each, in the imperative. Link directly to the template or dashboard rather than describing where it lives.
Definition of done. How the person knows they have finished, stated as something observable.
Common problems. Three or four things that actually go wrong, with what to do. This section is what makes the difference between a document people read once and one they return to.
Escalation. Who to ask when it goes wrong in a way not listed.
That is it. No scope statements, no revision history tables, no glossary. Those exist for auditors, and you do not have auditors.
Worked example
Send the monthly client report
Owner: Account Director. Last reviewed: 1 September 2026.
Trigger: First working day of the month.
Prerequisites: Access to the client's ad account, analytics property and the reporting dashboard. Previous month's report to hand.
Steps:
- Refresh the dashboard for the reporting period.
- Check the spend figure against the platform directly. If they disagree by more than two per cent, stop and escalate.
- Write the commentary. It must cover: what changed against last month, why, and what you are doing about it next month.
- Include one number the client did not ask for but should care about.
- Send to the Account Director for review by the second working day.
- Send to the client by the third working day, on the agreed channel.
- Log it against the client record.
Done: The client has the report, the send is logged, and the next month's task exists.
Common problems: Dashboard figures lag the platform by up to 48 hours - pull on day two, not day one. If a campaign was paused mid-month, say so in the commentary rather than letting the client find the gap. If results are bad, the report still goes out on time; delaying a bad report is how a bad month becomes a lost account.
Escalation: Account Director, then the Head of Delivery.
The "common problems" section there is worth more than the seven steps above it. It is the accumulated experience of everyone who has sent that report badly.
Where SOPs should live
The ranking that matters:
Best: inside the tool where the work happens. A checklist attached to the task itself, generated automatically when the work is created. Nobody has to remember the document exists because it arrives with the job.
Acceptable: one searchable library, linked from the task. A single place, with links from the project tool into it. Requires discipline but works.
Poor: a documents folder. Findable only if you already know it exists and what it is called.
Useless: individual drives, email threads, someone's head. This is where most agency process actually lives.
The practical version: if your CRM or project tool supports task templates, your SOPs should be task templates. Cloning a checklist against a client is the same act as following the SOP, so compliance stops being a discipline problem and becomes the path of least resistance.
Inflowave does this from the pipeline: when a deal moves to Won, the onboarding task set generates against the right owner with the steps already in it, so the process runs whether or not anyone remembers the document.
Keeping them alive
One owner per SOP. Named, not a team.
Review on a schedule and on failure. Quarterly, and immediately after anything goes wrong that this SOP should have prevented.
Every incident produces an edit. When something breaks, the last question in the post-mortem is which SOP needs changing. Over a year this builds a library shaped exactly like your real failure modes rather than your imagined ones.
Let the doer edit. If updating an SOP requires a request to someone else, it will not happen. The person who found the gap should be able to fix it.
Delete aggressively. An SOP nobody has opened in a year is either describing a task you no longer do or one nobody needed help with. Both mean delete it.
Questions we get asked
How many SOPs does an agency need?
Fewer than you think. Seven core processes cover most agencies under thirty people. Volume is not the goal; the goal is that the expensive tasks are consistent.
How long should an SOP be?
One page. Two if the task is genuinely complex. If it runs longer, the task is probably two tasks.
Who should write them?
The person who does the task, edited by the person who owns the outcome. SOPs written by managers who do not do the work describe how they imagine it is done.
What is the difference between an SOP and a workflow?
An SOP is the written procedure. A workflow is that procedure implemented in software so the steps are triggered, assigned and tracked automatically. The SOP is the specification; the workflow is the running version.
Should SOPs be video or written?
Written, with video as a supplement for anything where the interface matters. Video cannot be skimmed, searched or edited in thirty seconds, and all three are what make an SOP get used.
How do we get the team to actually follow them?
Stop treating it as a compliance problem. If following the SOP is harder than improvising, people will improvise. Put the checklist inside the task and the problem mostly disappears.
