Standard Operating Procedure Writer
Capture the steps—and the exceptions a new hire cannot guess.
Turn rough process notes into testable steps, explicit decisions, recovery guidance and questions for the current owner.
Ready-to-use prompt
The prompt
Copy it as-is, then swap the bracketed placeholders for your own details before running it.
Role: You are an operations writer producing a standard operating procedure that a competent new joiner can follow unsupervised.
Context:
- Task or process: {{process}}
- Who performs it today and how often: {{owner_and_frequency}}
- Tools, systems and access required: {{tools}}
- What a correct finished result looks like: {{definition_of_done}}
- Known failure modes or past incidents: {{known_failures}}
- Rough description of how it is done today: {{current_method}}
Task: Produce the SOP in this order.
1. Purpose in one sentence, the trigger that starts the process, and the owner role rather than a person name.
2. Prerequisites: access, permissions, inputs and approvals needed before step one.
3. Numbered steps. Every step begins with a verb, names the system used, and states the observable result that confirms it worked.
4. Decision points as an explicit table: condition, action, who decides, escalation path if unclear.
5. Failure handling: for each known failure mode, the detection signal and the recovery step.
6. Definition of done, including where the output is stored and who is notified.
7. Tacit knowledge gaps: everything the current owner does automatically that is not yet written down, listed as questions to ask them.
Rules:
- Never write a step a reader could perform two different ways. Split it.
- Do not use vague verbs such as handle, manage, review as appropriate or ensure.
- Flag any step whose duration or frequency you are guessing at with ASSUMPTION.
- Keep any step that requires judgement in the decision table, not in the numbered list.
Finish with: the three steps most likely to be skipped under time pressure, and what breaks downstream when they are.Estimated results
Editor's note
Why this prompt matters
A task is not ready to delegate just because its owner can describe the happy path. New hires get stuck on details experienced staff no longer notice: which queue to open, what confirms a save, whether a duplicate should be deleted, and who can approve an exception. A document that skips these details simply moves the dependency from a conversation into a file.
This prompt turns an existing routine into instructions with checkpoints. Supply the actual tools, access requirements, completion criteria and messy current method—not an idealised process. It separates repeatable actions from judgement calls, then exposes missing knowledge as questions for the owner.
Use the first draft as an interview and walkthrough aid, not immediate authority to operate. Confirm the decision rules, test the steps with a newcomer, and resolve missing permissions or recovery instructions before publishing. The useful outcome is a procedure someone can execute and verify, including knowing when to stop.
Anatomy
Prompt engineering breakdown
Role
Writes for independent execution.
Context
Grounds instructions in current practice.
Goal
Makes an informal task transferable.
Constraints
Separates actions, judgement and assumptions.
Output format
SOP, decision table, recovery guidance and questions.
Why this structure works
Makes missing dependencies visible before handover.
What you'll get
Expected output
What the draft contains
Expect purpose, trigger, owner role, prerequisites, numbered actions, a decision table, failure handling, completion criteria and questions for the current owner. It closes with three likely skipped steps and their downstream consequences. Missing operational facts should remain questions rather than become plausible instructions.
Worked example: logging supplier invoices
Suppose the supplied notes say: “The operations coordinator checks the shared finance inbox each weekday, saves invoice attachments in the shared invoice folder, and creates draft records in the accounting system. Match supplier and invoice number to detect duplicates. The finance lead resolves duplicates and missing purchase orders. Never submit payment.” Folder location and notification channel are also supplied.
The draft should identify a new invoice email as the trigger. Prerequisites include inbox access, folder write access, draft-entry permission and an invoice attachment. Payment approval is outside scope.
Representative steps would look like:
- Open the invoice attachment in the shared finance inbox; confirm the supplier and invoice number are readable.
- Search the accounting system using those identifiers; confirm the results display before following the decision table.
| Condition | Action | Decider / escalation | |---|---|---| | Existing matching record | Pause draft creation | Finance lead; backup unresolved | | Purchase order missing | Pause and request instructions | Finance lead; backup unresolved |
Failure handling should distinguish an unreadable attachment from a failed upload. For the upload, verify whether a file exists before retrying; confirm the authorised retry method with the owner.
Completion means a saved attachment and draft record—not payment. Specify storage and notification destinations. Ask who covers absent approvers and how corrected invoices are identified.
The skipped-step warning should connect duplicate checking, upload confirmation and notification to duplicate records, missing evidence and stalled processing.
Under the hood
Why this prompt works
The Role sets a practical standard: a competent newcomer must be able to follow the procedure without relying on the writer's memory. Context anchors the draft in an existing process. In particular, {{definition_of_done}} distinguishes completing an action from achieving the required result, while {{known_failures}} prevents an exclusively happy-path document.
The Task imposes a sequence that exposes dependencies before execution: prerequisites come first, decisions have accountable owners, and recovery instructions sit alongside completion criteria. The Rules constrain ambiguous writing. Verb-led steps with named systems and observable results are easier to test than instructions such as “handle the invoice appropriately.”
Separating judgement into a table makes approval boundaries visible. Flagging guessed timing with ASSUMPTION prevents estimates from quietly becoming policy. Finally, unanswered tacit-knowledge questions preserve uncertainty and give the process owner a focused validation checklist before handover.
Model fit
Best AI models for this prompt
ChatGPT
Use for a structured first draft. Check that decision branches stay outside numbered actions.
Claude
Use for scrutinising ambiguous owner notes. Ask it to prioritise blocking questions over stylistic refinements.
Gemini
Use with tool documentation or screenshots where supported. Verify interface labels and permissions against your live setup.
Grok
Use for an exception-focused second pass. Require recovery suggestions to remain provisional unless supported by your supplied process.
When to use
- Preparing a recurring task for onboarding.
- Covering an owner's planned absence.
- Reconciling inconsistent team practices.
- Capturing decisions before proposing automation.
When not to use
- No existing practice to capture.
- Rapidly changing workflows without an owner.
- Regulated work without required expert approval.
- Live incidents needing current system evidence.
Get more from it
Pro tips
- 1
Paste messy notes into {{current_method}}.
- 2
Name roles, not individual employees.
- 3
Include one real exception.
- 4
Supply exact storage destinations.
- 5
Resolve blocking questions before publication.
- 6
Test using a non-production example.
Don't ship this
Common mistakes
✗ Accepting invented interface paths.
Fix — Verify each path in the actual tool.
✗ Treating saved as complete.
Fix — Specify the confirming status and notification.
People also ask
Frequently asked questions
Q.What if the person who does the task cannot explain it clearly?
That is the normal case, and it is why the prompt returns a tacit knowledge question list rather than filling the gaps itself. Work through those questions with them, then rerun; the second draft is the one worth handing over.
Q.Why keep decisions out of the numbered steps?
Because a step containing a judgement call reads as an instruction and gets guessed at. In a decision table with a named escalation path, the same judgement gets escalated instead, which is what you wanted the document to achieve.
Q.How do I know the SOP is good enough to publish?
Hand it to someone who has never done the task and watch. Every question they ask is a missing step or an unlisted prerequisite. Two clean runs by a new person is a reasonable bar for publishing.