Free SOP Generator Prompt (Document Any Process)

TL;DR: An AI SOP generator is a prompt, not a product. Give any model a fill-in-the-blanks brief covering process name, trigger, owner, inputs, tools, steps, decision points, failure modes, escalation and review date, and it will produce a usable standard operating procedure in one pass. The hard part is extraction, not formatting.

What is an AI SOP generator, and does it actually work?

An AI SOP generator is a structured prompt that turns a messy brain-dump about how a process works into a formatted standard operating procedure. It works, with one large caveat: the model can only organise what you give it, and it will happily invent the rest.

That caveat is the whole story. If you type "write an SOP for onboarding a new client" into any model, you get back something that looks correct — numbered steps, a purpose statement, a header table — and describes a company that does not exist. It will tell you to send a welcome packet you do not have and schedule a kickoff call you do not run. It reads well enough that somebody will file it, and six weeks later a new hire will follow it and do the wrong thing.

So the generator is not the clever part. Any decent prompt template can impose structure on facts. The clever part is getting the facts, which live in one person's head and have never been said out loud. That is what most SOP content skips, and it is what the second half of this post is about.

If prompting itself is new to you, what prompt engineering actually is covers the basics. Everything below assumes you can paste a block of text into a model and read what comes back.

The free SOP generator prompt

Here is the block. It covers process name, trigger, owner, inputs, tools, steps, decision points, failure modes, escalation path and review cadence. Fill in what you know, mark the rest [UNKNOWN], and let the model tell you what it could not answer.

You are documenting a standard operating procedure for a team that has
never run this process before.

INPUT — fill these in. Leave a field as [UNKNOWN] if you don't know it.
Do not guess on my behalf.

