An operations lead inherits a process — vendor onboarding, customer escalations, monthly close — and discovers the "SOP" is a Google Doc last touched two years ago by someone who has since left. The steps are numbered but half start with "check with the team" and none say which team. Asking a model to "write an SOP for vendor onboarding" produces corporate-sounding fluff with the same under-specification in glossier prose. SOPs fail in predictable ways, and the prompt has to prevent those failures on purpose.
This post sits in the operations track of our prompt engineering for business teams guide and pairs with AI process automation prompts, AI vendor evaluation prompts, and AI incident postmortem prompts.
Why "Write an SOP for X" Fails
The generic ask produces four predictable failures. The first is vague steps. "Review the request," "coordinate with stakeholders," "ensure compliance" — verbs that describe a shape of activity instead of an action someone can take on a Tuesday afternoon. A vague step is one the reader has to re-derive.
The second is missing exceptions. Real processes branch: the vendor's W-9 has a different name than their invoice, the approver is on PTO, the form is missing a field. An SOP that describes only the happy path is a description of what the process looks like when nothing needs an SOP.
The third is unclear owners. "Someone from finance" reviews the invoice. "The team" approves the contract. Steps with no named owner devolve into the person who notices the step being undone doing it themselves.
The fourth is no verification. "Send the welcome email" does not say how the sender knows the email was received. When the step silently fails, the process silently fails with it. These four failures are the spec the prompt has to meet.
Process Decomposition
The model will not write numbered steps if the prompt does not require numbered steps. It is the single change that separates SOPs that work from SOPs that read like marketing copy for a process.
A decomposition prompt asks for atomic actions — one verb per step, one actor per step, one output per step. "Gather vendor information" is not a step; it is a phase. "Request the vendor fill out the onboarding form at [link] and return the completed PDF" is a step, because it has an actor, an action, an artifact, and an output.
Rules to put in the prompt: each step starts with an imperative verb; each step names the actor explicitly; each step produces one named artifact or state change; steps with more than one action get split. The model will resist this and collapse related actions back together. The acceptance criteria has to name it — "if a step contains 'and' between two verbs, split it."
Step Ordering and Prerequisites
Decomposed steps in the wrong order are still a broken SOP. The pattern is a prerequisite per step — one clause naming what must be true before the step begins. For vendor onboarding, the prerequisite for "create the vendor record in NetSuite" is "tax forms received and reviewed." The prerequisite for "send the welcome email" is "vendor record exists and primary contact confirmed."
Prerequisites surface hidden dependencies and turn the SOP into a runnable checklist — if one fails, the reader stops instead of pushing through and creating a downstream mess. The weight comes from requiring they be concrete, not "all prior work complete."
Exception Handling
Processes are mostly the happy path, but the value in an SOP sits in the unhappy paths. The team that has done the process fifty times knows what goes wrong, and the SOP is where that knowledge gets preserved. A prompt that does not ask for exceptions will not produce them.
The pattern is a "what if X fails" branch at each step that can fail. Any step involving an external actor, a form, a deadline, or a decision almost always can. A good branch names the condition, the detection mechanism, and the next action: "If the vendor does not return the W-9 within 5 business days, the onboarding owner sends a reminder. If no response within 10 business days, the request moves to hold and the requester is notified."
| Exception dimension | Prompt requirement | What it prevents |
|---|---|---|
| Condition | Name the specific failure (form missing, deadline passed, approver unavailable). | Vague "if something goes wrong" branches. |
| Detection | Name how the owner notices (system alert, time-based check, explicit follow-up). | Exceptions that only surface when they cascade. |
| Next action | Name the step, not a category of response. | "Escalate appropriately" with no escalation path. |
| Timeline | State when the exception handling triggers. | Exception paths that linger for weeks. |
Owner Assignment
Every step needs an owner — by role, not by person, so the SOP survives personnel changes — and every exception branch needs an owner too, often a different role than the happy-path owner.
The pattern: list the roles as input, require one role per step, and require a separate owner for each exception branch. When the model cannot determine the owner, require it to flag the step instead of inventing a plausible assignment. That last rule matters more than it looks. Left unconstrained, models assign ownership based on which role sounds right — producing SOPs that look complete and are wrong in ways reviewers miss because the assignment is plausible.
Verification Criteria
A step without a verification criterion will silently fail. Two months later the customer calls asking why they never got their welcome email, and the audit turns up three more cases.
Verification criteria belong per step, and they need to name something observable. "Email sent" is not observable; "email sent to person X at address Y, logged in system Z" is. "Contract approved" is not observable; "contract record shows status = approved and approver name recorded" is. The prompt asks each step to end with "the step is complete when [observable state]." It is the difference between an SOP that can be audited and one that cannot.
Feeding Existing Process Docs
Most SOPs start from something — an old doc, a Loom transcript, a slack thread where the team debugged the process last quarter, a scratchpad of the current owner's notes. The raw material is rarely usable as-is, but it contains most of what a finished SOP needs. Extraction is something AI does well, if the prompt knows what to extract and what to ignore.
A messy-notes-to-SOP prompt takes the notes as input, the SOP scaffold as structure, and extraction rules as behavior. Useful rules: pull steps from the notes without inventing new ones; surface ambiguity as open questions rather than plausible inventions; leave exception branches empty and flagged when the notes do not describe them; and preserve the author's judgment calls as notes-to-the-reader rather than collapsing them into the main flow.
The output is a draft, not a finished SOP. The value is the transformation from "we have 40 pages of scattered notes" to "we have a draft with the gaps flagged." The gap-flagging is often the most useful part — it tells the author what they still need to decide.
Example: SOP Prompt (Hypothetical)
A prompt for a vendor onboarding SOP. The example is hypothetical — roles, tools, and timelines are illustrative.
ROLE:
You are an operations lead drafting a Standard Operating Procedure.
You produce atomic, owned, verifiable steps with explicit exception
handling. You flag gaps rather than inventing plausible details.
CONTEXT:
Process: new vendor onboarding, from intake request to first PO.
Roles involved:
- Requester (internal team member requesting the vendor)
- Onboarding owner (ops team, runs the process)
- Finance reviewer (reviews tax docs and payment terms)
- Legal reviewer (reviews contract for non-standard terms)
Systems: NetSuite (vendor records), DocuSign (contracts),
Google Drive (document storage).
Known exceptions: vendor misses deadlines; legal flags contract
language; finance rejects W-9 due to entity mismatch; requester
cancels mid-onboarding.
TASK:
Draft the SOP. For every step, include:
- A numbered, atomic action (one verb, one actor, one artifact).
- The role responsible (from the list above).
- The prerequisite (what must be true before this step begins).
- The verification criterion (observable state indicating the
step is complete).
For every step where the listed exceptions could occur, add a
branch:
- Condition that triggers the branch.
- How the owner detects the condition.
- Next action and owner.
- Timeline for exception handling.
When the context does not support a step, prerequisite, owner, or
exception, flag it as "[GAP: <what is missing>]" instead of
inventing content.
ACCEPTANCE:
- Every step has a named role owner. No "the team" or "someone."
- No step contains "and" between two verbs. Split if present.
- Every step has an observable verification criterion.
- At least three exception branches, each with a named next action
and a timeline.
- Gaps are flagged, not filled with plausible guesses.The acceptance clause does the most work. Without it, the output regresses to the corporate-fluff shape a generic prompt produces. The "no 'and' between two verbs" rule catches the compression the model reaches for whenever two steps are close in activity.
Common Anti-Patterns
- "Write the SOP" as a single prompt with no scaffold. Produces corporate fluff. Fix: require numbered atomic steps, owners, prerequisites, exceptions, verification.
- Verbs that describe shape instead of action. "Review," "coordinate," "ensure" without an object. Fix: require one imperative verb and one artifact per step.
- "The team" as an owner. No one owns what everyone owns. Fix: require a named role per step.
- Exceptions in a single "if something goes wrong" section at the end. Disconnects failures from the steps they fail at. Fix: branches inline.
- Verification as "complete when the owner says so." Not observable. Fix: require an observable state — a record updated, an email logged, a status changed.
- Fabricated exception paths. The model invents plausible failures that are not real for this process. Fix: require exceptions to come from listed known failures or flag as a gap.
FAQ
How long should an AI-drafted SOP be?
As long as the process requires. Vendor onboarding might run 20 steps; a password reset might run 5. Length is not a quality signal. If your convention is one-page SOPs, put that in the prompt — "under 800 words" — and edit after. Do not let length pressure compress atomic steps back into vague phases.
Do we still need a human reviewer if the SOP is AI-drafted?
Yes. The model produces a draft; the operations owner validates it against reality. Skipping the review tends to ship SOPs with plausible-sounding but wrong owner assignments, or exception paths describing failures that never actually happen. The model cannot know what your process does in practice, only what similar processes tend to do.
Does this pattern work for SOPs that span multiple teams?
Yes, with a caveat. Cross-team SOPs have handoff ambiguity — which team owns a step is the thing the SOP is supposed to resolve. Feed team boundaries as explicit context, require handoffs to be their own step (not a sub-bullet), and require the owner to change with the handoff. For turning cross-team SOPs into automation specs, see AI process automation prompts.
Should we use the same prompt template for every SOP?
Start with one shared prompt template that lives in a repo or snippet library, and let it evolve as the team learns what works. Some processes need more exception detail; some need more verification detail. Improvements go back into the shared version so the next SOP benefits.
How do we keep AI-drafted SOPs from going stale?
Treat the SOP as code: version it, review it on a cadence, assign a named "SOP owner" responsible for updates. When the process changes, the SOP update is part of the change. AI lowers the cost of updating — feed the current SOP and the change description and ask for a revised draft — but does not solve the discipline problem.
The point of an SOP is to remove work, not to look like an SOP. Structured prompts produce SOPs that do the first job. Unstructured prompts produce SOPs that do the second so convincingly nobody notices the first never got done.