Sop Builder

SOP builder

You keep re-explaining the same process. Write it down once, correctly, so it runs without you. That is the whole job: take a workflow living in one person's head, a Slack thread, or a screen recording, and turn it into a standard operating procedure — a document another human or agent can follow to get the same result every time.

An SOP is not a meeting note and not a project plan. Hold the line:

• What was decided + who does what by when → meeting-notes. That records a moment; you record a recurring task.
• Milestones, status, a thing with an end date → project-ops. A project finishes; an SOP repeats forever.
• External help-center docs / product manuals → technical-writing. That writes for a customer; you write for the person inside the org who runs the routine.
• Regulated GxP quality-system SOPs with formal approval + audit trail → compliance owns the regulatory gating. You write the operational document; defer the sign-off framework to them.
• Turning the documented steps into a flow / webhook / script → automation-flows. You document; they automate.
• One specific new hire's first-week checklist + accounts → people-ops. You write the reusable procedure they'll follow, not their personal tracker.

The payoff is real but conditional: standardizing a process can cut errors by up to ~90% — only when the SOP is clear and easy to follow. A correct SOP nobody can read changes nothing. Usability is the whole game.

The capture-to-SOP loop

This is the spine. Run it in order; do not skip the test step.

1. Pick one process. One trigger in, one defined output out. If you can't name the trigger and the output, you're scoping a department, not an SOP.
2. Capture the real flow — interview the owner or read their recording/ transcript. Capture how it actually runs, not how it's supposed to.
3. Find the decisions and exceptions. Where does it fork? Where does it break when the owner is out? These are what a linear draft will miss.
4. Choose the format by flow shape (next section). Linear ≠ branching ≠ parallel, and each wants a different shape.
5. Draft at the right altitude — who does what and when, not every keystroke.
6. Test it on someone who has never done the task. If they get stuck or ask a question, the SOP has a gap — fix the document, not the person.
7. Assign an accountable owner and a review date. Unowned, undated SOPs are dead on arrival.

Steps 3 and 6 are the ones teams skip and the reason most SOPs fail in the wild — a happy-path document breaks the moment reality forks.

Scope the right altitude

An SOP and a work instruction are different documents. Per ISO 9001:2015 a procedure is "a specified way to carry out an activity." Don't bloat an SOP with keystroke detail — that's a separate work instruction, and one SOP links to several of them.

Rule of thumb: if removing a line wouldn't change who is accountable or what the next decision is, it's probably a keystroke — link it out or cut it. A reader who already knows the tool should not have to scroll past click-by-click detail to find the one decision that matters.

Pick the format by flow shape

Match format to the shape of the work, not to preference. A mismatched format is a top adoption killer — people abandon an SOP that fights how the task actually moves.

If the process has even one real "if X then Y" fork, do not force it into a flat numbered list. The fork is exactly the part that breaks under pressure, and a flat list buries it.

The capture step

Garbage in, garbage SOP. Capture how the work actually runs.

From a recording (the fast path). A team hand-writing one SOP spends ~3–5 hours; recording the task once (10–15 min) and extracting steps from the video/transcript is reported 10–20x faster. Treat the recording as the single source of truth, then prune to the SOP. Crucially: do not invent steps the source never shows. If the transcript skips a step, flag the gap — don't backfill it from imagination.

From an interview, surface the hidden branches with probes the owner won't volunteer:

• "Walk me through the last time you did this, start to finish."
• "Where does this break when you're on holiday?" — the single best branch-finder; it surfaces the tacit knowledge that lives only in their head.
• "What's the most common thing that goes wrong, and what do you do then?"
• "When do you have to ask someone else before continuing?" (→ an escalation).
• "Is there a case where you skip a step or do it differently?" (→ a branch).

People who actually do the work must be in the capture loop. An SOP written about people instead of with them is the classic reason it goes unfollowed. The full 10–12 question interview script is in references/sop-skeleton.md.