SOP vs Process vs Checklist: What Agencies Actually Need
Ask five agency owners what their SOP is for reporting and you’ll get a process, a checklist, and a paragraph of prose masquerading as instructions, and none of the five people will notice they gave you three different kinds of document. I’ve spent twelve years running delivery operations for marketing agencies, and this confusion is not academic. Agencies pay for documentation that fails because they wrote the wrong shape of document for the problem they had, not because they wrote it badly.
The three terms get used as synonyms. They aren’t. Here’s the distinction I use, and the test for which one a given problem actually needs.
Three artifacts, three different jobs. Confuse them and you get exactly what most agency documentation folders contain: SOPs nobody reads because they were never really SOPs, checklists that quietly hide the judgment calls a person actually has to make, and processes so vague nobody can tell what stage a project is even in.
What is a process?
A process is the sequence of stages a piece of work moves through, from what starts it to what finishes it, independent of who runs any single stage or how they do it. “Client onboarding” is a process: contract signed, access collected, kickoff held, first deliverable produced, thirty-day check-in. A process answers one question only: what comes next.
A process is a map. It has no opinion on how you drive between stops.
What is an SOP?
A standard operating procedure is the written instructions for one stage in that sequence, detailed enough that a competent person who has never done the task can complete it correctly without asking anyone. An SOP has a trigger, a set of steps written as single actions, the branches for what to do when the happy path doesn’t hold, and a definition of done that someone who wasn’t there can check. I’ve written the anatomy of a working one, and the four reasons most agency SOPs fail before anyone opens them, in full in the SOP guide. I won’t repeat it here.
An SOP is turn-by-turn directions for one stop on the map. It exists because that stop involves a decision a checklist can’t make for you.
What is a checklist?
A checklist is a short list of binary checks performed at a single point, usually right before work ships or a status changes, that confirms finished work meets a fixed bar. Every line answers yes or no. A checklist doesn’t teach anyone how to do anything. It only checks that it was already done correctly.
A checklist is what you glance at before you board. It has one job: catch what shouldn’t leave.
Put together: a process is the sequence, an SOP is the instructions for one stage that needs judgment, and a checklist is the yes-or-no check that confirms a stage that needed no judgment was actually done. Different questions, different documents, different failure modes when you get the wrong one.
Why do agencies keep writing the wrong one?
Here’s the failure I see most: an SOP written for work that only needed a checklist. QA before a deliverable ships is the clearest example. The task requires no judgment; it requires confirmation that six specific things are true. Writing that as narrative instruction, in paragraphs, with a preamble about why quality matters, produces a document that takes real time to write and gets skimmed on the one day it’s supposed to catch something. A checklist for that same gate takes five minutes to read and either gets completed or visibly doesn’t. Where an SOP costs you an hour to write and decays the moment one detail in it goes stale, a six-line checklist barely has surface area to go wrong.
The rarer, costlier version runs the other way: a checklist forced onto a step that actually has branches and judgment calls in it. A client who won’t grant analytics access, an approval that needs escalating, a scope question nobody on shift is authorised to answer alone. Squeeze that into yes-or-no lines and you get a checklist with forty items trying to cover every branch, or six items that quietly skip the branch that will actually happen this week. That step needed an SOP with named exceptions, not a longer checklist.
I’ve seen both mistakes stacked in the same document. A twelve-page “SOP” for client reporting that spends four pages narrating how to pull the numbers (a checklist’s job, five lines, done), skips the one branch that actually causes late reports (what happens when the data source is down, which needed the SOP’s judgment call), and never states the order reporting sits in relative to the rest of onboarding (which is process information and belongs in neither). One document, doing none of the three jobs well, because nobody separated them before writing started.
Both mistakes come from the same place: nobody asked what kind of failure the document was supposed to prevent before deciding what to write.
How do you choose between them?
Ask three questions, in order.
- Am I describing a sequence of stages, or one stage? A sequence is a process. One stage, keep going.
- Does this stage involve a decision that changes depending on the situation? If yes, it’s an SOP, and the branches are the part worth writing down. If no, keep going.
- Am I confirming something is already done and correct, rather than teaching anyone how to do it? That’s a checklist.
Most agencies stop at question one and try to make a single document answer all three. That’s how you end up with an “SOP” that’s really a process with no instructions inside any of its stages, or a “checklist” trying to hold branching logic it can’t express in yes-or-no lines. The three artifacts nest. A process is made of stages. The stages that carry real judgment get an SOP. The stages that gate what reaches a client get a checklist, often as the last line inside the SOP for that stage rather than as a separate document at all.
The artifacts and the specific fields each one needs, across the six documents that come up most in agency delivery (briefs, intake, status updates, handoffs, QA, reporting), are in the templates piece. Several of those are checklists wearing a template’s name; a couple are closer to SOPs. The distinction still holds once you’re looking at the actual document.
So which one does your agency actually need?
Almost certainly more checklists than you have, and fewer full SOPs than you think. In every delivery operation I’ve reviewed, the gate before something reaches a client is the least protected step and the cheapest one to protect. It only needs a checklist. Meanwhile the SOPs that get written are often for stages nobody has ever gotten wrong, because writing an SOP feels more like real documentation work than writing six checkboxes does, and that feeling is not a reason.
Start by mapping the process (the stages, in the order work actually moves through them). Then, for each stage, ask whether anyone has ever done it wrong, and whether the wrong version involved a decision or a missed check. Decision stages get an SOP. Missed-check stages get a checklist. Most stages get neither, because most stages don’t need documentation at all; they need someone to have named a trigger and an owner, which is process work, not procedure work.
None of the three is worth writing for work that happens once or changes shape every time you do it. A process, an SOP and a checklist all earn their cost through repetition. If a task hasn’t happened the same way twice yet, write nothing and watch it happen a third time first.
Where to start
If you’d rather have this diagnosed for your own agency, rather than argued about in the abstract, that’s the kind of build I take on as SOP consulting: which stages need a process, which need a procedure, which need a checklist, and who owns each one.
Or start with the diagnosis itself. The Agency Ops Audit is a $1,500 fixed-fee review: two weeks, a written 90-day roadmap, and a 60-minute readout call. It tells you which of your gaps is a missing process, which is a missing procedure, and which is a missing checklist, before you spend a week writing the wrong one.
