How to turn an SOP into an AI workflow

Pull five things out of the SOP: steps, decisions, inputs, tools and owners. Mark each step as deterministic (plain automation), judgment (AI) or approval (a human). Pick one build surface, such as n8n, Zapier, Relevance AI or a Claude skill, ship one workflow end to end, then measure the hours it saves against a baseline.
This guide is one practical piece of AI engineering for GTM operators, the path from writing prompts to running workflows that improve themselves. Here the starting material is a document your team already wrote.
Key points
An SOP is a spec in disguise. It already names the steps, the order and who owns each one.
Most steps in a business process are deterministic and need no AI at all. Reserve the model for steps that need reading, sorting or writing.
Every workflow that writes to a customer or a CRM needs at least one human approval point at first.
The build surface follows the step mix: rules heavy processes suit n8n or Zapier, judgment heavy ones suit Relevance AI or a Claude skill.
Measure hours per run before you build, or you will not be able to prove the workflow saved anything.
Why start from an SOP instead of a blank canvas?
Because the hard part of automation is agreeing on how the process works, and an SOP already records that agreement. Starting from it saves the discovery work and gives you a document to test the workflow against.
The volume of process work is large. Asana's Anatomy of Work Global Index (2023) reports 62% of the workday "lost to repetitive, mundane tasks." That is the work most SOPs describe.
The payoff comes from changing the process, not bolting AI onto it. McKinsey's The state of AI in 2026 says high performers "fundamentally redesign workflows that are enabled by AI rather than insert AI into existing ones," and reports that nearly three-quarters of high performers "report fundamentally redesigning workflows because of their AI use."
So treat the SOP as a draft to rewrite, not a script to copy. Some steps will disappear because they only existed to move data between tools by hand.
What do you extract from the SOP?
Extract five fields for every step: what happens, what decision is made, what goes in, which tool is touched and who owns it. Put them in one table before you open any automation tool.
The extraction sheet:
Field | Question to ask | Example (illustrative) |
|---|---|---|
Step | What action happens, in one verb phrase? | Enrich a new inbound lead |
Decision | Is there a choice here, and what rule or judgment makes it? | Route to sales if company size is 50 or more |
Inputs | What data does this step need, and where does it live? | Form fill, company domain, CRM record |
Tools | Which systems are read or written? | HubSpot, Slack, an enrichment tool |
Owner | Who does it today, and who signs off if it goes wrong? | SDR does it; RevOps lead owns the rule |
Four habits make the sheet useful:
Split compound steps. "Check the lead and assign it" is two steps with two different natures.
Write the hidden rules down. SOPs often say "use your judgment." Ask the owner what they actually check, and record it.
Mark the trigger. Note what starts the process: a form fill, a new row, a calendar date, an email.
Note the output. Every step should leave something behind: a field updated, a message sent, a file created.
Writing these rules down is also the first draft of the context the model will need later. The guide to what context engineering is explains why that written context matters more than prompt wording.
Which steps are automation, AI or human approval?
Sort every step into one of three lanes. Deterministic steps follow a fixed rule and go to plain automation. Judgment steps need reading, classifying or writing and go to a model. Approval steps carry risk and go to a person.
Anthropic's engineering post on building effective agents draws the same line. It defines workflows as "systems where LLMs and tools are orchestrated through predefined code paths," and says "workflows offer predictability and consistency for well-defined tasks." It also recommends "finding the simplest solution possible, and only increasing complexity when needed."
Lane | Signs a step belongs here | Typical examples | Build as |
|---|---|---|---|
Deterministic | Same input always gives the same output; the rule fits in one sentence | Copy a field, create a task, send a templated alert, update a stage | Trigger and action nodes, no model |
Judgment | Needs reading free text, classifying, summarizing or drafting | Score intent from a form note, summarize a call, draft a reply | A model call with written instructions and examples |
Human approval | Touches a customer, money, contract terms or permanent CRM data | Send an email, change a deal amount, delete a record | A pause that waits for approve or deny |
Most automation tools now build the approval lane in. The n8n docs on human in the loop for AI tools say "you can require human approval before an AI Agent executes a specific tool," with approvals through Slack, Gmail, Microsoft Teams and other channels. Zapier's guide to human in the loop describes a "Request approval" step that adds "the checkpoint right into your workflow."
A quick sorting test
Ask three questions of each step, in order:
Could I write this as an if/then rule? If yes, it is deterministic.
If not, would two careful people reach the same answer from the same input? If yes, it is judgment a model can handle with examples.
Would a wrong answer reach a customer or change money or records? If yes, add approval, whatever lane it started in.
Sorting each step into three tiers makes the split visible: judgment stays human, repeatable steps get delegated, and pattern-based steps go to automation.

