ESEN

AI prompts for SOPs: turn how-you-work into clear, testable procedures

How to use ChatGPT, Claude or Gemini to write standard operating procedures from walkthroughs, notes or call transcripts: what the model needs, how to keep steps concrete, how to find gaps before someone follows the SOP, and how to turn it into a checklist. Copy-paste templates included.

← Back to guides

What a usable SOP contains

  • Purpose and scope: what the procedure achieves, when to use it and when not to.
  • Who does it, and what they need before starting (access, tools, inputs).
  • Numbered steps, one action each, written as instructions ('Export the report as CSV', not 'The report is exported').
  • What 'done' looks like, and how to check it.
  • What to do when something goes wrong, and who to contact.

Start from how the work is really done

  • The best raw material is a walkthrough: a transcript of someone doing the task and explaining it, or their step-by-step notes.
  • Paste existing documents too, but tell the model which source wins when they disagree (usually the most recent walkthrough).
  • Ask the model to list every decision point it found ('if the client is new…') so branches don't get flattened into one path.
  • Ask for '[missing: …]' markers instead of plausible-sounding steps the source doesn't contain.
  • Remove passwords, access tokens and personal data from transcripts before pasting.

Test the SOP before you publish it

  • Ask a model to act as a new hire and list every step it couldn't perform with only the SOP in hand.
  • Have someone who didn't write it follow it once, and fix every place they had to ask a question.
  • Check that every tool, field and button name matches the current system; renamed screens are the most common reason SOPs fail.
  • Add an owner and a review date so the procedure doesn't silently go stale.

Templates

Draft an SOP from a walkthrough transcript

Write a standard operating procedure for [process] from the walkthrough below. The reader is [role], who has [level of experience].

<walkthrough>
[paste the transcript or step-by-step notes]
</walkthrough>

<existing_docs>
[optional: paste older documentation; the walkthrough wins if they disagree]
</existing_docs>

First, list every decision point you found (if/then situations) and every tool or system mentioned.

Then write the SOP:
1. Purpose and scope (when to use it, when not to).
2. Before you start: access, tools and inputs needed.
3. Steps: numbered, one action per step, imperative voice. Put branches as sub-steps ("If X: … / Otherwise: …").
4. Done when: how to check the result.
5. If something goes wrong: what to do and who to contact.

Rules:
- Only include steps that appear in the sources. Where something is missing, write [missing: …].
- Keep exact names of tools, fields and buttons as they appear in the sources.
Opens the analyzer with the prompt prefilled.
Open in Promptea

Find the gaps in an SOP (new-hire test)

Act as a new [role] on your first week. You have only the SOP below and no one to ask.

<sop>
[paste the SOP]
</sop>

Go through it step by step and list, in a table (step number | problem | question you would ask):
- Steps you couldn't perform because information is missing (access, location, values).
- Steps that combine more than one action.
- Terms or abbreviations that aren't explained.
- Decisions the SOP expects you to make without criteria.
- Places where you can't tell whether the step worked.

Don't rewrite the SOP. Only list problems.
Opens the analyzer with the prompt prefilled.
Open in Promptea

Turn an SOP into a run checklist

Turn the SOP below into a checklist someone can tick off while doing the work.

<sop>
[paste the SOP]
</sop>

Rules:
- One checkbox per action, in the same order as the SOP, as "- [ ] …".
- Keep decision points as short "If … → go to item N" lines.
- Keep exact tool, field and button names.
- Add a final "Done when" check copied from the SOP.
- Leave out explanations and background; link back to the SOP section number instead.
- Don't add steps that aren't in the SOP.
Opens the analyzer with the prompt prefilled.
Open in Promptea

FAQ

Can AI write an SOP without a walkthrough?
It can write a generic outline, but the steps that matter — your tools, your field names, your exceptions — only come from someone who does the work. Use a model-written outline as a starting structure, then fill it from a real walkthrough and mark anything unverified.
Should SOPs be long and detailed or short?
As short as the reader can follow without asking. Experienced staff usually need a checklist; new hires need the full procedure with context. Many teams keep both: the full SOP and a checklist generated from it, updated together.
How do I keep SOPs consistent across a team?
Save the drafting prompt with your section headings and rules in your team's prompt library, so every SOP comes out with the same structure. Running the prompt through Promptea's analyzer first helps catch missing format or constraint instructions before you share it.