Your agency runs on tribal knowledge. Here's the AI system that turns it into SOPs your team actually follows.
by Ayush Gupta's AI
The problem
Agency founders become the procedure manual because they never had time to write one. When the how lives in one person's head, every task routes back to them — and delegation becomes impossible regardless of how good the team is.
The fix
Use AI to extract your real operating procedures from how you actually work — Loom recordings, Slack threads, delivery docs — and build a living SOP library your team can follow without pinging you.
The Playbook
Find the three most repeated founder bottlenecks
Before writing a single SOP, check your Slack DMs and inbox for the last 30 days. Count which questions come back more than once. 'How should I respond when the client wants a revision after approval?' 'What goes in the weekly update?' 'When do I escalate vs. handle it myself?' These are not random questions. They are undocumented procedures. Start there — not with the things you feel like documenting.
Record yourself doing it once, narrated, then extract with Claude
The fastest way to write an SOP is to do the task once on a Loom, narrate your reasoning as you go, then feed the transcript to Claude. This captures how you actually work — not the idealized version you would write if you had a free afternoon. Get the Loom transcript, paste it into Claude, and run the extraction prompt below.
You are an expert operations writer for a digital agency.
I'm going to give you a transcript of me walking through [TASK NAME].
Extract this into a clean, usable SOP with:
1. When to use this procedure (the specific trigger)
2. What you need before you start
3. Step-by-step instructions (specific enough that a new team member can follow without asking questions)
4. The three most common mistakes and how to avoid them
5. What good looks like when this is done right
6. When to escalate to the founder instead of proceeding
Be concrete. No generic advice. If I said something unclear, flag it rather than guessing.
Transcript:
[PASTE LOOM TRANSCRIPT]Stress-test the draft for edge cases and decision rules
The transcript captures the happy path. Real SOPs need to cover what happens when things go sideways — the awkward client, the missed deadline, the ambiguous brief, the conflicting stakeholder. Run a second prompt to surface the failure modes and decision rules. That second pass is what makes the SOP usable in real conditions rather than just clean ones.
Here is a draft SOP for [TASK NAME]:
[PASTE DRAFT SOP]
Stress-test it. I will answer each of these questions and you will update the SOP accordingly:
1. What are the three to five most common ways this task goes wrong in practice?
2. What does the team member do when they are uncertain about a decision?
3. What triggers an escalation to the founder versus handling it independently?
4. Are there client types, project types, or situations where this SOP does NOT apply?
Ask me the questions one at a time. After I answer all four, revise the SOP to include decision rules for each.Format it for mid-task use, not a manual shelf
A 2,000-word Google Doc is not an SOP your team will open when they need it. They will Slack you instead. Format every SOP the same way: a one-sentence use case at the top, five to eight numbered steps max, a short decision tree for the most common variations, and a 'what done looks like' at the end. If it takes more than three minutes to scan, it will not get used.
Release it, watch what still comes back, iterate
Ship the SOP to the team. Do not wait until it is perfect. Watch your Slack DMs for the next two weeks and note which questions about that task still come back. Those are gaps in the SOP. Fix them. Then write the next three. You are building a living document, not filing a manual nobody will open.
What changes
The founder stops being the procedure manual. Team members escalate less and act more. New hires ramp faster. Consistent output quality regardless of who runs the task. Delegation becomes possible because the team has the context they need to move without constant check-ins.
The agency founder is the procedure manual.
That is the problem.
Not the team. Not the clients. Not the tools.
When there is no documented process, everything routes back to the person who knows how we do it. That person is almost always the founder.
So the founder answers the same questions.
Makes the same judgment calls.
Gives the same guidance.
Every week.
Not because the team is incapable. Because they have no documented procedure to fall back on.
Why agencies never write SOPs
It is not laziness. It is timing.
When the agency is small, everyone fits in one Slack channel. The founder touches everything. There is no gap between what the founder knows and what the team does — because the team is one or two people, and the founder is right there.
Then the agency grows. New people join. The founder cannot touch everything anymore. But there is still no bridge between what the founder knows and what the team does.
That is the moment agencies should write SOPs. It is also the moment nobody has time to.
So the SOPs never get written. The team works off informal guidance, old examples, and a standing instruction: "ask me if you're unsure."
That is not a system. That is a dependency.
The traditional approach fails for a specific reason
The conventional advice is to block a Friday afternoon and write your SOPs.
Nobody does this. Because the founder who most needs to write SOPs is the founder who most cannot afford to spend a Friday afternoon away from client work.
The result is a permanent intention: I will write the SOPs when things slow down.
Things do not slow down. The SOPs do not get written. The dependency persists.
AI changes the direction of effort required.
Instead of carving out time to document something you already know how to do, you do the work once — narrated, on a Loom — and the AI extracts the procedure from how you actually did it.
No blank page. No staring at a Google Doc wondering how much detail to include. No three hours building something your team reads once and ignores.
You run the task. You narrate your reasoning. Claude drafts the SOP. You stress-test it. You ship it.
That is the whole loop. The first SOP takes two hours including setup. Each subsequent one takes forty-five minutes.
Finding the right three to start with
The mistake is starting with the procedures you feel like documenting.
Start with the procedures that are actively costing you time right now.
Go to your Slack DMs. Open your inbox. Look at the last thirty days. Find the questions your team asked more than once:
- How do I handle a revision request after the client approved something?
- What goes in the weekly status update?
- When do I tell the client something is delayed versus figure it out first?
- How detailed should the brief be for a freelancer?
Each of those is an undocumented procedure. Each one is routing to you instead of being handled independently.
Write those three down. That is your SOP backlog for week one.
Recording yourself doing it
Set up a Loom. Open whatever you use to do the task. Do the task exactly as you normally would.
The only addition: narrate your thinking out loud.
Not a polished explanation. A working narration. "Okay, so the first thing I do is check whether the revision falls inside scope or outside. If it's inside, I just acknowledge it and queue it. If it's outside, I need to do two things before responding..."
Talk through the edge cases you run into. Explain the judgment calls. Note what you check before you proceed, and why.
When the recording is done, get the Loom transcript. Paste it into Claude with the extraction prompt in this playbook.
What Claude produces is not the final SOP. But it is eighty percent there — structured, sequential, with the logic intact. That is dramatically better than a blank document and a blocked afternoon.
The second pass: stress-testing for real conditions
The recording captures the happy path.
Real work is not the happy path. Real work is the client who comes back two weeks after approving something and says they want to change the direction. It is the brief that is missing three things you need before you can start. It is the ambiguous feedback that could mean two different things.
The second prompt in this playbook surfaces the failure modes. You answer four questions about what goes wrong, when to escalate, and which situations the SOP does not apply to. Claude updates the SOP with decision rules for each.
That second pass is what makes the difference between a document that helps your team and one they ignore after the first edge case catches them off guard.
Formatting for the moment of use
Most agency SOPs fail because they are formatted like manuals.
Long. Dense. Written for completeness rather than quick access.
When a team member hits an uncertain moment in a task, they have two options: open the manual and find the right section, or Slack the founder. Manual search takes time and is uncertain. Slacking the founder is instant and reliable. So they Slack the founder.
The SOP format that actually gets used is:
- One sentence at the top: when this procedure applies
- Five to eight numbered steps maximum
- A short "if X then Y" decision block for the most common variations
- A "what done looks like" section at the end
If the team member cannot scan it in three minutes, it will not get opened in the moment they need it. Format for that constraint.
Building the library incrementally
Do not try to document your entire agency in one sprint.
Write three SOPs. Release them. Watch your Slack DMs for two weeks. Note which questions about those tasks still come back.
Those questions reveal the gaps. Fix the SOPs based on what the team actually gets wrong — not what you predicted they would get wrong. The team's failure modes are more accurate than your intuition about their failure modes.
Then write the next three.
A SOP library built this way compounds. Each procedure you document is one fewer thing routing to you. After six months, the distribution of questions in your inbox looks different — more client-facing, more strategic, fewer "how do we handle this" requests about things your team should be able to handle independently.
What this actually changes
The first shift is visible within two weeks.
The same question stops coming back. The team member runs the SOP, makes the call, and moves. You find out later in a status update rather than a real-time ping.
The deeper shift takes a few months.
Once the team has procedures they trust, they stop waiting for permission to act. They do not second-guess themselves as much. They escalate less because they have a framework for when to escalate and when to proceed.
That is what functional delegation actually looks like.
Not "here are your tasks." Not "let me know if you need me." It is: here is the context you need to operate, and here is the system for the edge cases.
The SOP library is how you give them that context at scale without becoming the context yourself.
Record the first Loom this week. Run the transcript through the extraction prompt. Ship the draft to your team.
See what still comes back.
That feedback is your roadmap for the next one.