Which build surface should you pick?
Pick the surface that matches your step mix and the people who will maintain it. Mostly deterministic steps suit n8n or Zapier; mostly judgment steps suit Relevance AI or a Claude skill.
Surface | Best when | Watch for |
|---|---|---|
n8n | Many deterministic steps, branching logic, a technical owner, self-hosting needs | You own hosting and updates if you self-host |
Zapier | Simple trigger and action chains across common SaaS apps, a non-technical owner | Long multi-branch flows get hard to read |
Relevance AI | Judgment steps run by agents with tools, built in a no-code editor | Agents need clear instructions and tool limits |
Claude skill | A repeatable task a person runs with Claude, packaged as instructions plus files | Runs inside Claude, so pair it with a scheduler or automation for unattended runs |
Relevance AI's own docs describe it as "a low/no-code platform where you can build AI agents and multi-agent teams that autonomously complete tasks." Anthropic's Agent Skills overview says each skill "packages instructions, metadata, and optional resources (scripts, templates) that Claude uses automatically when relevant." That makes a Claude skill the closest thing to an SOP Claude can read and follow.
For a side by side on cost, hosting and who can maintain each tool, see Relevance AI vs n8n vs Zapier. If the SOP is a task one person runs on demand, the tutorial on how to create a Claude skill walks through turning it into a SKILL.md file.
In the systems I build, a common pattern mixes surfaces: n8n handles triggers and CRM writes, a model call handles the judgment step, and Slack carries the approval.
How do you ship the first workflow?
Ship one workflow from trigger to output before you build a second. A finished narrow workflow teaches you more than three half built ones.
A build sequence that works for most SOPs:
Pick the SOP with the clearest trigger and highest volume. Volume makes the savings visible quickly; a clear trigger keeps the first build simple.
Baseline it. Time five to ten manual runs and record minutes per run and runs per week.
Build the deterministic lane first. Wire the trigger, the data pulls and the writes, with no model yet. Use test records.
Add the judgment step. Write the instructions from your extraction sheet, include two or three worked examples, and define the exact output format.
Insert the approval point. Route anything that touches customers or records to a person who can approve or deny.
Run it in shadow mode. Let the workflow produce outputs while the team still does the work by hand, and compare the two.
Switch over and keep the log. Once outputs match, let the workflow run, and keep every run logged so you can audit it.
Shadow mode is where most problems surface. The guide on testing an AI workflow before trusting it covers how to turn those comparisons into repeatable evals.
If the SOP lives in Notion, Claude can read it directly once connected. The tutorial on connecting Claude to Notion over MCP shows the setup, so the workflow reads the current version of the document instead of a stale copy.
How do you measure hours saved?
Multiply minutes saved per run by runs per week, then convert to hours and dollars at a loaded hourly rate. Compare against the baseline you timed before building, not against a guess.
The formula: hours saved per week = (manual minutes per run minus remaining human minutes per run) x runs per week / 60.
The remaining human minutes matter. If approval takes two minutes per run, those minutes stay on the books.
An illustrative example
The worked example on the Leak Call page uses round, illustrative numbers:
Input | Value |
|---|---|
Team size | 12 people |
Manual hours per person per week | 8 |
Loaded hourly rate | $60 |
Weeks per year | 52 |
Annual cost of the manual work | 12 x 8 x $60 x 52 = $299,520 |
One workflow that removes half of it | $149,760 a year |
The point is not the size of the number. It is that each workflow gets a dollar value you can check after 30 days, and the next SOP to automate is the one with the biggest gap between cost and effort. The manual work leak audit shows how to find and cost those gaps across a whole team.
This is the operator side of my work: I build these systems for my own work and do the same for SaaS revenue teams (lead routing, CRM cleanup, pipeline reporting) in a 90-day AI RevOps Sprint for Series A and B SaaS. Contact me to get yours scoped.
What are the common mistakes?
The most common mistake is automating the SOP exactly as written. The rest come from skipping the baseline or the approval point.
Copying every step. Steps that existed only to move data by hand should be deleted, not automated.
Sending deterministic work to a model. A field copy does not need AI. A rule is cheaper, faster and never makes things up.
Leaving "use judgment" undefined. If the owner cannot explain the rule, the model cannot follow it either.
No baseline. Without timed manual runs, hours saved is a guess.
No approval point on day one. Customer emails and CRM writes should wait for a person until the workflow has a clean record in shadow mode.
Building three workflows at once. Each one gets stuck at 80% and none of them saves an hour.
Letting the SOP and workflow drift apart. When the process changes, update the document and the workflow together, or point the workflow at the live document.
FAQ
What is the difference between an SOP and an automation?
An SOP describes how people do a process. An automation runs some or all of those steps in software, with people kept on the steps that need judgment or approval.
Do I need AI to automate an SOP?
Often not. Many steps are fixed rules that plain trigger and action tools handle. Add a model only for steps that need reading, classifying or writing.
Which SOP should I automate first?
The one with a clear trigger, high weekly volume and low risk if a run goes wrong. Internal routing and reporting usually beat customer facing steps as a first build.
How long should the first workflow take to build?
That depends on the number of steps and integrations. Keep scope to one SOP, one trigger and one output so the first version ships rather than stalls.
Should the workflow read the SOP directly?
For judgment steps it helps. Pointing a model at the live document, for example through an MCP connection to Notion, keeps its instructions current when the process changes.
How do I know the workflow is working?
Run it in shadow mode, compare its outputs with the manual results, and track hours saved per week against your baseline.
Want help turning your SOPs into workflows?
If you have a folder of process documents and want a second pair of eyes on which one to build first, see how I work or book a short intro call. Bring one SOP and we can sort its steps into the three lanes together.
Running revenue at a Series A or B SaaS company? Ask about the 90-day AI RevOps Sprint. I take two clients at a time.
About the author: Kevin Payne is an AI engineer and GTM operator who installs AI workflows for B2B teams. He has 10+ years in B2B SaaS demand generation and RevOps across Techstars, a16z and YC portfolio companies, and his writing has appeared in HubSpot, GetResponse, Outbrain and more.


