Agency SOP Guide: How to Build, Maintain, and Scale Standard Operating Procedures

Every agency owner I meet has an SOP folder. Very few of them have working SOPs. The folder exists, the documents are in it, and the team still runs the work from memory and Slack. I have spent twelve years running delivery operations for digital marketing agencies, and this is the most repeatable failure I see: the documentation gets written, and nothing about how the work actually happens changes.

This piece is the how-to argument: how I would build, maintain and scale a procedure library inside your agency. If you would rather it were done for you, that is my SOP consulting work. What follows is the version you run yourself.

Why do most agency SOP projects fail?

The usual explanation is that they were not written well enough. I do not believe that. I have read elegant procedures nobody followed and scrappy checklists that held an agency together for years. The difference is decided before the first word is typed, by four design mistakes.

• It is run as a project. Projects have an end date. A procedure library does not end; it is a standing obligation, closer to client reporting than to a website build. Anything framed as a project gets celebrated at launch and abandoned by week six.
• It is written for the wrong reader. Most agency SOPs are written to impress somebody who is not in the room. The real reader is a stressed person halfway through a task who wants one answer in ten seconds. Those two documents share almost nothing.
• It sits outside the work. If following the procedure means leaving the tool the task lives in, opening a folder and searching, then asking a colleague will win every time. It should win. Asking is faster.
• Nobody is on the hook. “Ops owns the SOPs” means no one owns them. When the process changes and no named person has to reflect it, the document turns into fiction while everyone keeps pointing at it.

The result is the artefact I find in most agencies: a folder of long documents nobody has opened since the meeting where they were announced. The team is not lazy. They are correctly ignoring something that costs more to use than to work around.

What does a working SOP actually look like?

Short, embedded, owned, reviewed. Those four constraints get fixed before I write a word. What they do not tell you is what the document should contain, so here is the anatomy I use.

• A trigger written as an event. Not “onboarding process” but “a signed contract lands in the pipeline”. Procedures without a stated trigger do not get started at the right moment, which is a different failure from being badly written.
• Steps as single actions, in the imperative. “Send the welcome email from the shared inbox” is a step. “Manage client communications” is a heading pretending to be one. If a step contains the word “and”, it is usually two steps.
• The branches, not just the happy path. Most procedures document the route where nobody needed help. The value is in the exceptions: the client who will not grant analytics access, the judgement call nobody on shift is authorised to make. Write those, and name who decides.
• A definition of done. The observable condition that ends the task. “Report sent” is weak. “Report sent and logged in the client record, with the next send date set” can be checked by someone who was not there.
• One named owner, visible at the top. A person, not a department. The name is what makes the document answerable, and it tells a reader who to ask when the procedure and reality disagree.
• Two dates: last changed, next review. They let a reader decide in one second whether to trust the document. A procedure with no dates asks for blind faith it has not earned.

Then run the test almost everyone skips. Hand the procedure to a competent person who has never done the task, and watch them work through it without answering a single question. Every hesitation is a defect in the document, not in them. First drafts always fail it, which is the point.

One rule matters more than any format: write the procedure while doing the task, not afterwards from memory. Memory compresses. The steps you leave out are the ones you stopped noticing years ago, and those are exactly the ones a new person does not know.

Which processes should an agency document first?

Rank the candidates by how often the work happens multiplied by what it costs when it goes wrong. In a marketing agency of five to fifty people that arithmetic lands in nearly the same place every time, and it produces five procedures:

