How do you turn an SOP into an automation?
Lees dit in het NederlandsYou turn an SOP into an automation by rewriting it as explicit steps, each one carrying its inputs, its outputs and its decision points, then automating only the steps a rule can decide, keeping a person at the steps that need judgment, and giving the whole thing logs that fail loudly when something does not run. The rewrite is the hard part. A procedure that is vague on paper cannot be automated, because software will not fill in the parts you left to whoever happened to be doing the job.
That order is the part people skip. The conversions I have watched go wrong started with a tool and worked backward toward the procedure, so the software encoded a version of the job nobody does. Start with the document. You can run everything below on a notepad before paying for anything. If you have not picked the procedure yet, work out which tasks to automate first and come back with one. If you reach the end of the rewrite and want the built version, or an honest read on which parts belong in human hands, that is where the automation work I do begins.
Rewrite the procedure as steps, not as prose
The SOPs I get handed are paragraphs written by somebody who already knows the job, which is why they read fine and automate badly. Rewrite yours as a list where every step names three things: what arrives, what leaves, and where each of those lives.
Step: send the quote
In: the intake form the customer filled in (form tool)
Out: a quote document (client folder), an email (shared inbox)
Decides: nothing. The line items come from the form answers.If you cannot fill in all three lines for a step, you have found a piece of the job that lives in somebody's head. That is a documentation problem rather than an automation one, and it is the exact place the automation would have failed. I ran kitchens for years before I built software, and the test was the same there: a prep list and a station system were good when service ran without me standing in it.
Mark every decision as a rule or a judgment
Walk the list, find every point where somebody decides something, and label each one.
| A step in your procedure | Rule or judgment | How you can tell |
|---|---|---|
| Copy the address off the form onto the label | Rule | No decision at all, just a hop between two places. |
| Pick the shipping method for this order | Rule | It fits in one sentence with an if in it. |
| File the invoice under the right customer and month | Rule | The destination follows from fields you already have. |
| Decide whether this reply sounds right for this client | Judgment | It rests on tone and history that are not in the record. |
| Decide whether a complaint gets a refund or a redo | Judgment | Two people who know the customer could reasonably disagree. |
Be honest here. The temptation is to call something a rule because you want it automated. My test: could you hand the decision to somebody on their first day with only the written condition in front of them, and never check their answer? If not, it is judgment, and judgment is not a failure. It is the part worth keeping a person on.
Find the trigger
Every procedure starts because something happened. An email arrives, an order is paid, a form comes in, a date comes around. Name the trigger, then name how a machine would know it happened, which is the harder half.
On the coaching platform I built for Doomscrollers, the member record is created and the welcome email fires only on the confirmed payment event, so a member exists because money cleared, not because somebody saw a payment and remembered to act on it. The other trigger there is the member's own check-in, which is what the next plan gets written from.
Automate the rule steps first, one hop at a time
Do not build the procedure. Build its first rule step, run it for real, then add the next. A chain of small hops that each work is a system you can debug. A whole procedure built in one go is a system you can only restart.
The shape you are heading for, on any procedure with judgment in it, is draft, review, send. The system prepares, a person approves, the system delivers. On that same platform, writing the plan is the job only the coach can do, so everything around it gets her to that screen faster, with the member's own check-in sitting in a column beside the editor. The desk can generate a draft for her to react to, and marking the plan sent is its own step.
Make it fail loudly
The expensive failure is not the automation that breaks. It is the one that stops and says nothing while you believe it ran. Two things prevent that: a log a person actually reads, and an alert when a step did not run.
Treat a clean number with suspicion. A counter sitting at zero only means zero if you can point at the thing that would have written a one into it. Otherwise the honest reading is "not measured". Everything leaving that coaching platform goes out through a single send point and lands in a log with its delivery state, and the member's own page flags mail that failed to reach them, or a plan published but never sent.
The Answer Report is my own product and the fully automated end of the same idea: auditing, publishing and delivery run as scheduled jobs on their own server, with a watchdog that raises an alarm the moment serving looks wrong. Nobody stands next to it, which is exactly why the alarm exists.
Run it beside the manual way before you trust it
Keep doing the procedure by hand while the automation does it too, and compare the outputs every round. The disagreements are the specification you did not write. When they stop, switch over. Do not call it early because the first run looked right: the first run is the easy case, and the cases that break a procedure are the ones a person handles without noticing.
Write down how it runs and how to change it
An automation nobody can explain becomes a thing nobody dares touch, and then it sets the rules of the business instead of following them. Keep one short page beside it: what starts it, what each step does, where the log lives, who gets the alert, and how to change the parts that will change.
Then put those parts where a person can find them. On the coaching platform, the prices, tiers, cadence, capacity and terms live in a single business file, so changing what a membership includes is one edit the pages, forms, emails and structured data all follow.
What an SOP needs before an agent can follow it
That deserves a guide of its own, so here is the short version. An agent needs precise wording, because "check the order" is not an instruction while "compare the shipping address to the address on the payment, and flag it when they differ" is. It needs an example of a finished output, so done is something it can match rather than infer. It needs the exceptions written next to the step they interrupt, because every real procedure has "unless" cases living in a head. And it needs an escalation rule: what happens when the case does not fit, who it goes to, and what gets handed over. Without one an agent guesses, and a guess inside a procedure is worse than a stop.
Work through this with one procedure and the document often ends up more useful than the automation. That is normal, and it is the point: the rewrite is where the thinking happens, and the software is what makes it hold. Bring me the list, plus the steps you could not confidently label, and building it starts there.
Sources
Frequently asked questions
Do I need a written SOP before I can automate anything?
You need the procedure written as steps, which is not the same thing as owning a formal SOP document. A business can run a procedure well for years without writing it down, and the first real task is getting it out of somebody's head and onto a list with inputs, outputs and decision points. If your written version reads as a paragraph of prose, rewrite it as steps before you look at any tool.
Which steps of a procedure should stay with a person?
The ones where the answer rests on things that are not in the record, like tone, the history with this customer, or what you know about how the week is going. A useful test is whether you would let somebody on their first day decide it from the written rule alone and never check their answer. If the answer is no, keep a person there and let the system prepare the work for them instead of replacing them.
Which tools do I need to turn an SOP into an automation?
The tool choice comes last and it matters far less than the rewrite. Once a procedure is written as steps with inputs, outputs and labeled decisions, a lot of those steps turn out to be moving a known thing from one place to another, which nearly any automation tool can do. Pick one that connects to the systems you already pay for rather than one that asks you to replace them.
How do I know the automation is actually working?
Only by reading something it wrote. Give every run a log entry a person can read and an alert that fires when a step did not run, then actually read the log for the first rounds instead of assuming. A counter at zero, with nothing proven to be writing to it, means the thing is not measured rather than that nothing happened.
What should happen when the automation hits a case it was not built for?
It stops and hands the case to a named person, along with whatever it already gathered. Write that escalation into the procedure before you build it, including what the customer sees while the case waits. An automation that guesses at an unfamiliar case does more damage than one that halts and says so.