businessoperations

SOP Document Writer

Drafts a clear standard operating procedure with step-by-step instructions, roles, and exception handling.

Prompt
You are an operations manager who specialises in process documentation for [industry] companies. Write a Standard Operating Procedure (SOP) for [process name] at [company type]. The target audience is [team/role] and the goal is to ensure consistent execution. Format as a structured document with these sections: (1) Document header: title, SOP number (e.g. SOP-OPS-001), effective date, revision number, author, approver, (2) Purpose: why this SOP exists in 2-3 sentences, (3) Scope: who and what it applies to, (4) Definitions: define 3-5 key terms such as 'escalation', 'SLA', or domain-specific terminology, (5) Responsibilities: list each role in a RACI table format, (6) Procedure: numbered step-by-step instructions (15-25 steps) with sub-steps where needed, (7) Exception Handling: what to do when 3 common exceptions occur, (8) Related Documents: placeholder references, (9) Revision History table. You must ensure each step starts with an action verb. For example, 'Verify the customer record exists' rather than 'The customer record should be verified'. Avoid passive voice throughout. Only include steps that are necessary. Do not pad with obvious instructions. Do not use jargon without defining it first.

Why this prompt works

What separates a useful SOP from a binder is whether each step starts with an action verb. The 'action verb' constraint plus the example pair ('Verify the customer record exists' instead of 'The customer record should be verified') is what produces an SOP someone can actually follow without re-interpreting it. The RACI table on responsibilities is the section most teams skip on first pass, which is exactly what makes SOPs unusable when something goes wrong; the prompt forces it. The exception-handling section addressing three common deviations is also non-trivial: most SOPs document the happy path and stop, leaving operators to invent the rest.

When to reach for it

  • You're documenting a process for the first time and want a starting structure rather than a blank Confluence page.
  • You're standardising how a process is run across regions or teams and need a single doc that everyone can refer back to.
  • You're handing over a process to a successor or vendor and want the handover document to survive without you in the room.

How to customise it

The team or role field shapes the level of detail; an SOP for senior engineers can skip steps that an SOP for new hires must include. Be honest. The 'company type' input also matters: regulated industries (healthcare, finance, legal) need different precision than internal-only ops, and you should add 'include compliance checkpoints where applicable' to the brief if you operate in one. For SOPs that reference internal tools, name them in the input ('Salesforce', 'Jira', 'Workday') so the steps reference the right interfaces rather than generic ones.

What good output looks like

A document running 1,500 to 2,500 words depending on process complexity. The header section has the SOP number, dates, and approver fields as placeholders. Definitions and responsibilities tables come before the procedure, which is the longest section (typically 18 to 22 numbered steps). Exception handling has three named scenarios with action sequences. The revision history table is empty by design; you fill it as the doc evolves.

SOPprocess documentationoperationsstandard procedureChatGPT / Claude

Build a prompt like this for your task

Use the free guided prompt builder on the homepage: pick what you need, answer three quick questions, and get a high-scoring prompt of your own.

Open the prompt builder →
100
out of 100
Role definition100
Task clarity100
Specificity100
Context100
Output format100
Constraints100
Examples100