Building Your SOP Library with AI
Get the process out of your best people's heads and onto paper, fast
Why SOPs never get written
Every agency owner knows they should document their processes. Almost none do, for a simple reason: writing an SOP from a blank page is slow, boring, and always loses to whatever client fire is burning that day. The fix isn’t finding more time — it’s changing how the SOP gets written. Instead of writing from scratch, you talk through the process the way you’d explain it to a new hire, and let Claude structure it.
Talk, don’t type
The fastest SOP-creation method is to explain a process out loud (or in a stream-of-consciousness written braindump) exactly as you’d walk a new hire through it, then hand that to Claude to formalize.
I'm going to explain our client offboarding process the way I'd
talk a new hire through it. Turn my explanation into a formal SOP
with numbered steps, a "who's responsible" column, and any tools
or templates referenced. Ask me clarifying questions if a step is
ambiguous - don't guess and fill gaps silently.
Here's how it goes: So when a client is ending their contract,
first thing is someone needs to check if it's a mutual end or if
they're leaving upset, because that changes the tone of everything
after. Then we need to export all their data - analytics access,
any creative files, whatever we built for them - from our systems.
We usually forget to revoke their login access to our project
management tool, that's a gap actually. Then there's an exit
survey we're supposed to send but honestly only send about half
the time...Notice the instruction to ask clarifying questions rather than guess. This is what turns a documentation exercise into a process audit — Claude will surface the “we usually forget to revoke access” gaps that a from-scratch SOP template would never catch, because it’s working from how the process actually happens, not how it’s supposed to happen.
Standardize the format across your whole library
Individual SOPs are only useful if they’re consistent enough that anyone can find what they need fast. Set a fixed template before you write the second one.
| Section | Purpose |
|---|---|
| Purpose | One line: why this process exists |
| Trigger | What event starts this process (e.g. “contract signed,” “client requests offboarding”) |
| Steps | Numbered, each with an owner and any linked template |
| Common mistakes | What goes wrong when this is rushed — captured from real experience, not hypothetical |
| Last updated | Date and who reviewed it — SOPs rot fast if nobody owns upkeep |
Tip: Once you have three or four SOPs written this way, ask Claude to review them together for consistency — same tone, same level of detail, same template. It’s much easier to standardize after a few drafts exist than to get the template perfect before you’ve written anything.
Keep SOPs alive, not archived
An SOP library that nobody updates becomes actively dangerous — a new hire follows a documented process that’s two reorganizations out of date. Build a light review habit: every time a process changes noticeably, feed the updated version back to Claude alongside the old SOP and ask it to reconcile the two and flag exactly what changed.
Key principle: The value of an SOP isn’t the document — it’s that a new hire can execute a process correctly without pulling a senior person away from billable work to explain it verbally for the fifth time this quarter.
Build it: Pick the process you’ve explained verbally to a new hire most often. Record or write yourself explaining it exactly as you would out loud, then run it through the Step 1 prompt above.