How to Write Standard Operating Procedures People and AI Can Follow.

Most guides to standard operating procedures start with a template. The template is the easy part. The hard part is that the knowledge a standard operating procedure (SOP) needs usually lives in a few people's heads, and the person asked to write it down is often not one of them.

The result describes the work as a manager imagines it, not as it is done, and people quietly go back to asking the colleague who knows.

That colleague is a bigger dependency than most companies realize. In Deloitte's 2026 survey of 22,595 Gen Z and millennial workers in 44 countries, only 54% of Gen Zs and 60% of millennials said their team could maintain performance if a key expert left tomorrow.

This guide covers the usual steps, plus two that most guides leave out: the decision rules that let people handle cases the steps did not foresee, and the habit of fixing the procedure every time something goes wrong. Both matter more now that AI assistants are reading your procedures too.

What a standard operating procedure is, and what it is not.

A standard operating procedure is a written description of how a recurring piece of work gets done, detailed enough that a trained person who has never done it can produce the same result. It sets out who does what, in what order, and what to do when things do not go to plan.

It belongs to a family of documents that are easy to confuse:

The difference between an SOP and a work instruction is mostly altitude. The SOP covers the whole process and the decisions inside it; a work instruction covers one task within it. Write the SOP first, and hang the work instructions off it.

What an SOP should include.

Whatever the format, a usable SOP has the same parts:

• A header block: title, ID, owner, version, effective date and next review date.
• Purpose and end state: why the procedure exists, and what done looks like.
• Scope: where it starts and stops, and what it deliberately leaves out.
• Roles: who does each part, by role rather than by name.
• Trigger and inputs: what starts it, and what must be in hand before step one.
• The steps.
• Decision rules and exceptions: what to decide alone, when to check with someone, and when to stop.
• Records: what gets logged, and where.
• Revision history: what changed, when and why.

Most procedures fit on one or two pages. If yours runs much longer, it is probably two procedures.

How to write standard operating procedures in 8 steps.

This is the order I would follow for any process, from closing the books to onboarding a client. At Z.Advisors a build runs in four stages, capture, design, build and hand over, and these eight steps sit inside them.

How to write standard operating procedures: the eight-step cycle

01

Pick the process

Frequent, risky, or held in one person's head

02

Capture the work

From the people who do it, judgment calls included

03

Write the purpose and end state

Why it exists and what done looks like

04

Choose a format

Checklist, steps, hierarchy or flowchart

05

Write one action per step

A verb first, conditions people can check

06

Add the decision rules

Decide alone, check with someone, or stop

07

Test it on a newcomer

It passes when nobody has to ask a question

08

Publish it with an owner

Reopened after every significant error

When something goes wrong, ask which step failed, go back to step 02 and fix the procedure.

01Pick the processes worth writing down

Not every task needs an SOP, and a library of procedures nobody uses is worse than none, because it teaches people to ignore the library. Ask three questions of each candidate:

• Does it happen often, or pass between several people?
• Does a mistake cost money, safety, customers or compliance?
• Does it live in one or two people's heads?

Two yeses earn an SOP. The third question is the one most companies miss. A process only one person can run is a risk whether or not anything is written down, which is the same reason succession plans need emergency cover for every critical role. Start with those processes.

02Capture the work from the people who do it

Write an SOP from memory, or from a manager's description, and you get the work as it is supposed to happen. The real version has shortcuts, workarounds and checks that nobody mentions, because they are obvious to the person doing them.

So capture it at the source. Watch the work at least once, or record a walkthrough with the person narrating as they go. Then ask about the moments of judgment, because that is the knowledge that walks out the door:

• What makes you stop and check before carrying on?
• What do you look at before you send it?
• What did the last new person get wrong?
• When do you break the usual order, and why?

Those answers are worth more than the click-by-click. Steps can be reconstructed from a screen recording. Judgment cannot.

03Write the purpose and the end state first

Before any steps, write two sentences: why this procedure exists, and what done looks like. "Customers who qualify get their money back within two working days, and every refund is traceable to an approved reason" tells the reader more than ten steps do.

Add the scope while you are there: where the procedure starts, where it stops, and what it does not cover.

In Rewired Leadership I borrow this from General Stanley McChrystal's idea of commander's intent. When people know the purpose and the desired end state, they can act sensibly in situations the plan did not foresee.

Every procedure eventually meets a case its steps do not cover. The purpose and the end state are what the reader falls back on.

04Choose a format that fits the work

Choose the simplest format that still holds the decisions. Many good SOPs mix two: numbered steps for the main path, and a small flowchart for the one point where it branches.

05Write one action per step

The steps are where most procedures lose their readers. A few rules keep them usable:

• Start each step with a verb. "Check the order date," not "The order date should be checked."
• One action per step. A step with "and" in the middle is usually two steps.
• Use must, should and may on purpose. Must is a requirement, should is the expected path, may is a genuine option.
• Replace vague words with conditions. "As needed" and "periodically" mean something different to every reader. "If the amount is over $250" means one thing.
• Put a warning before the step it applies to, never after it.

How detailed should an SOP be? Detailed enough for the least experienced person who will use it, and no more. Here is the difference in a single step:

06Add the decision rules and the stop points

This is the step most procedures skip, and the one that decides whether they work beyond the easy cases. Steps tell people what to do when everything goes to plan. Decision rules tell them what to do when it does not.

In the book I call these guardrails, and they answer three questions:

• What risks are acceptable without escalation?
• What decisions require consultation but not approval?
• What outcomes matter more than process?

