Most people try to write SOPs with AI the wrong way round. They open ChatGPT, type something like "write an SOP for onboarding a new client" and get back a clean, well-formatted document that's almost entirely useless.
The problem isn't the AI. The problem is that you gave it nothing real to work with.
This guide covers how to write SOPs with AI in a way that actually produces something your team can follow. It's based on how we document processes at AMPL before every automation engagement, because the SOP has to come before the build, not after.
Why Most AI-Generated SOPs Are Useless
There's a version of this that gets written about everywhere: open an AI tool, describe your process in a sentence or two, get a polished document back in 30 seconds. Job done.
The issue is that the output is generic. It describes how that type of process usually works, not how your business actually does it. And those two things are almost always different.
A client we worked with in real estate had a process for managing contracts from accepted offer to close. On paper it looked like a standard checklist. In practice, there were six points in that workflow where the coordinator was making judgement calls based on the specific agent, the lender, and the type of transaction. None of that was written down anywhere. An AI generating an SOP from a vague prompt would never know to include it.
That's the core problem. AI is good at structure and language. It's not good at knowing what actually happens in your business, where the exceptions live, or what the person doing the job does when something goes sideways.
So the question isn't whether AI can write standard operating procedures. It can. The question is whether what it produces is useful, or just looks useful.
What Makes a Good SOP (Before You Involve AI at All)
Before touching any AI tool, it's worth being clear on what you're actually trying to produce. A lot of what gets called an SOP is really just a process description, and they're not the same thing.
The Four Elements Every Operational SOP Needs
A working SOP, one someone can follow without asking three follow-up questions, needs four things:
Trigger: What starts this process? A form submission, an email, a client reaching a specific stage? Without this, people don't know when to use it.
Steps in order: The actual sequence, including the steps that seem obvious to the person doing it but aren't obvious to anyone else.
Exception handling: What happens when something doesn't go to plan. This is the part AI almost always gets wrong.
Output and handoff: What does done look like, and who does it go to next?
If your SOP is missing any of those four, it'll produce questions rather than clarity.
The Difference Between a Process Description and an SOP
A process description tells you what happens. An SOP tells you what to do and when.
"The coordinator checks the contract and sends it to the lender" is a process description. "When the executed contract is received: open the file in the CRM, verify all fields against the checklist, then email the lender using the standard template within two hours of receipt" is an SOP.
The second one is longer. It's also the one that actually gets followed consistently. AI is useful for turning the first version into the second, but only if you give it enough specifics to work with.
Step 1 - Record the Process Before You Prompt
This is the step most people skip, and it's why their AI-generated SOPs don't work.
You need raw material before AI can do anything useful. The raw material is what actually happens, not what you think happens, not what should happen, but what the person doing the job does every time they sit down to do it.
Interview the Person Who Actually Does It
The best input for an SOP is a conversation with the person who does the process day to day. Not a manager describing it. The person doing it.
Ask them to walk you through it as if you've never seen it before. Ask specifically: what do you check before you start? What do you do if a specific exception comes up? What does done look like? Is there anything you do that isn't written down anywhere?
That last question usually gets the most useful answers.
Record the conversation. You'll use the transcript as your AI input, not a summary, the actual transcript. The messiness of how someone explains a process in conversation is more useful than a polished description, because it includes the details they'd never think to write down.
Screen Recording and Transcript as Input
If the process involves a computer, and most do, a screen recording while they do it is even better than an interview alone. Ask them to talk through what they're doing as they do it. Record both the screen and the audio.
Tools like Loom will do this. Run the audio through a transcription tool like Whisper or Otter. Now you have a timestamped record of every action and every decision point.
That transcript is your prompt input. It's specific, it's real, and it includes the things the person didn't know were worth mentioning because they do them automatically.
Step 2 - Structure Your Prompt for SOP Output
Once you have real input, you can write a prompt that produces something useful. The prompt structure matters as much as the input.
The Prompt Template AMPL Uses
This isn't a one-line prompt. It's a structured brief that tells the AI exactly what format and content you need. Here's the template:
You are documenting a business process as a standard operating procedure. Here is a transcript of [name], who does this process daily, explaining how it works: [paste transcript]. Using this transcript, write an SOP with the following structure: 1) Process name. 2) Trigger, what starts this process. 3) Who is responsible. 4) Tools and systems used. 5) Steps, numbered, in sequence, as specific as possible. For each step, note the system used and the expected output. 6) Exception handling, what to do when exceptions mentioned in the transcript occur. 7) Definition of done, what does completion look like and what happens next. 8) Review date. Use plain language. Write each step so someone new to this role could follow it without asking questions. If the transcript is ambiguous on a step, write it out and flag it with NEEDS VERIFICATION rather than guessing.
That last instruction matters a lot. You want the AI to flag gaps, not paper over them with plausible-sounding generic text.
What to Include, What to Leave Out
Include the full transcript as context, not a summary. The more specific the input, the more specific the output.
Leave out anything aspirational, meaning how you want the process to work or what you're planning to change. Write the current-state SOP first. You can document the future state separately once the current state is captured accurately.
Also leave out any request for the AI to improve the process. That's a separate job. The SOP should reflect what actually happens, not what someone thinks is best practice. Mixing the two produces a document that reflects neither accurately.
Step 3 - Review, Test, and Close the Gaps
The AI output is a first draft, not a finished document. The review step is where the real work happens.
The Most Common Gaps AI Misses
From documenting processes across a range of businesses, the same gaps come up consistently:
The informal check: The person doing the job has a mental check they run before a step that never made it into the transcript. Something like: I always look at the account status first before I do anything else, said 20 minutes into the conversation, not at the start.
The workaround: A system doesn't work as intended, so the team has developed a workaround. The AI documents the system as designed, not as actually used.
The escalation path: Who do they call when something breaks? Nine times out of ten this is someone specific, not a generic "contact your manager" instruction.
Tool-specific steps: "Click the export button" sounds simple until you realise there are four export buttons and only one produces the right format.
Go through the AI draft with the person who does the process. Ask them to read it as if they're seeing it for the first time. Watch where they slow down. That's usually where the gap is.
How to Run a Walk-Through Test
Once you've done one review pass, run a walk-through with someone who doesn't do this process, ideally someone who would need to follow it if the usual person was away.
Ask them to follow the SOP exactly as written, step by step, without being helped. Note every point where they pause, ask a question, or make a different choice than the SOP describes. Those are your remaining gaps.
This sounds like a lot of effort. For a process that runs every day, it's worth 30 minutes. You'll find the gaps now rather than at the worst possible time.
Step 4 - Version Control and Keeping SOPs Current
An SOP that was accurate six months ago is often inaccurate now. Systems change, team members develop better approaches, tools get updated.
Build in a review cadence from the start. For high-frequency processes, quarterly is reasonable. For less frequent ones, twice a year.
A few practical things that help:
Date every version clearly. "Current as of [date]" at the top of the document.
Name who's responsible for the review. Without a name it won't happen.
Store SOPs somewhere the team can access them easily, not in someone's personal Google Drive. A shared wiki or Notion works well.
When a process changes, update the SOP the same day. Not "when we get a chance".
If you're building towards automation, version control becomes even more important. The SOP is the spec the automation is built from. If the SOP changes and the automation doesn't, you end up with a system doing what you used to do, not what you do now.
Real Example: Documenting a Transaction Coordination Workflow
When we worked with Empower, a real estate business, the transaction coordination process was one of the first things we documented, because it was the process we were going to automate.
The coordinator walked us through it over a 45-minute call. We recorded the whole thing. What came out wasn't a clean list of steps. It was a conversation that included six points where she was making judgement calls based on the specific agent, the lender's preferences, and whether it was a cash or financed transaction.
None of that was written down anywhere. When we ran the transcript through our SOP prompt, the AI flagged several of those points as needing verification because the transcript was ambiguous. That was exactly right. Those were the bits we needed to sit back down and clarify before we could document them properly.
The final SOP was 14 steps. The version we'd have got from prompting without the transcript would probably have been six generic steps that missed everything specific to how Empower actually operates.
The automation we built on top of that SOP handled roughly 70% of the workflow without human input. The remaining 30%, the judgement calls, stayed with the coordinator. But the SOP now made those explicit rather than invisible, which meant we could build the system to hand off to a human at exactly the right point rather than guessing.
That's the difference between documenting what AI thinks the process looks like and documenting what the process actually is.
FAQ
Can AI write standard operating procedures on its own?
AI can produce a well-structured SOP document, but it needs real input to produce a useful one. Without a transcript or detailed description of how the process actually runs in your business, AI will generate a generic template that describes how that type of process usually works, not how yours does. Use AI for the drafting, not the discovery.
What's the best AI tool for creating SOPs?
The tool matters less than the input. Claude, ChatGPT, and similar models can all produce solid SOP drafts given a good transcript and a structured prompt. The template in this post works across all of them. If you're documenting processes at scale, a consistent prompt structure is more valuable than any specific tool choice.
How long should an SOP be?
Long enough to remove ambiguity, short enough that someone will actually read it. For most operational processes that's somewhere between one and three pages. If an SOP runs to ten pages, it's usually covering multiple processes that should be documented separately. Break it up by trigger: one trigger, one SOP.
Should I document processes before or after automating them?
Before. Always before. The SOP is the spec the automation is built from. If you automate first and document later, you're building on assumptions about how the process works that may not be accurate. At AMPL, the SOP comes before every build. It's how we make sure the system we build reflects what the business actually needs.
How do I stop SOPs going out of date?
Two things: assign a named owner to each SOP, not a team, a specific person, and set a review date when you publish it. Quarterly works for most high-frequency processes. When the process changes, update the document the same day. Outdated SOPs are often worse than no SOP because they create false confidence in something that no longer reflects reality.
What's the difference between an SOP and a process map?
A process map shows the flow, who does what and in what order, often as a diagram. An SOP tells someone how to do each step. Both are useful, but for delegation and automation purposes the SOP is what you need. Use the process map to identify bottlenecks and handoffs. Use the SOP as what the person or system doing the work actually follows.
If you're thinking seriously about documentation, whether for delegation, automation, or getting knowledge out of people's heads, the audit we run at the start of every engagement covers exactly this. You'll know which processes to document first, which ones are ready to automate, and what the realistic return looks like. Book a free audit at amplconsulting.ai.
