Sop Builder Agent Skill

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.

• 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.

• Capture the real flow — interview the owner *or* read their recording/

transcript. Capture how it actually runs, not how it's supposed to.

• 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.

• Choose the format by flow shape (next section). Linear ≠ branching ≠

parallel, and each wants a different shape.

• Draft at the right altitude — who does what and when, not every keystroke.
• 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.

• 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.

| Altitude | Answers | Example line | Belongs in |

| --- | --- | --- | --- |

| SOP | *who* does *what* and *when* (the roadmap) | "The editor approves the draft before it's scheduled." | The SOP body |

| Work instruction | *how* one operator does one task (the GPS) | "Click Settings → Schedule → pick 09:00, hit Confirm." | A linked WI, not inline |

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.

| Flow shape | Use | Why |

| --- | --- | --- |

| Strictly linear, every time the same | Numbered step-by-step | The order *is* the procedure; numbers carry it. |

| Many parallel pieces, done by experienced people | Checklist | They know *how*; they need to not forget a piece, not be walked through it. |

| Has decision points / forks / "it depends" | Flowchart or decision table | A numbered list hides branches inside prose and readers miss them. |

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.

The SOP skeleton

Four sections are load-bearing and appear in essentially every credible

template: purpose, scope, responsibilities, procedure. Everything else is

supporting structure. Mark sections mandatory vs optional-by-size:

| Section | Status | Note |

| --- | --- | --- |

| Title + ID/version | Mandatory | One process, one document. |

| Purpose | Mandatory | Why this exists, in one sentence. |

| Scope | Mandatory | What's in, what's out, when it triggers. |

| Owner (the "A" in RACI) | Mandatory | Exactly one accountable person. |

| Trigger | Mandatory | The event that starts the procedure. |

| Steps | Mandatory | The numbered/checklist/branched body. |

| Decision points | If it branches | The forks, written explicitly. |

| Quality check | Mandatory | How you know the output is correct. |

| Output | Mandatory | The defined thing produced. |

| Exceptions / escalation | If it can fail | What to do when it goes wrong. |

| RACI matrix | If >1 role | Only when the process spans roles. |

| Change log | Mandatory | Version, date, author, one-line what-changed. |

| Next-review date | Mandatory | See "Keep it alive". |

A RACI clarifies ownership when more than one role touches the process:

Responsible does it, Accountable owns the outcome (exactly one), Consulted gives

input, Informed is kept in the loop. A solo task does not need a matrix —

don't add ceremony the process doesn't carry. The full copy-paste template with

per-field guidance lives in

references/sop-skeleton.md.

Write it so it's actually used

SOPs go unfollowed because of the document, not the people: lack of clarity,

cognitive overload from length and jargon, and staleness. Under pressure people

default to memory over a wall of text. So write short, active, and concrete.

• One action per step. Two verbs in a step means a reader can do half and

think they're done.

• Active voice, named actor. Who does it must be unambiguous.
• No internal jargon the next hire won't know — or define it once.

Bad → Good:

Bad:  The newsletter should be reviewed and then it gets scheduled, making
      sure that everything is fine before it goes out.
Good: 1. Editor reviews the draft against the checklist in §4.
      2. Editor schedules the approved draft for 09:00 Tuesday.
      3. Editor confirms the send shows in the queue.

The bad version hides three actions, names no actor, and uses passive voice that

lets everyone assume someone else did the check.

Branches and exceptions — the section people skip

Branching logic, exceptions/escalations, and the change log are the three

sections SOPs most often omit, and the reason they fail in production. Write the

fork explicitly; don't bury it in prose.

Step 4 — Check the invoice total.
  - If total ≤ €1,000 → approve and proceed to Step 5.
  - If total > €1,000 → route to Finance lead for sign-off, then Step 5.
  - If the PO number is missing → STOP. Escalate to <owner>; do not approve.

Every exception needs a named escalation target and a clear stop condition. "If

unsure, ask someone" is not an escalation — name the role and the trigger. You

don't need a sprawling flowchart for three forks; inline if X then Y lines are

enough until the branch count makes a decision table or flowchart clearer (see

"Pick the format").

Keep it alive

An SOP without an owner and a review date is already dead. Every SOP carries:

• One accountable owner — the person who answers for the outcome.
• A change log — version, date, author, one line on what changed. Without

it, nobody trusts which version is current.

• A next-review date. Reviews are annual minimum *plus* trigger-based: after

a process or tool change, after an incident, or after an audit.

Treat an SOP unreviewed for 18+ months as unreliable — it likely describes a

process that no longer exists. When the review fires, re-run the capture loop on

the diff, not the whole document.

For regulated quality systems (GxP, formal approval workflows, audit-trail

sign-off), write the operational content here and hand the approval/gating

framework to compliance. Once the SOP is stable and

you want the steps executed automatically, hand it to

automation-flows.

Anti-patterns

| Anti-pattern | Why it fails | Do instead |

| --- | --- | --- |

| Keystroke-level SOP ("click Settings, then…") | Bloats the doc; rots the day the UI changes | Keep SOP at who/what/when; link work instructions |

| Flat numbered list for a branching process | Hides the forks that break under pressure | Use a decision table / flowchart for branches |

| Happy-path only, no exceptions | Breaks the first time reality forks | Write if X then Y + a named escalation |

| No owner, no review date | Goes stale silently, nobody trusts it | Name one accountable owner + a next-review date |

| Written *about* the doer, not *with* them | Misses tacit steps; gets ignored | Interview/record the person who runs it |

| Inventing steps the recording never showed | Ships a procedure that doesn't match reality | Flag gaps; capture the missing step, don't guess |

| Wall of passive-voice prose | Cognitive overload; people fall back to memory | One action per step, active voice, named actor |

| RACI on a solo task | Ceremony the process doesn't carry | Add a matrix only when >1 role touches it |

Reference

Pull the full fill-in template, the 10–12 question capture interview script, the

format-selection decision table, and a complete worked Bad→Good example SOP from

references/sop-skeleton.md. Keep this body lean;

reach for the template when you're actually drafting.