Write the SOP First, Automate It Second

The first AI automation I ever shipped failed because I couldn’t answer one question: “what happens when the invoice has no PO number?”

I had the workflow half-built. Intake form to extraction to CRM, clean on paper. Then a real document hit the edge case, the agent guessed, and a client got billed against the wrong project. The problem was never the model. The problem was that the task had three unwritten rules living in one person’s head, and I’d skipped past all of them because I was busy building.

That’s the lesson I keep relearning: if you can’t write the SOP, the AI can’t run it. Automation doesn’t create clarity. It exposes the lack of it.

The bottleneck is almost never the tool

When an automation breaks, operators reach for a better model or a different platform. Most of the time the real gap is upstream. The task was never actually documented, it was just done, the same way, by the same person, for years.

That’s tribal knowledge. It works fine until you try to hand it to anyone who isn’t that person, and an AI agent is the most literal new hire you will ever onboard. It won’t infer that “Tuesday invoices skip approval” or that you always check the spelling of one specific vendor. It does exactly what’s written. So if nothing is written, it does exactly nothing useful.

The reframe that fixed my hit rate: stop thinking “how do I automate this” and start thinking “how would I hand this to a competent stranger on their first day.” If you can write that document, you have an automatable task. If you can’t, you’ve found the real work, and it’s not technical.

Write the SOP first, in five passes

A usable SOP for automation isn’t a wiki page. It’s a small, ordered set of decisions. Here’s the sequence I run before any build, on any task, regardless of which tool ends up doing the work.

The order matters. People want to start with the rules, but you can’t see the rules until you’ve watched a real run and pinned down what actually comes in the door.

Narrate one real run

Pick a single recent instance of the task and talk through it like you’re training someone over your shoulder. Record it or type as you go. Don’t summarize, don’t clean it up. “Okay, the email comes in, I open the attachment, I check whether it’s the new template or the old one…” The messy version is the accurate version.

Capture the inputs and define done

Write down exactly what the task receives: a PDF, a form, a Slack message, three of those at once. Then write down what a correct finished output looks like, specifically enough that two people would agree on whether a given result passed. “Entered correctly” is not a definition. “Vendor, amount, and project code populated, with the project code matched against the active list” is.

List every rule, including the rare ones

This is where tribal knowledge lives. Every “except when,” every “but if it’s this client,” every judgment call you make without noticing. The rare rules are the ones that bite you in production, so chase them down now while you’re thinking clearly, not at 11 PM when the agent has done something dumb.

What the SOP changes about the build

Here’s the part that surprises people. Once the SOP is honest, the build gets boring, and boring is exactly what you want.

The SOP isn’t a document you write and file. It becomes the prompt, the test cases, and the escalation rules, all three. The inputs section tells you what the agent has to handle. The rules become explicit instructions. The “done” definition becomes how you check the output. And the exceptions become the moments where the agent hands control back to a person instead of guessing.

That last one is the difference between an automation you trust and one you babysit. A literal new hire who knows when to ask for help is useful on day one. One who guesses confidently is a liability.

The honest limitation

This method has a cost, and I won’t pretend otherwise. Writing the SOP is slower and less fun than wiring up a tool. It feels like overhead, especially when the demo version worked in ten minutes.

It’s also where the failure point actually is. The ten-minute demo breaks on the eleventh input. The SOP-first build holds because you did the thinking before the stakes were real instead of after. I’ve never regretted the hour spent narrating a task. I’ve repeatedly regretted skipping it.

There’s one case where this is overkill: a genuinely simple, deterministic task with no judgment calls. If the task has no “it depends,” you barely need an SOP. But those tasks are rarer than they look, and the ones that feel simple are usually the ones hiding three unwritten rules.

Do this with one task this week

Pick the task you most want to hand off and run it through the SOP pass before you touch a single tool. The document you produce is the thing that determines whether the automation works, no matter what you build it with.

If you get to step five and can’t finish it, that’s not a failure. That’s the method working. You found the real bottleneck before it cost you a client, and now you know what to fix first.