SOPs that execute themselves

Your onboarding SOP is 14 pages. It’s accurate, it’s well written, and nobody has opened it since March. New runs happen from memory, which means they happen the way the most recent person remembers them — and the real test of an SOP isn’t whether it’s written. It’s whether run #47 happens exactly like run #1 when the person who wrote it is on vacation.

This article is the method we use to take a process off the page and turn it into something that runs: a checklist wired to your tools, where software does steps 1–7 and a human approves step 8. One worked example — client onboarding — with the before/after table and the cost.

Why documented processes drift

• ▸PDFs have no state. Nothing in a document knows that step 5 happened, so nothing can notice that step 6 didn’t.
• ▸PDFs have no telemetry. You can’t ask a document how long step 6 usually takes, which step gets skipped, or where runs stall. You find out at the client complaint.
• ▸Changes don’t propagate. You update the doc; the veterans keep doing it the old way from memory, because memory is what they actually run on.
• ▸The tribal-knowledge tax. Half of what makes the process work lives in one operator’s head — and teams already spend about 1.8 hours a day hunting for information that exists somewhere. When that operator leaves, the process leaves with them.

The conversion: document → classified steps → workflow

The method is mechanical, which is the point. Take the SOP, split it into atomic steps — one actor, one action, one output each — and classify every step into one of three classes:

Decompose almost any back-office SOP this way and the split lands in the same place — typical for this type of process: 70–80% deterministic, 15–20% assisted, and a small number of true judgment calls. The judgment calls are why the process needs a person. The other 80% is why that person is exhausted.

The human-approves-step-8 pattern

Every executable SOP we build follows one design rule: software does steps 1–7, a human approves step 8. “Step 8” is whichever step is irreversible or client-facing — the send, the charge, the go-live. Everything before it is preparation a machine does perfectly and never forgets; everything after it is bookkeeping a machine does instantly. The human’s job compresses to the one decision that actually needed a human — made with the full context laid out in front of them, instead of assembled by hand over three days.

An SOP is a program you’re currently running on people. We port it.

Worked example: client onboarding

A 12-step onboarding SOP for a professional-services firm — the composite we use because nearly every service business runs some version of it. Before: a 14-page PDF, 4–5 hours of admin per new client spread across a week, and steps skipped often enough that “did anyone invoice the deposit?” is a real Slack message. After: a DocuSign signature starts the machine.

Admin time per onboarding: about 4.5 hours before, about 25 minutes after — the approval plus whatever edits the brief needs. Typical for this type of automation. The bigger win is variance: run #40 is identical to run #4, on the client’s first week, which is exactly when your firm is being judged hardest.

Under the hood each step is a small declaration — class, tool, inputs, and what gates it. Steps 6 and 8 from the build above:

- step: 6
  name: internal-brief
  class: assisted
  tool: claude
  inputs: [proposal.pdf, contract.pdf]
  output: brief.md            # account lead edits before the gate

- step: 8
  name: approval-gate
  class: judgment
  waits_for: [5, 6, 7]        # invoice, brief, welcome email all ready
  approver: account-lead
  channel: slack
  timeout: 24h → escalate(owner)

Zero drift

When the process changes, you change the workflow once — and every run after that follows the new version. There is no “the veterans do it the old way,” because the old way no longer exists as an option. And since every run is logged, the SOP finally has telemetry: where runs stall, which drafts get heavily edited, how long onboarding actually takes versus how long everyone assumed. n8n workflows export as JSON, so the process lives in version control like the software it now is — you can diff this quarter’s onboarding against last quarter’s and see exactly what changed, and when.

Ramp time, the quiet payoff

A new hire on a PDF SOP reads 14 pages, then interrupts a veteran 20 times in week one anyway. A new hire on an executable SOP works the checklist: the system creates the folder, drafts the brief, and presents them the one decision that’s theirs. New-hire ramp roughly halves when onboarding SOPs run as guided flows instead of tribal knowledge — typical for this type of deployment, and it compounds with every process you convert.

Which SOP to convert first

Rank every documented process by two numbers: runs per month, and minutes of admin per run. Multiply. The top of that list is your first build — usually onboarding, invoicing, or scheduling, because they run weekly and touch 4+ tools. Skip anything that runs quarterly; the payback math rarely clears, and quarterly processes are where a written checklist and a calendar reminder honestly do fine.

What it costs

• ▸One SOP family (like the onboarding above): $2,000–6,000 fixed, from our published workflow band — the spread is how many tools the steps touch. The 12-step example, with 6 integrations, quotes near $4,000, in writing, before we start.
• ▸Running cost: the self-hosted n8n VPS at ~$20/mo plus a few dollars of Claude drafting. Every other tool in the table is one you already pay for.
• ▸The math, labeled typical: 6 onboardings/mo × 4 hours saved × $45/hr loaded ≈ $1,080/mo — a $4,000 build pays back inside 4 months. The skipped-step incidents that no longer happen are worth more than the hours, and appear on no invoice.

One honest boundary: not every process should be converted. An SOP that changes shape every month isn’t ready — automating it just means re-building it monthly. We mark those human-only in the roadmap and say why.