SOP Playbook
Builder
How to turn something you know how to do into instructions someone else can follow. Four passes. Each one catches what the others miss.
Why "Write Down
What You Do" Fails
You know how to do something well. Maybe you've been doing it for months or years. Now someone else needs to do it... a coworker, a new hire, an AI tool. You need to write instructions good enough that they can execute without you standing over their shoulder.
That's harder than it sounds. Two structural problems get in the way.
Problem 01: You leave stuff out without realizing it. When you write instructions for something you know well, you skip things. Not on purpose. Your brain doesn't flag them because they've become automatic. You write "make the sauce" when what you actually do involves checking the consistency, adjusting the heat three times and tasting it at a specific point. The gap between what you write and what you actually do is where instructions fall apart.
Problem 02: You can't see your own autopilot. Some of what you do happens so fast and so automatically that you don't register it as a step. You glance at something before starting. You make a split-second call about which approach to take. You sense when something is "off" before you can explain why. You can't document what you can't observe yourself doing.
This playbook gives you a system for catching both problems. You'll run through your process four times, each time looking for different signals. By the end, you'll have instructions that actually transfer.
Five Setup
Questions
These answers become the header of your SOP. Don't skip them. They keep the entire document focused.
The Four
Passes
You run through your process four times. Each pass catches signals the others miss.
The goal: Get your process on paper the way you'd explain it to someone competent who's never done this specific task.
Write out every step from start to finish. For each step, include:
- What you do (the action)
- Why you're doing it (the purpose)
- What the result looks like (the output)
The most important discipline here: break it down smaller than feels necessary. If you think your process has 3 steps, it probably has 8-12. A reliable test: if any single step takes more than 5 minutes to execute, it contains hidden sub-steps. Pull them apart.
Don't stress about completeness. This first pass is supposed to have gaps. The next three passes exist to surface them.
The goal: For each step, describe what a bad version looks like instead of what a good version looks like.
Why this works: It's structurally easier to explain what's wrong than what's right. You might struggle to describe what makes a good email, but you can spot a bad one immediately. Use that instinct.
Go through each step from Pass 01 and answer:
- What does a bad version of this step's output look like? Give 2-3 specific examples.
- What's the most common mistake someone new makes here?
- What would make you redo this step?
- Is there a subtle failure here that someone might not notice until it causes problems downstream?
Write these as "If you see X, that means Y went wrong" statements.
Example:
Step: "Write the summary email to the client"
Pass 01 instruction: "Summarize what we decided in the meeting in 2-3 short paragraphs"
Pass 02 (what wrong looks like):
"If your email is longer than your phone screen, you included too much. It should be decisions and next steps only, not the full discussion."
"If every sentence starts with 'We discussed,' you're writing meeting minutes, not a summary. Lead with what was decided, not what was said."
"If the client would need to reply asking 'so what do I need to do?' your summary is missing the action items."
The goal: Perform the process in real time while narrating every tiny decision, pause and check you make.
This is the most important pass. It's also the most uncomfortable. You're observing your own thinking, out loud, while executing. (That's supposed to feel weird. It means you're doing it right.)
Pick a capture method:
- Voice memo on your phone (talk while you work, transcribe later)
- Screen recording with narration
- A colleague watching you work and documenting everything they see you do that isn't in your Pass 01 writeup
Then do the process for real. Not from memory. Not hypothetically. Start to finish while saying things like:
- "I'm checking X first because..."
- "I'm pausing here because something looks off. Specifically..."
- "I almost did it this way but changed my mind because..."
- "I'm jumping ahead to check something before I continue because..."
- "I'm going back to fix step 2 now that I can see what step 4 produced..."
Find the Gap: After you finish, compare what you said in Pass 03 against what you wrote in Pass 01. Everything that shows up in Pass 03 but NOT in Pass 01 is the invisible work. The autopilot layer. The stuff your brain does that you never would have documented.
This gap is the most valuable part of your SOP. Things that commonly surface:
- Pre-checks you run before starting (glancing at something to confirm conditions are right)
- Quick quality assessments between steps ("is this good enough to move on?")
- Branching decisions you make without thinking
- Workarounds you've developed that nobody taught you
- Reference materials you consult that aren't mentioned in your instructions
- Backtracking patterns (going back to revise earlier work based on what you discover later)
The goal: Take every "I just know" moment from Pass 03 and force it into a clear if/then rule.
Why this matters: Your instincts aren't magic. They're patterns you've seen so many times your brain processes them instantly. The patterns ARE logical. You've just stopped noticing the logic. This pass makes that logic visible so someone else can follow it.
For each autopilot item from Pass 03's gap, ask:
- What am I actually looking at when I make this call? (The signal)
- What are the possible states of that signal? (The conditions)
- What do I do differently depending on what I see? (The branches)
- What happens if I get this wrong? (The stakes)
Write each one as:
WHEN [situation] IF [this is true] → DO [this] IF [that is true instead] → DO [that] OTHERWISE → DO [default thing] STAKES: [what goes wrong if you call this incorrectly]
Example:
WHEN a customer sounds frustrated on the call
IF they mention a specific past issue → ACKNOWLEDGE it by name before solving the new one
IF they're frustrated but it's their first contact → SKIP the history, go straight to solving
OTHERWISE → ASK one clarifying question before jumping to solutions
STAKES: If you skip acknowledgment on a repeat caller, they escalate. Every time.
Not every judgment call will break down into clean rules. That's fine. For the ones that resist, use a Gap Tag (next section) and move on. Honest incompleteness is more useful than false precision.
Gap Tags
You will have places where your instructions are incomplete. That's not failure. That's the most honest thing in the document. Mark those places so the person following your SOP knows where the exposure is.
These tags are the most honest parts of your SOP. An SOP with zero tags is almost certainly lying about its completeness.
Structuring
the Output
Once you've completed all four passes, you have raw material. Organize it into the capture template. Each step includes fields for:
- Step Name ... Start with a verb. "Send the confirmation" not "Confirmation sending."
- Instructions ... Your Pass 01 writing, cleaned up for the target executor.
- What Goes Wrong ... Your Pass 02 failure patterns. 2-4 specific failure modes per step.
- Autopilot Notes ... Your Pass 03 gap items. The work you do without conscious awareness.
- If/Then Rules ... Your Pass 04 decision structures.
- Success Check ... Flip your failure patterns. "This step is done right when [none of the bad things happened] AND [these positive conditions are true]."
- Example (Good + Bad) ... One correct output. One incorrect output. The contrast teaches more than either alone.
- Output Format ... A sample, template or sketch of what the finished step looks like structurally.
- Gap Tags ... Any [SIMPLIFIED], [CAN'T EXPLAIN YET], [IT DEPENDS] or [HUMAN CALL] flags with notes.
- Tools and Setup ... Software, links, login info, environment requirements. The operational wiring.
Testing
Instructions you haven't tested are a hypothesis. Not a procedure.
Give your SOP to someone who has never done this process. Watch them attempt it without helping. Every place they get stuck, ask a question or go wrong is a gap in your documentation. Fix the SOP. Don't coach the person.
If someone else also does this process, show them your SOP. Ask: "What's missing? What would you do differently?" Their disagreements are either errors to fix or legitimate variations to document.
Remember the three strangest or most unusual times you've run this process. Walk through your SOP with each one in mind. If your instructions don't handle them, either add a branch or add an [IT DEPENDS] tag with a note.
If this SOP will be executed by AI, convert each step into a prompt and run it. The AI's mistakes are diagnostic. They tell you exactly where your instructions are ambiguous or assume knowledge that isn't written down.