Turn how you actually work into a document someone else can follow. Below are 7 copy-ready prompts. Fill in the [BRACKETS], copy, and paste into ChatGPT, Claude, Gemini or any capable assistant.
An SOP fails for one of two reasons: the person who knows the process never wrote it down, or they wrote down the clean version rather than the real one. AI fixes the first problem well and makes the second one worse unless you prompt against it.
The 7 prompts
Turn a messy process description into a numbered SOP
Convert an informal explanation of how something gets done into a clean, auditable standard operating procedure.
You are a process documentation specialist. Turn the messy description below into a formal Standard Operating Procedure. PROCESS NAME: [PROCESS NAME] DEPARTMENT: [DEPARTMENT] WHO PERFORMS IT: [ROLE OR ROLES] HOW OFTEN: [FREQUENCY] MESSY DESCRIPTION: """ [PASTE THE INFORMAL DESCRIPTION] """ Produce the SOP with these sections in order: 1. Purpose - one sentence on why this process exists 2. Scope - what is and is not covered 3. Roles and responsibilities - table of role vs responsibility 4. Prerequisites - access, tools, approvals needed before starting 5. Procedure - numbered steps. One action per step. Start each step with a verb. 6. Decision points - any step where the path branches, written as IF/THEN 7. Common failure points - what usually goes wrong and how to recover 8. Revision history - a table with a single first row dated today Rules: - Where the description is ambiguous, do NOT invent detail. Insert [CLARIFY: your question] instead. - Keep each step under 25 words. - Do not use the words 'simply', 'just', or 'obviously'.
What you get: A complete SOP document with eight sections, numbered steps, and explicit [CLARIFY] markers wherever your source was vague.
Tip: The [CLARIFY] rule is the most valuable line in this prompt. Without it, models confidently invent approval steps that do not exist at your company.
Extract an SOP from a recorded screen-share transcript
Turn a 'let me show you how I do this' recording into written documentation.
You are documenting a process from a screen-share transcript where an expert narrated what they were doing. TOOL/SYSTEM USED: [SOFTWARE NAME] TASK BEING DEMONSTRATED: [TASK] TRANSCRIPT: """ [PASTE TRANSCRIPT] """ Produce: PART A - The procedure Numbered steps. For each step give: the action, the exact UI element clicked or field filled (quote the label if the speaker said it), and the expected result. PART B - Tacit knowledge List everything the expert did without explaining why. These are the judgement calls a new person will get wrong. Phrase each as: "The expert [did X]. A new person needs to know [why]." PART C - Gaps List every point where the transcript is unclear or the speaker trailed off, with the timestamp if available. Do not smooth over gaps. Part C is the most important output.
What you get: Three-part document: clean steps, the unspoken expertise, and an explicit gap list to go back and ask about.
Tip: Part B is why this beats writing the SOP yourself. Experts systematically omit the things they find obvious, and those are exactly what new hires get wrong.
Audit an existing SOP for gaps and ambiguity
Pressure-test a written procedure before it goes into the handbook.
You are a quality auditor reviewing a Standard Operating Procedure. Be harsh. Your job is to find what will break. SOP: """ [PASTE SOP] """ WHO WILL FOLLOW IT: [EXPERIENCE LEVEL, e.g. new hire in week one] Review against these tests and report findings as a table with columns: Step | Issue | Severity (High/Medium/Low) | Suggested fix. Tests: 1. AMBIGUITY - could two reasonable people read this step and do different things? 2. MISSING PREREQUISITE - does a step assume access, data, or approval not mentioned earlier? 3. UNDEFINED TERM - jargon, acronym, or internal system name used without definition 4. NO FAILURE PATH - what happens if this step fails? Is it stated? 5. HIDDEN DECISION - a step that actually requires judgement but is written as if mechanical 6. UNVERIFIABLE - no way to confirm the step succeeded before moving on 7. STALE RISK - anything likely to be out of date within 12 months After the table, give the single change that would most reduce error rate, and say why.
What you get: A severity-ranked audit table plus one prioritised recommendation.
Tip: Telling the model 'be harsh' and 'your job is to find what will break' meaningfully changes output. Without it you get polite validation.
Build a process map from an SOP
Turn written steps into a flow you can see, including every branch.
Convert this SOP into a process flow.
SOP:
"""
[PASTE SOP]
"""
Output in three formats:
1. MERMAID FLOWCHART - a valid mermaid `flowchart TD` code block. Use rectangles for actions, diamonds for decisions, rounded for start/end. Label every decision edge with its condition.
2. SWIMLANE TABLE - columns are the roles involved, rows are sequential steps, each cell holds the action that role performs at that point (or is blank).
3. HANDOFF LIST - every point where work passes from one role to another. For each: who hands off, who receives, what is handed over, and what the receiver needs to check.
The handoff list is the priority output - handoffs are where processes fail.
What you get: A pasteable Mermaid diagram, a swimlane table, and an explicit handoff register.
Tip: Paste the Mermaid block into mermaid.live to render it free. If the diagram fails to parse, paste the error back and ask for a fix.
Write a one-page quick reference card from a long SOP
Compress a 6-page procedure into something someone will actually keep at their desk.
Compress this SOP into a single-page quick reference card.
SOP:
"""
[PASTE SOP]
"""
Constraints:
- Must fit on one side of A4 at 11pt. Assume roughly 450 words maximum.
- Assume the reader has done this before and needs reminding, not teaching.
Structure:
- TOP: the process name and the one thing that must be true before you start
- MIDDLE: the steps as a numbered list, maximum 12 words each, verbs first
- DECISION BOX: any IF/THEN branches, as a compact table
- BOTTOM LEFT: 'If it goes wrong' - the three most common failures and the immediate fix
- BOTTOM RIGHT: who to escalate to, and the deadline/SLA if there is one
Cut anything that is context, rationale or background. Keep only what is needed in the moment.
What you get: A tight, printable one-pager built for someone mid-task, not someone learning.
Tip: Give it a word budget, not a page count. Models have no idea how much text fits on a page, but they can count words.
Create an onboarding checklist for a role
Turn a job description and a pile of SOPs into a structured first-90-days plan.
Build a structured onboarding checklist. ROLE: [JOB TITLE] REPORTS TO: [MANAGER ROLE] KEY RESPONSIBILITIES: [PASTE FROM JOB DESCRIPTION] SYSTEMS THEY WILL USE: [LIST TOOLS/SOFTWARE] EXISTING DOCUMENTATION: [LIST SOP NAMES, OR 'none'] Produce a checklist across four phases: Before day one, Week one, Weeks 2-4, Days 31-90. For each phase give a table: Task | Owner (new hire / manager / IT / other) | Done when (an observable, checkable condition) | Depends on. Rules: - 'Done when' must be observable. 'Understands the CRM' is wrong; 'Has independently logged one new lead in the CRM' is right. - Every system in the list needs an access-request task in 'Before day one', owned by someone other than the new hire. - Include at least two tasks where the new hire produces something reviewable, not just consumes information. - Flag with [DOC GAP] any task that needs documentation you said does not exist.
What you get: A four-phase onboarding checklist with observable completion criteria and flagged documentation gaps.
Tip: The 'observable done-when' rule is what separates a usable checklist from a wish list. It also quietly generates your training-material backlog.
Find the automation candidates in a process
Work out which steps are worth automating before you spend money on tooling.
Analyse this process for automation potential. Be sceptical - most steps are not worth automating. PROCESS: """ [PASTE SOP OR PROCESS DESCRIPTION] """ HOW OFTEN IT RUNS: [FREQUENCY] MINUTES PER RUN: [TIME] PEOPLE INVOLVED: [NUMBER AND ROLES] TOOLS ALREADY IN USE: [LIST] For each step, score: - Repetitiveness (1-5): identical every time vs judgement-heavy - Rule-clarity (1-5): fully specifiable vs requires context - Volume: how many times per month - Error cost: what happens when it goes wrong Then produce three lists: 1. AUTOMATE NOW - high repetitiveness, high rule-clarity, meaningful volume. For each, name the category of tool needed (not a brand) and estimate monthly minutes saved. 2. AUTOMATE LATER - worth it but blocked by something. Name the blocker. 3. LEAVE ALONE - and say why. Judgement, low volume, or the cost of getting it wrong exceeds the saving. End with the honest total: monthly minutes saved if list 1 were fully automated, and roughly what that is worth. Do not recommend automating anything under 30 minutes of monthly saving.
What you get: Three ranked lists plus an honest total time saving, with low-value automation explicitly rejected.
Tip: The 'leave alone' list is the useful one. It stops you automating a five-minute monthly task and calling it transformation.
Where AI actually helps here
- Turning a rambling description, a recorded walkthrough or an old checklist into numbered steps with owners
- Spotting the steps you skipped because they are obvious to you and invisible to everyone else
- Producing the boring-but-necessary parts: prerequisites, handoffs, escalation paths, glossaries
Where it falls down
- Inventing the steps you did not mention. A model asked to document a process will happily fill gaps with a plausible generic version of it
- Smoothing over contradictions in your description instead of flagging them
- Writing the ideal process rather than yours — which is why the first draft often describes a company you do not work at
The mistake almost everyone makes: Letting it fill the gaps silently
The single instruction that changes SOP quality more than any other: where my description is vague or contradicts itself, do not smooth it over — write the step as best you can and add a line starting “OPEN QUESTION:” underneath. Without it you get a confident document with invented steps buried in the middle, and you will not find them until someone follows one.
Free tool: SOP Generator
Runs in your browser. No sign-up, nothing uploaded.
Questions people ask
Can AI write an SOP from a meeting recording?
Yes, and this is where it works best. Paste the transcript and ask for numbered steps with an OPEN QUESTION line wherever the recording is unclear. The gaps in a transcript are the gaps in your process — the flags are the useful output, not a failure.
How long should an SOP be?
As long as it takes someone unfamiliar with the work to finish it without asking. That usually means shorter steps and more of them, not fewer longer ones. If a step contains the word “and”, it is two steps.
Which model writes the best SOPs?
In practice, Claude holds a long unstructured description together better and flags its own gaps more honestly. GPT produces tidier formatting faster. If the input is a messy transcript, start with Claude.