A few years ago, one of my best project managers left the studio with two weeks' notice. She'd been running our client review process for eighteen months — who signed off, in what order, what "approved" actually meant contractually. None of it was written down. It lived in her head and in a Slack channel nobody else read. It took us six weeks and two missed client deadlines to reconstruct what she'd been doing quietly and well.
That's the moment most agencies discover they don't have a business — they have a person the business depends on.
I've run a product studio and now build AI automation systems for agencies across healthcare, recruitment and operations, and the pattern repeats everywhere: teams that document nothing scale by adding more meetings, not more capacity. Teams that document the right things scale by removing themselves from the loop.
Agency Reliability = Documented Process × Consistent Execution ÷ Founder Involvement. The lower the denominator, the more the business runs without you re-explaining the same thing for the fortieth time.
Here's how to actually build the library, not just start a folder that dies in month two.
1. Document failure points first, not everything
Don't try to write fifty SOPs in a weekend. Start with the three or four moments where things have actually gone wrong: a missed handoff, an inconsistent client review, an onboarding that took a new hire four weeks longer than it should have. Those are your first SOPs, because they're the ones with a receipt attached — you can point to the cost of not having them.
Research on knowledge loss backs this up: replacing an employee typically costs 50–200% of their salary once you count lost productivity and ramp time, and 56% of managers report that knowledge loss makes onboarding measurably harder. Every SOP you write for a failure point is a hedge against that cost the next time someone leaves.
2. Size the library to your headcount, not your ambition
A common mistake is trying to build an enterprise-grade wiki at 8 people. It won't get used and it won't get maintained. As a rough benchmark: a 25-person agency runs well on 20–40 core SOPs covering the recurring, high-volume workflows in each function (delivery, sales, ops, finance). By 100 people you're realistically looking at 80–150. Past 200, especially in regulated work, it's common to see 300+.
If you're a 10–15 person shop with 60 "SOPs," most of them are either duplicates or nobody's read them since they were written. Fewer, sharper documents beat a library that looks impressive in a demo.
| Agency size | Realistic SOP count | Focus |
|---|---|---|
| 5–15 people | 10–20 | Delivery, client review, onboarding |
| 15–40 people | 20–40 | + sales handoff, QA, offboarding |
| 40–100 people | 40–80 | + compliance, vendor management, escalation paths |
| 100+ people | 80–150+ | Full functional coverage, regulated processes |
3. Write them as checklists, not essays
The biggest reason SOPs die is that they're written like documentation instead of instructions. Nobody re-reads a 1,500-word Google Doc mid-task. They want: step, step, step, done. If a step has a decision in it ("if the client hasn't responded in 48 hours, escalate to the account lead"), write the branch explicitly — don't bury it in a paragraph.
A useful test: could someone who joined this week follow this SOP without asking you a single clarifying question? If not, it's not finished.
4. Pick a tool that matches how the SOP gets used, not how it gets written
This is where most agencies overthink it. The tool question isn't "which is the best wiki" — it's "does documentation here actually get followed, or just filed."
| Tool | Best for | Trade-off |
|---|---|---|
| Notion | Flexible knowledge base, fast to set up | No built-in accountability for whether SOPs are followed |
| Confluence | Engineering-heavy teams already on Jira | Clunky for non-technical ops staff |
| Trainual | Structured onboarding, training sequences | Weak on visual process capture, no AI-assisted drafting |
| Process Street | Recurring operational checklists with due dates and assignments | Less useful as a general knowledge base |
| Waybook | AI-assisted SOP creation plus visual capture in one place | Newer platform, smaller ecosystem |
If your problem is "documentation exists but nobody follows it," you need something closer to Process Street or Trainual, which turn an SOP into an assigned, trackable task. If your problem is "nothing is written down at all," Notion or a plain shared doc is enough to start — the tool matters far less than momentum in month one.
5. Give every SOP an owner, not just an author
Documentation drifts fast. Operations change, and if nobody's job is to update the SOP when the process changes, the doc and the reality diverge within weeks — which is worse than having no SOP, because now people are following instructions that are quietly wrong.
Assign an owner to each SOP — usually whoever runs that process day to day — and put a review date on it. "Reviewed quarterly" is enough for most agency processes; anything client-facing or compliance-related should be reviewed every time you have a near-miss.
6. Use new hires to stress-test the library
Your newest hire is the best QA tool you have for SOPs. If they hit a wall following a documented process, that's not a training problem — it's a documentation gap. Build a habit of asking every new hire, in their first thirty days, which SOP confused them or was missing entirely. Feed that straight back into the library. It's a far better signal than asking a five-year veteran, who's long since filled in the gaps mentally without noticing.
7. Connect the SOP library to how work actually gets delivered
An SOP library that lives separately from delivery work becomes a museum — accurate, occasionally visited, irrelevant to the daily grind. The agencies that get real value tie their SOPs directly into the tools where delivery happens: the client review checklist becomes the actual review step in the project, not a separate document referencing it.
This is part of why we built Scopeyard around milestones and structured client sign-offs rather than a generic task list — the "SOP" for how a milestone gets approved is the workflow itself, not a doc someone has to remember to open. If you're running delivery for AI automation projects or product builds, the review and approval process is exactly the kind of SOP that should live inside delivery, not next to it.
Final thoughts
Most agencies don't lack process. They lack a written version of the process that survives someone leaving. Start with the three moments that have already cost you money, write them as checklists a first-week hire could follow, assign an owner, and stop treating the library as a project with an end date — it's maintenance, forever, or it's dead in six months.
Sources: Flowster on SOP library sizing, ks-agents on turnover and knowledge loss costs, Waybook 2026 SOP software comparison, Tango on process documentation software.