Ninsei LabsTo write an SOP before automating, sit down with the person who actually runs the process (not who manages it), walk it in real time while documenting every decision branch and the reason behind each one, and don't finalize the document until it runs three consecutive times without intervention. That's the whole method. Knowing how to write an SOP this way is the difference between an automation that holds and one that fails on its fourth live run. Everything below is why each part matters and how to execute it in roughly two hours.
The phrase "never automate a broken process" has been repeated so many times it's become furniture. Nobody argues with it. And yet I watch teams reach the automation-build phase with zero documentation of what they're actually automating. The assumption is that someone will write the SOP afterward, or that the process is obvious enough that documenting it is busy-work. Neither is true. The SOP isn't a formality you file after the automation ships. It's the input that tells you whether you should build at all.
Why "Never Automate a Broken Process" Is Incomplete Advice
The line is right. The problem is it offers no mechanics.
What it actually means: a process that depends on tribal knowledge, that produces different outputs depending on who runs it, or that routinely requires undocumented judgment calls, is not automatable. You can build a workflow around it. The workflow will fail in edge cases, produce wrong outputs silently, or require constant supervision. You'll spend more time managing the automation than you saved.
What the line doesn't tell you: how to figure out if your process is broken before you build. How to capture what the process actually is, not the sanitized version the manager describes. How to know when the documentation is good enough to hand off.
Those are the mechanics nobody writes down.
Start With the Person Who Does the Work, Not Who Oversees It
This is the most important rule of SOP capture. Schedule the session with the person whose hands are on the keyboard, not their manager, not the department head.
Managers describe processes as they're supposed to work. Operators describe processes as they do work. The gap between those two descriptions is where automation fails.
I've run this exercise on billing workflows, client onboarding sequences, weekly report pipelines. In every case, the operator version had at least two steps the manager's version omitted: a cross-check against a second spreadsheet, a Slack message sent to flag an edge case, a judgment call made every third Friday because of a quirk in the source data. None of that surfaces in a top-down description.
Schedule 90 minutes. Tell the operator you're going to watch them run the process live, or ask them to narrate it step by step while you document. Do not let them describe it from memory at a whiteboard. Memory produces the idealized version.
How to Write an SOP That Captures the Real Process, Not the Clean One
Ask the operator to start the process as if you weren't in the room. Your job is to document every action and every decision point.
For each decision point, ask one question: "Why?"
Not "Why do you do it that way?" (slightly confrontational, produces defensive answers). Just "Why?" Flat, neutral, curious. Then write down the answer verbatim.
This is where the process reveals itself. "Why do you check that field first?" leads to "Because if that field is empty, the rest of the form is garbage." That's a validation rule you'd have to reverse-engineer from live automation failures. Now you have it upfront.
Document in plain language. No process diagrams, no swimlanes, no color-coded flow charts. A numbered list of steps is fine. Each step needs: what triggers it, what action happens, what the output is, and what the decision criteria are if it branches.
If the operator can't explain why a step exists, write that down too. "Operator does X; reason unknown." Unknown reasons are a signal, not a gap to paper over.
The Three-Run Rule: Don't Finalize Until It Runs Clean
Don't clean up the SOP after one capture session.
Run the process three more times using the draft documentation as the only guide. The operator follows the documented steps while you watch. Every time they deviate from the doc, even slightly, stop and update the doc.
Three consecutive clean runs is the bar. Clean means the operator completed the process exactly as written, without opening a different tab to check something, without asking a question the doc didn't answer, without making a judgment call that wasn't captured.
This takes maybe two hours spread across a week. The alternative is an automation that works in your test environment and fails on the fourth live run because the edge case from step seven showed up and nothing handled it.
If you can't get three clean runs, the process isn't documented well enough to automate. That's information. It means either the documentation is incomplete or the process itself isn't stable enough to hand off to a machine. Either way, you've avoided building the wrong thing.
Automation Readiness Signals: What to Look For Before You Build
Once you have a three-run-clean SOP, evaluate automation fit. Not every documented process should be automated.
Automate when:
The trigger is predictable. A form submission, a scheduled time, an inbound email matching a pattern. Not "whenever someone feels like it."
Decision branches have discrete, checkable criteria. "If field A is empty, do X" is automatable. "If the situation feels off, do Y" is not.
The process runs at least ten times a month. Below that, the build and maintenance overhead often exceeds the time saved.
Data inputs are structured. If the first step involves a human interpreting an unstructured input (a PDF, a handwritten note, a vague Slack message), that's an AI-assist job with a human checkpoint, not a straight automation.
Fix first, then automate:
The process requires judgment calls nobody can define. Get the criteria documented before you build.
Outputs vary depending on who runs it. That's a training and standardization problem. Solve it at the human level first.
The error rate is high even with a careful human doing it. An automation running at the same error rate, at ten times the volume, produces ten times the damage.
What a Finished SOP Needs Before You Hand It to a Builder
The document doesn't need to be long. A ten-step process fits on one page. What it needs to include:
- Trigger: what starts this process
- Prerequisites: what must be true or ready before step one
- Each step: action, tool used, output
- Decision points: the criteria, not just the options
- Known edge cases: what they are and how to handle them
- Owner: who handles it when something falls outside the documented path
When I translate a documented process into an automation build (whether that's an n8n workflow, a Make scenario, or an agent with tool access), this document is what the build is written from. Ambiguity in the SOP becomes ambiguity in the automation, and automation ambiguity is silent failures at 3am.
The SOP is also how you evaluate the automation after it ships. Does the live system follow the documented process? If the automation deviates and produces a good output, update the SOP. If it deviates and produces a bad output, you have a clear reference point for the bug.
Automating a well-documented process is fast and the results are predictable. Automating a process you think you understand is months of debugging something that almost works. Write the SOP first. The two hours you spend capturing it will save ten on the back end, and they'll tell you whether the automation is worth building at all.