1. Client onboarding. More people touch a new account in its first fortnight than at any other point, and the client is forming their opinion of you the whole time. The document should cover access collection, the kickoff agenda, what gets promised about communication in the first thirty days, and who confirms each item is done.
2. The sales-to-delivery handoff. Write down what sales must hand over in writing: scope sold, anything promised verbally, budget, dates, and the client’s own words about what success looks like. Then add the step almost everybody omits: delivery formally accepting the handoff. Without acceptance you have a document, not a handoff.
3. Recurring client reporting. Cover the template, the data sources, who writes the commentary rather than the numbers, and the send date. Reporting is the first thing quietly downgraded in a busy week, and it is the one clients notice missing fastest.
4. QA before anything reaches a client. Keep it to a checklist that takes under five minutes, and name the person who signs it. A QA step with no signer is a suggestion, and suggestions lose to deadlines.
5. Offboarding. Every agency loses accounts, and the way the last two weeks are handled decides whether the client becomes a reference or a warning. Access removal, final handover of files and documentation, a short exit conversation, and a referral request that does not read as desperate.

The first two are fixed in that order. The middle three swap depending on where your agency is bleeding: if clients churn on communication, reporting goes first; if you are redoing work, QA does. Five is a deliberate ceiling. Agencies that start with twenty end up with twenty half-written documents and no habit.

How do you keep SOPs alive after they are written?

Writing is perhaps a third of the job. Maintenance is the rest, and it is mechanical rather than heroic.

• Put the review on the calendar as a task, not a policy. A recurring task assigned to the named owner, with the procedure linked inside it. Quarterly is enough for most things; monthly for anything client-facing that changes often. A policy that says “review regularly” produces no reviews.
• Make deviation the trigger for an edit. The most valuable signal you have is somebody doing the task differently from the document. The standing rule is that whoever deviates either edits the procedure or tells the owner the same day. It costs a minute and it is the difference between a library and an archive.
• Edit when the process changes, not at the next review. The review date is a safety net. If you rely on it as the mechanism, the document is wrong for however many weeks are left on the clock.
• Keep one procedure for the procedures. Where new ones are created, who approves them, how they are named, how they get retired. Skip it and the library grows two competing versions of onboarding, which is worse than having none.
• Retire without sentiment. A procedure for work you no longer do teaches the team that the library cannot be trusted, and that lesson spreads to the documents that are still correct. Delete it.

The tool matters less than people hope. I work inside ClickUp, Asana, Monday.com, Airtable and Notion, and connect them with n8n, and the same thing holds in all of them: a rough checklist attached to the task beats a polished document one click away. The strongest form of embedded is a step the tool performs by itself. For the wider operational view of what should already exist before you start writing procedures, I keep a running agency operations checklist.

When are SOPs the wrong thing to build?

• The process changes every week. Documenting a moving target produces something wrong on the day it ships. Stabilise the way the work happens first, then write it down.
• There is no team. If you are running solo, a procedure library is a way of feeling productive without selling anything. Your bottleneck is clients, not documentation.
• The argument is structural. If the room cannot agree who owns a process, or whether it should exist at all, writing it down only formalises the confusion. That is a question for business systems consulting: which processes exist, who owns them, how they connect. Documentation is the layer underneath a structure that already makes sense.
• What you want is automation. Sometimes the right answer is that no person should be following the procedure at all. If a step is purely mechanical and happens weekly, the useful output is a working trigger, not a paragraph asking someone to remember.

So does an agency SOP library actually pay for itself?

Yes, on one condition. My verdict after twelve years of this work: an SOP library pays for itself only if you treat it as a permanent maintenance obligation with named owners. Treated as a project with a launch date, it costs you a quarter and leaves you where you started. Five procedures kept current beat forty that were accurate once. If you adopt one habit, make it the review task with a name on it.

Where to start inside your own agency

If you want to know which procedures your agency should write first, and who should own each one, that is what the Agency Ops Audit answers. $1,500 fixed, two weeks, a written 90-day roadmap and a 60-minute readout call. If you would rather have it built, the retainer is $4,000 to $6,000 a month at 10 to 15 hours a week with a 90-day minimum, and a full implementation is $8,000 to $14,000 fixed. There is nothing attached to this article on purpose: a procedure you did not write from your own delivery week is somebody else’s process wearing your logo. My basis for that is twelve years running agency delivery, 79 completed engagements and a 4.9 out of 5 client rating, which is the record worth asking any consultant for.