Process name:        [e.g. Issue a refund over $500]
Trigger:             [what starts it — an event, request, schedule, threshold]
Owner (role):        [the role accountable for the outcome, not a person's name]
Performed by (role): [who actually runs it, if different from the owner]
Frequency:           [how often it fires]
Inputs required:     [data, approvals, files, access needed before step 1]
Tools / systems:     [named systems, and the permission level needed in each]
Steps (rough):       [brain-dump, any order, do not clean it up]
Decision points:     [every "if X then Y" fork, however small]
Failure modes:       [what has actually gone wrong, and how you noticed]
Escalation path:     [who to contact, when, and how fast they must respond]
Definition of done:  [the observable state that means it worked]
Constraints:         [any rule, contract or regulation that limits how it runs]
Review cadence:      [how often this document must be re-checked, and by whom]

RULES
1. Write only from what I gave you. Anything you infer, mark inline as
   [ASSUMPTION: ...] so I can confirm it or delete it.
2. If a field is [UNKNOWN], or a step is missing a precondition, do not
   invent it. List it under "Open questions" at the end.
3. Steps are imperative, one action per step, second person. No step
   contains two verbs joined by "and".
4. Every decision point becomes an explicit branch with a stated criterion.
   Never write "use your judgement" — ask me for the criterion instead.
5. Name the system and the exact screen, object or field for every action.
6. No adjectives. No rationale inside a step; rationale goes in "Why this
   matters", once, at the top.

OUTPUT
1. Header block: process name, owner role, version, date, next review date.
2. Purpose — one sentence.
3. When this runs — the trigger, stated as a condition.
4. Before you start — inputs, access and prerequisites, as a checklist.
5. Procedure — numbered steps, branches nested under their decision point.
6. Decision table — every fork, its criterion, and the resulting path.
7. If it goes wrong — failure mode, how to detect it, immediate action.
8. Escalation — who, when, which channel, expected response time.
9. Definition of done.
10. Open questions — everything you could not answer from my input.

Three details in there do the heavy lifting, and they are the three people delete first.

The [ASSUMPTION: ...] marker. Without it, invented content is indistinguishable from reported content. With it, you can scan the draft and delete anything the model made up in about ninety seconds. This single instruction is the difference between a draft you can trust and one you have to re-verify line by line.

The ban on "use your judgement". Every SOP that survives contact with a real new hire has this failure. A step says "escalate if the issue is significant" and nobody knows what significant means. Forcing the model to ask for the criterion converts a vague instruction into either a number or an explicit admission that the criterion has never been defined. Both are useful. The second is more useful.

The "Open questions" section. This is the output you should read first. It is the model telling you which parts of your own process you cannot currently explain. On a first pass through a genuinely undocumented process, expect eight to fifteen open questions. That list is your interview agenda.

Why the hard part is extraction, not formatting

Every SOP tool on the market solves formatting. Screen recorders capture clicks, templates impose headings, AI writers produce prose. None of them solve the actual problem, which is that the person who runs the process cannot tell you how they run it.

This is not laziness. It is how expertise works. When somebody has done a task four hundred times, the decisions have compressed into something that feels like instinct, and the parts they can still articulate are the parts that are obvious anyway. Ask a senior support lead how they handle a refund dispute and you will get six steps. Watch them do it and you will count nineteen, four of which involve checking something they never mentioned because checking it is automatic.

The gap between the six and the nineteen is the entire value of the SOP. It is also the part that walks out of the building when they leave — a problem agencies hit hard when staff turn over.

So do not ask people to describe their process. Ask about specific past events, and probe for the things experts systematically omit.

The interview prompt

This one makes the model run the interview for you, one question at a time. Paste it, then answer honestly, including the boring bits.

You are interviewing me to document a process I run. I know how to do it.
I am bad at explaining it, and I will skip things that feel obvious to me.
Your job is to catch what I skip.

Process: [NAME]

RULES
- Ask ONE question at a time. Wait for my answer before the next one.
- Never accept "it depends" or "you just know". Ask what it depends on,
  and what the possible values are.
- If I name a vague threshold ("if it's big", "if it's urgent"), ask for
  the number or the specific condition.
- If I say "usually" or "normally" or "most of the time", ask what the
  exception is, what triggers it, and roughly how often it happens.
- If one of my answers implies a step I have not mentioned, ask about that
  step before moving on.
- Do not summarise, reassure, or draft anything until I say "done".

COVER THESE, IN ORDER
1. WALKTHROUGH — walk me through the last real time I did this, start to
   finish. The actual one, not the ideal version. Ask what I did first.
2. FIRST CHECK — what do I look at before I touch anything? What am I
   checking for, and what would make me stop and not proceed at all?
3. DEVIATION — when do I not follow the normal path? What signal tells me
   this one is different? What do I do instead?
4. FAILURE — what goes wrong most often? How do I notice it has gone
   wrong? What do I do about it? And separately: what went wrong once that
   was expensive, and what do I now do to prevent it?
5. HANDOFFS — where does this leave my hands? Who do I wait on, how long
   do they normally take, and what do I do when they don't respond?
6. NEW HIRE — if someone competent but new did this tomorrow from my
   description alone, where exactly would they go wrong? What would they
   do in the right order but the wrong way?
7. OMISSION — what did I leave out because it seemed too obvious to say?
   Name three things. Push me if I say "nothing".

When I say "done", output a numbered list of every decision rule,
threshold, exception and check I stated, quoting my own words. Do not
write the SOP yet.

The ordering matters. Each probe is designed to defeat a specific way that experts under-report.

Walkthrough beats description because a description is a summary, and summaries drop steps. Anchoring to one real recent instance forces recall instead of reconstruction. "The last time" also surfaces the messy version, which is the one you need.

First check catches the pre-flight scan nobody mentions. There is almost always something the expert looks at before starting — a queue depth, a customer tier, a date, whether a flag is set — that determines whether the standard path applies at all. It gets omitted because it happens before the process "starts" in their mental model.

Deviation is where the real judgement lives. The standard path is easy to document and rarely the problem. What separates a competent operator from a new hire is knowing when the standard path does not apply, and that knowledge is stored as pattern recognition rather than as a rule. Asking "what tells you this one is different" converts recognition back into a stated signal.

Failure does two jobs. It produces the troubleshooting section, and it surfaces steps that exist purely to prevent a past disaster. Those steps look pointless in a clean SOP and get deleted by the first person who edits it, which is exactly how organisations relearn expensive lessons.

Handoffs catch the dead time. Most process pain is not in the steps, it is in waiting on someone who did not know they were on the critical path. An SOP that documents nine actions and no wait states will consistently under-promise on cycle time.

New hire is the strongest probe in the set, and it is worth asking even if you skip the others. Experts cannot easily list what they know, but they are very good at predicting how a novice will fail. Asking them to imagine a specific person getting it wrong gives them a concrete scene to inspect, and out comes tacit knowledge they could not retrieve when asked directly.

Omission with a forced quota of three is a deliberate trick. "Anything else?" reliably returns "no". A quota makes them search. The third item is often the best one.

Turning the interview into the document

Once the interview is done, chain the transcript straight into the generator block from earlier.

Below is a transcript of an interview about a process, plus the numbered
list of decision rules you extracted from it.

[PASTE TRANSCRIPT]
[PASTE RULES LIST]

Map this into the SOP input fields: process name, trigger, owner,
performed by, frequency, inputs, tools, steps, decision points, failure
modes, escalation path, definition of done, constraints, review cadence.

For each field, quote the line from the transcript it came from. If a
field has no supporting line, write [UNKNOWN] — do not fill it in from
general knowledge of how processes like this usually work.

Then produce the SOP using those fields, marking every inference as
[ASSUMPTION: ...].

The quote-the-source requirement is what keeps this honest. It makes hallucination visible: a field with no quote next to it is a field the model made up, and you can see it at a glance rather than discovering it in production.

The gap check

Before you publish, run the finished document through a hostile read.

Here is a finished SOP: [PASTE]

Act as a competent new hire on day three. You have exactly the access
listed in the document and no other context. Read it once, then answer:

1. Which steps could you not complete without asking somebody? Quote them.
2. Which steps could you complete in more than one way, with different
   end results?
3. Where does the SOP tell you what to do but not how to confirm you did
   it correctly?
4. Which decision points have no stated criterion?
5. What would you have to assume that the document never states?
6. Which named tools, screens or fields would you not be able to find?

Do not fix anything. List the gaps only, ranked by how likely each one is
to cause a wrong outcome rather than a delay.

Rank by wrong outcome, not delay. A gap that makes somebody stop and ask a question costs ten minutes. A gap that lets them proceed confidently in the wrong direction costs considerably more, and those are the ones a fluent, well-formatted SOP hides best.

SOP or checklist: which one do you actually need?

These are different documents with different jobs, and conflating them produces a file that fails at both. An SOP is read when you are learning the process or when something unusual happens. A checklist is used during the work, every single time, and contains confirmations only.

Atul Gawande's The Checklist Manifesto (Metropolitan Books, 2009) made the case for the second thing, and a lot of ops teams read it and turned their SOPs into checklists. That is a downgrade if the process has branches. A checklist cannot tell you what to do when the answer is no.

The practical rule: write the SOP first, then generate the checklist from it. Ask for "the confirmation-only checklist for the standard path in this SOP — no explanations, no branches, one line per item, phrased as something you can tick". You now have one authoritative document and one working aid that cannot drift from it, because one is generated from the other.

SOPs go stale. Put the expiry date inside the document.

Most SOP libraries fail the same way. Somebody documents thirty processes in a burst of enthusiasm, the tools change, nobody updates anything, and eighteen months later the library is worse than useless — because a wrong SOP is followed with confidence, whereas no SOP at least prompts somebody to ask.

The fix is unglamorous and it is a header block:

Process:        Issue a refund over $500
Owner (role):   Support Lead
Version:        2.1
Last verified:  2026-08-26   (by: Support Lead)
Next review:    2026-11-26   (quarterly — Stripe dashboard changes often)
Change log:     2.1 threshold raised $250 → $500
                2.0 moved from Zendesk macro to Stripe dashboard

Two things in there are doing real work. "Last verified" is not the same as "last edited" — somebody confirmed the steps still match reality on that date, which is a stronger claim than somebody fixed a typo. And the review cadence carries its reason. "Quarterly because the Stripe dashboard changes often" survives a handover. A bare "quarterly" gets dropped by the next owner as bureaucratic overhead.

This is not an invention. Recognised quality standards have required roughly this for years: ISO 9001:2015 clause 7.5.2 requires documented information to be identified with a title, date and author or reference number, and to be reviewed and approved for suitability before use, while 7.5.3 covers version control and a review cycle (as summarised by ISMS.online, read 26 August 2026 — ISO does not publish the clause text publicly). Worth noting for anyone who thinks a certified QMS mandates a specific SOP format: ISO 9001:2015 dropped the six mandatory documented procedures that the 2008 version required, and specifies no required procedures at all (Advisera, read 26 August 2026). You choose what to document. The standard only asks that whatever you do document is dated, owned and reviewed.

Calendar dates are the floor, not the mechanism. These events should force a review the day they happen, regardless of what the next-review date says: a tool migration or a significant UI change, a pricing or policy change, a reorg that renames the role in the escalation path, a new compliance requirement, and — the most informative one — the first time somebody follows the SOP correctly and still gets the wrong result.

When a trigger fires, do not rewrite from scratch. Diff it:

Attached is an SOP last verified on [DATE].

Since then, these things changed: [LIST — tools, team structure, volume,
policy, pricing, integrations, regulations].

For each change, tell me:
- Which specific steps, screens, fields or thresholds it invalidates.
  Quote the exact text from the SOP.
- Which steps are now unnecessary and can be deleted.
- Which new failure modes it introduces that the SOP does not cover.
- Whether the escalation path still points at a role that exists.
- Whether the definition of done is still observable the same way.

Output a change list, not a rewritten document. Mark each item CONFIRMED
(I told you it changed) or SUSPECTED (you inferred it from context).

A change list is reviewable in five minutes. A rewritten document has to be re-read in full, which is why nobody does it, which is why the library goes stale.

When you should not document a process at all

Documentation is not free. It costs an hour to write, and then it costs a small amount of attention forever, because every stale document in a library reduces trust in the rest of it. Some processes should not be documented. They should be automated, simplified, or deleted.

The first row is the one people resist. A process with no decision points and no judgement is exactly the thing computers are good at, and writing a careful SOP for it is a way of making peace with work that should not exist. If your process documentation project keeps producing linear, branchless procedures, you have found an automation backlog, not a documentation backlog.

There is a related trap worth naming. Documenting a broken process makes it permanent. Once the three-approval refund flow is written down, versioned and trained on, it acquires a constituency, and changing it becomes a project. Ask "should this process exist in this shape?" before you ask "how do I write it down?" — the generator prompt above deliberately asks for a definition of done, and if you cannot state one, that is usually the answer.

How to run this across thirty processes without retyping anything

One SOP is a document. Thirty SOPs, reviewed on a cadence, is a system, and the difference is whether the prompt lives somewhere reusable or gets retyped slightly differently every time.

This is the honest limit of what we do. Prompt Architects is not SOP software. We do not host your documents, version them, or route approvals — if you need that, you want a documentation platform, and there are several good ones. What we do is the layer above: keeping the prompts that produce those documents consistent, findable, and shared across a team.

Concretely, for this workflow: save the generator block, the interview prompt, the gap check and the diff prompt to your Prompt Library once, so the fifth process you document uses the same interrogation as the first. Put the parts that change per process — team name, tool stack, escalation defaults, house terminology — into Global Variables so you fill them in rather than editing prompt text, which is the same argument as reusable prompt variables for dev teams. Put your standing constraints into a Context Library entry so every SOP inherits your tone, your role names and your compliance boilerplate without repeating them. Then Team Sharing means the ops manager and the support lead are documenting to the same standard rather than to their own taste.

If you want the SOP output as machine-readable data — feeding a workflow engine, a task tracker, or a training system — ask for it as JSON rather than prose. The mechanics of getting reliable structured output are covered in JSON prompts explained, and a decision table converts to JSON far more cleanly than a paragraph does.

Everything in this post runs on the free plan. If you are building the library rather than testing one prompt, more on building a personal prompt library covers the organisation side, and current pricing is on the pricing page — paid plans start at $4.99/month at the time of writing, and there is a free tier that does not expire.