SOP Audit for Agencies: What to Assess
If your agency already has SOPs and something about them still feels off, this is not the piece that tells you whether you need them in the first place. That question belongs to agencies with nothing written down. It is also not the guide to building a procedure library, which assumes you are starting from a blank folder. You are past both of those. You have documents. What you do not have is confidence that they are still true, that anyone opens them, or that anyone is responsible for either.
I have spent twelve years running delivery operations for marketing agencies, and reviewing a procedure library that already exists is now part of what I get hired to do, so read the bias in early. An SOP audit is not a proofread. It does not ask whether the document is well written. It asks four separate questions, and most libraries fail at least one of them without anyone noticing, because nobody has ever asked all four in the same sitting.
What does an SOP audit actually check?
An audit runs a procedure library through four separate checks, and a library can pass one and fail the rest without anyone noticing until someone asks all four at once.
- Coverage. Which processes that matter have nothing written down at all.
- Accuracy. Whether the document still matches what the team actually does today.
- Usage. Whether anyone actually opens it, and how you would know either way.
- Ownership. Whether a name, or better a role, is actually responsible for it.
Run those four checks against a real library and the result is rarely a clean pass or fail. It comes out as a triage list: which procedures to fix, which to rewrite, which to merge, and which to delete. That last option is the outcome most audits never produce, and it is usually the most useful thing the audit finds.
Coverage: which processes have nothing written down at all?
Coverage does not ask whether an existing document is any good. It asks a narrower question first: build the list of processes that should have something written down, independent of what is actually in the folder, then compare the two. Anywhere a client is handed off between people, anywhere a mistake is expensive to repeat, anywhere a new hire would otherwise have to ask someone rather than read something, that process belongs on the list. Onboarding, the QA pass before something ships, escalation when a deliverable is going to miss its date, offboarding a client, and what happens when scope changes mid-project are the categories that show up in most agencies. A gap here is not a document that reads badly. It is a category with nothing in it at all.
This pass says nothing about whether the document that does exist is any good, and it should not try to. A process with a bad document and a process with no document are different problems, and conflating them is how audits end up rewriting things that only needed fixing, or worse, leaving a genuine gap alone because a mediocre placeholder made the checklist look complete.
Accuracy: does the document match what the team does now?
Reading a procedure and asking whether it sounds right is not an accuracy check, it is a comprehension check. The actual test is to find whoever did the task this week and ask them to walk you through it live, in the tool where the work actually happens, step by step, next to the document. The gap between what the document says happens at step four and what that person actually does at step four is where accuracy drift lives, and it is almost never visible from reading the document alone.
Tools change their interface. People find shortcuts that work better than the documented order and never report it back. A new hire gets shown the task by someone who was themselves taught a slightly wrong version, and the drift compounds one generation at a time. None of that means anyone did anything wrong. It means the document is a snapshot, and snapshots age the moment the work underneath them moves.
Usage: does anyone actually open this, and how would you know?
This is the pass most audits skip, because it is the hardest to answer honestly and the easiest to assume. Most of the tools these documents live in log something: a last-viewed date in Notion, a last-modified timestamp in Airtable, an activity feed in ClickUp or Asana. That data tells you the document was opened. It does not tell you the person who opened it used what they read, or that opening it was even necessary rather than habitual.
The more honest test does not live in a log at all. Ask whoever did a task this week where they looked it up last, and watch the answer arrive. If it comes back as I asked so-and-so, the document is not being used, no matter what the activity feed says, because the actual answer to how do we do this still lives in a person’s head, not in the library. No complaints about a document being wrong is not evidence anyone opens it. It usually just means nobody has hit the situation yet that would force them to check.
Ownership: is there a name against each one?
Whether a role rather than a person is named against a procedure, what level of approval a change should require, and what actually happens when someone ignores the document anyway, is a separate question I have already answered in full in the piece on SOP governance. Restating that structure here would just be a shorter, worse version of it. For the audit itself, the ownership pass is a single yes or no: can anyone in the agency answer, without guessing or checking with someone else first, who is responsible for this document right now. If the honest answer is a shrug, mark it unowned and move to the next one. Fixing that belongs to the governance piece, not this one.
Fix, rewrite, merge, or delete: how do you triage what the four passes find?
Score each procedure against the four passes and a pattern falls out on its own. A document that is accurate, used, and owned needs nothing from you. A document missing on any one of the other three points toward a specific action, not a general sense that something is wrong.
| What the four passes find | Triage call |
|---|---|
| Accurate, used, and owned | Leave it alone. Not every procedure needs the audit to do something to it. |
| Present and owned, but drifted from what the team actually does | Fix. A targeted edit closes the gap without touching the rest of the document. |
| Built for a process that has changed shape, not just a few steps within it | Rewrite. A patch on the wrong structure reads accurate in places and useless as a whole. |
| Two or more documents covering the same process, usually written at different times by different people | Merge. Keep whichever is closer to current practice and retire the other. |
| Not opened in months, describing a process that no longer runs this way, or duplicating one you just merged into | Delete. Retiring it is a legitimate outcome, not a failure to keep something maintained. |
Why does the delete option get skipped almost every time?
Every other outcome in that table produces more work: an edit, a rewrite, a merge that still leaves one document standing. Delete is the only call that removes something from the folder instead of adding to it, and that is exactly why it gets skipped. Someone spent real time writing the document being deleted, and marking it for removal can feel like criticizing that person even when the role they wrote it for has changed twice since. It is easier to leave a stale document sitting quietly in the folder than to be the one who takes it out.
There is a second reason, and it is structural rather than emotional. An audit with no delete option only ever adds to the list. Every finding becomes a new task, a rewrite, a field to fill in, and the team runs the process once, sees a longer to-do list at the end of the audit than they had at the start of it, and does not schedule the next one. Deleting belongs on the same footing as fixing, rewriting, and merging, not as a last resort you reach for only when nothing else applies. If a process has genuinely changed shape, or a merge has left one document plainly redundant, removing it is not giving up on documentation. It is refusing to leave something wrong in a place where someone will eventually trust it.
So what does a finished SOP audit actually produce?
My basis for how I run this is twelve years inside marketing agency delivery operations and 92 completed engagements, working inside ClickUp, Asana, Monday.com, Airtable, and Notion, with n8n handling the parts of a procedure that should never have been a manual instruction at all. A finished audit is not a report describing your library in general terms. It is a decision against every procedure in it: fix, rewrite, merge, delete, or leave alone, with a name against each decision, not a fresh document explaining the state of things. The ratio across those five outcomes matters more than the list itself. If nothing in your library gets marked for deletion, either the audit was not thorough, or whoever ran it was too uncomfortable removing something someone else wrote to call it what it was.
Where to start
You do not have to run this against your whole library alone, or guess at which of your procedures are worth the time before you start. That is what the Agency Ops Audit checks alongside the rest of your delivery operation: $1,500 fixed, two weeks, a written 90-day roadmap, and a 60-minute readout call that tells you which of your procedures to fix, which to rewrite, which to merge, and which to finally delete.
