Almost every ops team we have talked to has some version of the same situation: well-documented standard operating procedures sitting in Word documents, Notion pages, or Confluence wikis, and a large gap between those documents and any actual automation. The SOPs describe exactly what should happen. The problem is that turning those descriptions into working automations has historically required either technical skills the ops team does not have, or a ticket to IT that takes weeks to get resolved — and when it does, the automation is owned by IT, which means the ops team cannot modify it when the process changes.
This article is about how to close that gap yourself, using your existing SOP documentation as the starting material.
Why SOPs are already 80% of the way there
A well-written SOP contains most of what you need to describe an automation: a trigger condition ("when a customer submits a returns request"), a sequence of steps ("check the order date, verify the product is within the returns window, send the customer a returns label, notify the warehouse"), and the responsible parties and systems ("using our WMS for stock updates, customer email via our support inbox").
The gap between a SOP and an automation description is mostly a matter of specificity at the system level. SOPs are written for people — they assume the reader knows what system to go to and where to find the relevant field. Automation descriptions need those specifics made explicit: not just "notify the warehouse" but "send a Slack message to #warehouse-ops with the order number, the customer name, and the SKU of the returned item."
The practical implication is that converting a SOP to an automation description is mostly a translation exercise, not a technical exercise. You are not learning something new — you are adding precision to something you already know.
How to read a SOP for automation candidates
Not every step in a SOP is automatable, and not every process is worth automating. When you read through your SOPs with automation in mind, you are looking for two things: steps that are purely information-transfer (copy this data from here to there, notify this person when that happens) and steps that are consistently executed the same way every time. These are the highest-value candidates.
Steps that require judgment, interpretation, or relationship context are generally not good automation candidates — at least not fully. "Review the customer's history and decide whether to approve the exception" is a human decision. "Send the customer an email confirming the exception was approved" is an automation. The automation handles the communication; the human handles the judgment call. Most good automations in an ops context are about removing the mechanical steps that surround human judgment, not replacing the judgment itself.
Red flags in a SOP that suggest a step is currently manual but should not be:
- Steps described as "copy X into Y" or "add X to the spreadsheet"
- Steps that say "notify [person/team] about [event]" — notifications are almost always automatable
- Steps that start with "check [system] to see if [condition]" on a regular schedule
- Steps that are identical across multiple SOPs — strong signal that the underlying trigger-action pair is a general pattern worth automating once
Walking through an example: supplier onboarding SOP
Consider a supplier onboarding SOP for a small product business. The document describes the process from "supplier agreement signed" through to "supplier active in systems." A typical flow might look like this:
- Receive signed agreement from supplier via email
- Create supplier record in accounting system
- Add supplier to vendor management spreadsheet with status "Onboarding"
- Send welcome email to supplier with payment terms and contact details
- Notify procurement team via Slack
- Set a calendar reminder to follow up on first invoice in 45 days
Steps 2 through 5 are all automatable. Step 6 is partially automatable (the calendar event can be created automatically; what happens at the reminder requires human follow-up). Step 1 is the trigger.
The automation description you would write from this SOP:
"When an email arrives in [email protected] with 'supplier agreement' in the subject line and a PDF attachment, create a new supplier contact in Xero with the sender's name and email address. Add a row to the Vendor Management sheet with the supplier name in column A, their email in column B, today's date in column C, and 'Onboarding' in the Status column D. Send the supplier a welcome email with our standard payment terms attached. Post a Slack message to #procurement with the new supplier name and a note that onboarding has started. Create a Google Calendar event 45 days from today titled 'Follow up: first invoice from [supplier name]' in the Procurement calendar."
That is the SOP translated into an automation description. The translation took approximately five minutes. The time saving is every instance of this process executed in the future — which, for a product business with regular supplier additions, could be weekly.
The IT ticket trap and how to avoid it
The traditional path from SOP to automation runs through IT. Ops manager writes the SOP, decides the process should be automated, raises a ticket, waits for IT to scope it, waits for development, waits for testing, receives an automation they cannot fully understand or maintain, and eventually stops using it when the process changes and the automation does not.
We are not saying IT-built automations are bad. For complex, high-stakes processes that touch core systems, there is genuine value in having engineering involvement. But the category of automations that ops teams need most — notification flows, data sync between business apps, simple trigger-action workflows across SaaS tools — does not need to go through that process. The tools exist for ops managers to build and own these directly.
The key word is own. An automation that an ops manager built from a description they wrote is an automation they can read, understand, modify when the process changes, and hand off to a colleague by simply pointing them at the description. That ownership changes the relationship between the team and the automation infrastructure in a way that a ticket-generated script never can.
What to tackle first when you have a library of SOPs
If you have a large set of SOPs and want to prioritise which to automate first, the heuristic we recommend is frequency times pain. A process that runs twenty times a week and takes five minutes each time is a better first target than a process that runs once a month and takes two hours — even though the monthly process has higher per-instance cost, the weekly one will show returns faster and give you more practice iterations on a shorter feedback cycle.
Start with one process, not three. Get it running, watch a few executions in the run log, make the adjustments you inevitably need to make, and then move to the next. The second automation always goes faster than the first because you have already done the connection setup and you understand the description format better.
The goal is not to automate everything in your SOP library in one month. The goal is to reach a point where your instinct, when you write a new SOP step, is to ask yourself whether this step is actually necessary for a human to do — and if not, to describe the automation at the same time you write the procedure. That shift in how your team thinks about process documentation is more valuable than any individual automation you will build.
When a SOP is too vague to automate
Sometimes you will sit down to convert a SOP to an automation and realise the SOP itself is not specific enough. The step says "update the customer record" without specifying which fields, which system, or what triggers it. This is not a failure of the automation approach — it is feedback about the SOP. If a step is not specific enough to automate, it is probably not specific enough to train a new hire on reliably either.
Using the automation description exercise as a SOP quality check is a side benefit worth naming explicitly. The precision required to describe an automation is approximately the same precision required to write a procedure that produces consistent outcomes regardless of who is following it. Building those skills simultaneously makes both your documentation and your automation more valuable.