Write a Standard Operating Procedure with AI

If your team relies on tribal knowledge to get anything done, you have a problem that compounds quietly until someone leaves or something breaks. Standard Operating Procedures fix that. The traditional way to write them is to pull a subject-matter expert into a meeting for two hours, take notes, then spend another hour formatting those notes into a document that still manages to miss half the edge cases. Claude can do this in a few minutes.

The output is not a rough draft that needs heavy editing. With a solid description of the process, you get a properly structured SOP with purpose, scope, responsibilities, and numbered steps. What you still need to do is verify that those steps match reality.

Getting the Input Ready

The description you paste in does not have to be polished. A brain-dump works fine. What matters is that it includes:

• Who is involved (which roles, departments, or individuals touch this process)
• Where the process starts and ends
• The main steps in order, even if you phrase them roughly
• Any common mistakes or exceptions you can think of

You do not need to write in formal SOP language. Write the way you would explain it to a new hire out loud. The prompt handles the conversion to structured format.

If the process has a lot of conditional steps (“if the client is enterprise, do X; otherwise do Y”), note those explicitly. Claude will work them into the exceptions section. If you skip them, they will not appear in the output, and your SOP will look clean but incomplete.

One thing worth doing before you paste: think about who the audience is. A procedure for a warehouse team reads differently from one for a finance department. You can tell Claude the audience in the first sentence of your description and the language will adjust accordingly.

The Prompt

You are an experienced operations manager. I am going to describe a business process. Turn it into a formal Standard Operating Procedure (SOP) document.

Format the SOP with these sections:
1. Title
2. Purpose (1-2 sentences on why this process exists)
3. Scope (who this applies to)
4. Roles & Responsibilities (bullet list)
5. Step-by-Step Procedure (numbered, one action per step -- be specific enough that someone doing this for the first time can follow it without asking questions)
6. Notes / Exceptions (edge cases, common mistakes)
7. Revision History (placeholder row: Version 1.0, [today's date], Initial draft)

Here is the process to document:

[PASTE YOUR PROCESS DESCRIPTION HERE]

Write the SOP now. Use plain language. Avoid jargon. Each step should start with an action verb.

The instruction “each step should start with an action verb” is worth keeping. It forces every step to be specific and actionable rather than describing a state. “The system is checked” becomes “Check the system for pending alerts before proceeding.”

What You Get

The output is a complete SOP ready to paste into whatever system your team uses. A typical result for a moderately complex process runs about 400 to 600 words, structured into the seven sections listed in the prompt.

The Step-by-Step Procedure section is the one to scrutinize. Read it as if you are doing the task for the first time. If a step assumes knowledge that is not stated anywhere in the document, edit it. If the order of steps looks wrong, swap them. Claude follows the logic of the description you provided, so any gaps in your input show up as gaps in the output.

The Roles and Responsibilities section is useful for surfacing assumptions you did not realize you were making. If the SOP says “the department manager approves this step” but there is no approval step in your actual process, that is a sign the description was incomplete.

After the First Draft

Run the draft past the person who actually does the job most often. Not for approval, but for accuracy. They will catch the step that is technically correct but skips an implicit check, or the exception that happens every third time but nobody thought to mention.

If the SOP covers a regulated process (HR, safety, food handling, finance), have someone qualified review it before it goes live. The prompt is designed to produce complete, usable documents, not to substitute for compliance review.

For high-traffic SOPs, add a version control habit from day one. The revision history section the prompt includes is a placeholder. Put a real date in it, assign a version number, and update both every time the document changes. A well-maintained SOP that your team actually trusts is worth more than a perfect document nobody looks at.