Agency SOPs that survive growth (and the ones that don't)

TL;DR

Most agency SOPs fail the same way: written in a burst of process enthusiasm, stored in a doc nobody opens, dead within a quarter. The fix isn't better writing — it's recognizing that there are two kinds of SOP and only one of them belongs in a document. Reference SOPs (how we name things, how we talk to clients, what good looks like) live in docs and need an owner and a review date. Executable SOPs (onboarding, weekly optimization passes, monthly reporting, offboarding) shouldn't be documents at all — they should be templated, recurring work in your system of record, where skipping a step is visible and "did we do it" is a filter, not a memory test. Document five processes first — client onboarding, the per-department weekly beat, monthly reporting, access management, and offboarding — and adopt the one maintenance rule that matters: every SOP has exactly one owner and an expiry date, and an expired SOP is treated as wrong until re-verified.

---

Every agency past about eight people attempts the SOP project. A Notion wiki appears. Twenty pages get written in a weekend of founder energy. Six months later a new hire follows one, breaks something, and is told "oh, we don't do it that way anymore." The wiki is now worse than nothing — it's confidently wrong.

The failure isn't effort. It's a category error about what an SOP is.

Reference SOPs vs executable SOPs

Reference SOPs answer "how do we do things here." Naming conventions for GTM containers. Tone rules for client emails. The escalation ladder when a client is unhappy. What a finished deliverable looks like per department. These are genuinely documents: read at onboarding, consulted occasionally, stable for quarters at a time.

Executable SOPs answer "what do we do next." Onboard this client. Run this week's PPC pass. Produce this month's report. Revoke this departed employee's access. These have steps, owners, and deadlines — and the moment you write them as prose, you've built a system where compliance is invisible. Nobody can see whether step 6 happened. The document can't tell you which client skipped it.

Executable SOPs belong in the work system as templates: a checklist that instantiates as real tasks with real assignees and real dates, every time the trigger fires. The difference is enforcement-by-structure — exactly the operating-rhythm argument from our digital marketing project management post. When the weekly PPC pass is a recurring task template, "did we run it for Client X" is a glance at the board, and a skipped step is a visibly stuck task instead of a silent omission. (This is why Phloz's recurring templates and our standard template set exist — but the principle holds in any tool that can template work.)

The five SOPs to build first

Resist documenting everything. Five processes cover the moments where agencies actually bleed:

1. Client onboarding. The highest-stakes 60 days in the relationship, and the process most often improvised. We published the full onboarding checklist — the SOP version is that checklist as a template that fires on every signed contract, with the tracking audit and access mapping as non-skippable steps.

2. The per-department weekly beat. PPC, SEO, social, CRO each have a weekly minimum (the passes that catch budget runaways, ranking drops, and dead pixels before clients do). Department leads own the template's contents; the department workflows breakdown is the starting point.

3. Monthly reporting. Not the report's design — the process: data verified by the 3rd, draft by the 5th, AM review by the 7th, sent by the 9th. Dates make late visible.

4. Access management. Who has admin on which client's ad accounts, GTM, GA4, hosting? This SOP has two halves: grant (recorded at onboarding) and revoke (fires on any departure — yours or the client's staff). Agencies that skip it discover ex-employees with live ad-account admin during an incident, never before one. The grant half is half the reason we built the tracking infrastructure map: access only stays known if it's recorded where the infrastructure lives.

5. Client offboarding. The forgotten one. Final deliverables handed over, access transferred (not deleted — transferred), billing closed, a post-mortem run per the retention playbook. Offboarding well is how you stay referable to the network of people who just stopped paying you.

Writing them so they stay true

Three rules, earned from watching wikis rot:

One owner per SOP, by name. "The team" owns nothing. The owner isn't the person who executes it — they're the person who fixes it when reality drifts.

An expiry date on every SOP. Ninety days for executable, 180 for reference. The rule with teeth: an expired SOP is presumed wrong — anyone may flag it, and the owner re-verifies or retires it. This single convention kills the confidently-wrong wiki, because staleness becomes a state the system tracks instead of a discovery made mid-mistake.

Written from a recording, not from memory. The fastest accurate SOP: screen-record the current-best person doing the task, have the most junior person transcribe it into steps, then have a different person execute from the steps alone. Memory-written SOPs document the idealized process; recordings document the real one, including the workaround in step 4 that turns out to be load-bearing.

The growth test

An SOP system is working when three things are true: a new hire completes their first client onboarding without asking "what's next" (the template told them); a department lead can take two weeks off without their weekly beats silently stopping (the templates fired anyway); and when something breaks, the post-mortem question is "which step failed" rather than "did we have a step." That last one is the real prize — processes turn incidents into specific fixes instead of general anxiety.

Agencies don't scale by hiring people who don't need processes. They scale by building processes that don't need heroes — and then keeping them true with owners and expiry dates instead of optimism.