Write the answers into the procedure as plain rules. For refunds: an agent may approve up to $250 alone; above that, they check with a team lead but do not need sign-off; and suspected fraud stops the procedure and goes to the fraud team, whatever the amount.

The third question is a reminder that the end state from step 3 outranks the step order. If following the steps would leave a qualifying customer without their money, the end state wins.

Rules like these are also how you decide which calls stay with a person once an AI assistant takes on part of the work.

07Test it with someone who has never done the task

A procedure is finished when someone new can use it, not when its author is happy with it. Run two tests:

• The newcomer test. Give it to someone who has never done the task and watch them follow it without help. Every question they ask is a line to rewrite, not a reader to coach.
• The expert test. Ask the person who does the work best to read it for anything missing or wrong. They will spot the check they do without thinking.

If an AI assistant will use the procedure, add a third: give the assistant only the SOP and a realistic case, and compare its answer with your expert's. Where they differ, the procedure left something to guess.

It passes when the newcomer finishes without a question and the expert finds nothing missing.

08Publish it with an owner, and update it when something goes wrong

Store the SOP where the work happens: inside the tool people already use, linked from the task, not three folders deep in a shared drive. The person who does the work drafts it; one named owner, usually the person who leads that work, approves it and keeps it current. Set a review date six to twelve months out.

Then add the trigger most procedures lack: every significant error reopens the SOP. When something goes wrong, the first question is which step failed, not who failed.

A fear-based culture blames people. An adaptive culture blames the process.

In the book I call this a systemic autopsy, and the measure that goes with it is worth tracking across any set of procedures: the share of significant errors that end in a documented change to a process, rather than a personnel action.

When that share is high, people report problems early, because the organization has learned to treat a mistake as a design problem rather than a personal failing. When it is low, mistakes get hidden and the procedure drifts further from the work.

A worked example: a refund SOP.

Here is a short SOP written with the eight steps. It is illustrative, not drawn from a real company, and the amounts are placeholders.

The steps:

1. Open the order record and confirm it belongs to the customer asking.
2. Check the account for fraud flags. If there are any, stop and apply the decision rules.
3. Check the order date. If the order is more than 30 days old, offer store credit under the refund policy.
4. Check the amount against the limit in the decision rules.
5. Issue the refund to the original payment method and copy the refund ID into the ticket.
6. Tell the customer the amount and when to expect it, then close the ticket with a reason code.

The decision rules in the refund SOP

01

Is fraud suspected?

If yesstop and hand the case to the fraud team

02

Is the order more than 30 days old?

If yesoffer store credit under the policy

03

Is the refund over $250?

If yescheck with a team lead, then issue it

Otherwiseissue the refund to the original payment method

How to write SOPs that AI assistants and agents can follow.

More procedures now have two kinds of reader: the people doing the work, and the AI assistants and agents helping them. Writing for the second changes less than you might expect, but it removes any room for vagueness.

Using AI to write standard operating procedures

AI is good at the slow part of writing a procedure: turning a recorded walkthrough or a pile of notes into a clean first draft. Used carelessly, it produces a confident, tidy procedure that is wrong in exactly the places that matter, because it cannot know which shortcuts are safe.

The safe order is to capture the work from people first (step 2), give the AI the recording or transcript, and ask it to draft in your SOP structure and to flag every gap or contradiction rather than smooth it over.

Then the expert checks every step and every rule. AI drafts; people verify, and a named person owns the result.

Writing an SOP for AI agents

A person who meets a gap in a procedure fills it from experience, or asks someone. An AI agent fills it by guessing, quickly and with confidence. So a procedure an agent will follow needs everything a person would infer written down:

• The trigger and inputs: what starts the task, and what it may read.
• Limits: what it may do, up to what amount or level of risk.
• Stop points: the conditions under which it must stop and hand the case to a person, and to whom.
• Checkable conditions: "if the amount is over $250," never "if the amount seems high."
• One source of truth: a single current version with clear headings, so the assistant never finds last year's copy.

None of this is new. It is the decision rules from step 6, written for a reader with no common sense to fall back on. A procedure clear enough for an agent is almost always clearer for a new hire too, which is why procedures and knowledge bases written for people and AI assistants alike are one piece of work, not two.

Why SOPs don't get followed.

Most procedures that fail were never wrong on paper. They simply stopped being used, and the know-how went back to traveling by word of mouth.

Drug manufacturing, where written procedures are the law, shows how far that goes. In the FDA's inspection data for fiscal 2025, the finding cited most often at drug makers, 243 times on 713 inspection reports, was quality procedures not in writing or not fully followed.

What FDA investigators cited most often at drug makers, fiscal 2025

Quality procedures not in writing or not fully followed 243

Discrepancies and batch failures not thoroughly reviewed 164

No adequate written production procedures 162

Laboratory controls not scientifically sound 121

Ask why a procedure stops being used and the same causes come up:

• It was written by someone who does not do the work, so it describes a process nobody recognizes.
• It is too long to use at the point of work, so people read it once and then go from memory.
• It is stored where nobody looks.
• It is out of date, so people learn not to trust it, and then not to open it.
• It was launched with an email. One announcement does not change a habit.

The last cause has the clearest fix. Short refreshers, team leads who coach from the procedure, and spot checks against it do more for effective standard operating procedures than a better template ever will.

Frequently asked questions.

The short version.

A standard operating procedure is only as good as the knowledge it captured and the last time someone fixed it.

Capture the work from the people who do it, write down the purpose and the decision rules as well as the steps, test it on someone new, and change it every time something goes wrong. Do that, and the procedure keeps working after the person who knew it best has moved on.