Prompting Guide
How to Prompt Claude to Write a Standard Operating Procedure
A good SOP lets someone who's never done the task do it correctly on the first try.
Anthropic's Claude is good at turning a process you already know how to do into a standard operating procedure that someone unfamiliar with it can actually follow: numbered steps, clear stopping points, and the edge cases that trip people up. It isn't good at knowing the parts of your process that live only in your head, the exceptions you've never written down, or the specific tools and names your team actually uses, unless you give it those details. The fix is walking Claude through the real process the way you'd explain it to a new hire standing next to you, not the clean version you'd describe if someone asked what you do in one sentence.
To prompt Claude to write a standard operating procedure, describe the process step by step the way you'd actually do it, including the tools, systems, and exact names involved, and ask Claude to format it as numbered steps with a clear start and end point. Call out any exceptions, common mistakes, or decision points where the next step depends on a condition, and ask Claude to flag any step where it had to guess at a detail because you didn't specify it. Read the draft against the real process once, ideally while doing the task, before treating it as final.
Published
Free lesson · no account neededMeet ClaudeWhy Claude?6 minStart the free lessonKey Takeaways
- Describe the process as you actually do it, not the clean summary version. The steps you skip because they're automatic to you are exactly the steps a new hire needs written down.
- Give Claude the real names: the specific tool, the exact field, the system you log into. A step that says "update the system" is useless to someone who doesn't already know which system.
- Call out decision points explicitly. A process with a branch, "if the request is under $500, do X; if not, do Y", needs that branch stated, not implied by context only you have.
- Ask for a clear start and end point. An SOP that doesn't say when the task begins and when it's actually done leaves the reader guessing whether they've finished.
- Walk through the draft while doing the task once before publishing it. An SOP that reads fine on screen but skips a step only becomes obvious when someone actually tries to follow it in order.
- Separate the normal path from the exceptions. Burying an edge case in the middle of the main steps makes the common case harder to follow for the ninety percent of the time the exception doesn't apply.
Copy and Paste
Prompts You Can Use Today
A first draft from a walkthrough of the process
I'm going to describe how I do [task] step by step, including the exact tools and systems involved. [Walk through the process in as much detail as you can, including tool names, field names, and anything you check along the way]. Turn this into a numbered SOP with a clear starting point and a clear point where the task is done. Flag any step where you had to guess at a detail because I didn't specify it.
Describe the process the way you'd actually do it, including the small habitual checks you don't usually mention out loud; those are often the steps a new hire is missing.
Adding a decision point the steps depend on
Here's my draft SOP: [paste your draft]. Step 4 actually branches depending on a condition: if [condition], the next step is [X]; otherwise it's [Y]. Rewrite step 4 to state that branch clearly, so someone following the SOP knows which path applies to them before they continue.
Do this for every branch in the real process; an SOP that hides a decision point inside a single step is the most common reason someone follows the wrong path.
Separating the normal case from exceptions
Here's my draft SOP for [task]: [paste your draft]. Pull out anything that only applies in unusual situations, like [describe the exception], into a separate "Exceptions" section at the end, so the main numbered steps only describe the normal case. Keep a short pointer in the main steps noting where to check if the current case doesn't fit the normal pattern.
This keeps the common path easy to follow instead of making every reader wade through edge cases that apply to a small fraction of cases.
Stress-testing the SOP for a gap
Read this draft SOP as if you've never done this task before and are following it for the first time: [paste your draft]. At each step, tell me anything you'd need to know that isn't stated, any term that isn't defined, or any point where you'd be unsure whether you did the step correctly before moving to the next one.
This surfaces the gaps that are invisible to you because you already know the process; a fresh read catches what familiarity hides.
Adapting an SOP after the process changes
Here's our existing SOP for [task]: [paste the current SOP]. The process changed: [describe what's different now]. Update the SOP to reflect the new process, and call out exactly which steps changed so the team can see what's different from the version they already know.
Calling out what changed, rather than silently replacing the old steps, helps people who memorized the previous version notice what's actually different.
The Structure
What a followable SOP actually needs
These are the pieces that let someone unfamiliar with a task complete it correctly on the first attempt.
A clear start and end point
State exactly when the task begins and what it looks like when it's genuinely done. An SOP without a defined endpoint leaves the reader guessing whether they've finished or missed a step.
Real names for real tools
Use the actual system, field, and tool names your team uses, not a generic description. "Open the request" is only useful if the reader already knows where requests live; name the system.
Decision points stated explicitly
If the process branches based on a condition, say so directly in the step rather than leaving it implied. A hidden branch is the most common reason someone follows the wrong path.
Exceptions separated from the main steps
Keep the normal path short and clean, and move edge cases to their own section. An SOP that buries exceptions in the main steps makes the common case harder to follow.
The Steps You Skip
Why the process you'd describe in one sentence isn't the process to give Claude
If someone asked what you do for this task, you'd probably summarize it in a sentence or two: "I check the request, verify the account, and process the refund." That summary is accurate, and it's also missing nearly everything a new hire would actually need, because the small checks you do automatically, the specific field you glance at, the thing you always confirm before moving on, have become invisible to you through repetition. They're not invisible to someone doing the task for the first time.
This is the gap that makes a first-draft SOP feel thin even when it's technically correct. Claude can only write down what you tell it, and if you describe the clean summary version of the process, you get back a clean summary formatted as numbered steps, not an actual procedure someone unfamiliar with the work could follow. The fix is narrating the process the way you'd walk a new hire through it standing next to you, including the parts that feel too obvious to mention.
A useful trick for surfacing those invisible steps is to actually do the task once while narrating it out loud, or as close to that as you can get in a prompt, rather than summarizing from memory afterward. The habitual checks tend to surface naturally when you're walking through the live process; they tend to disappear when you're recalling it from memory after the fact, because memory keeps the summary and drops the small moves that made the summary true.
Common Mistakes
What makes an SOP fail the first time someone actually uses it
These are the gaps that turn a reasonable-looking document into one that doesn't survive contact with a real, unfamiliar user.
Vague tool references instead of real names
"Log the update in the system" means nothing to someone who doesn't already know which system, which screen, and which field. Name the actual tool every time.
A hidden decision buried inside one step
If a step secretly depends on a condition that isn't stated, the reader won't know which path applies to their situation until it's already too late to easily switch tracks.
No stated endpoint for the task
If the SOP doesn't say what "done" looks like, the reader is left guessing whether to move on or whether they've missed a step that comes after the last one written.
Exceptions mixed into the main steps
An edge case placed in the middle of the normal steps forces every reader, including the ones in the common case, to figure out whether it applies to them before continuing.
Keeping Related Material Together
Why an SOP benefits from living alongside its related documents
A standard operating procedure rarely stands alone. It usually references a policy it has to comply with, a prior version it replaced, or a related procedure for a different but connected task, and keeping those documents close together while drafting makes the result more consistent than writing the SOP in isolation and hoping it lines up with everything else. Claude's Projects feature lets you keep a set of related files together in one place so each conversation about the SOP can reference the same background material without you re-pasting it every time, which is documented at support.claude.com's Projects help page.
This matters most when an SOP needs to stay consistent with a policy document that changes independently of the procedure itself. If the policy sets a threshold, like a dollar amount that determines which approval path applies, keeping the policy and the SOP in the same project means a future update to one is easier to check against the other, rather than discovering months later that the procedure and the policy it's supposed to implement have quietly drifted apart.
It also helps when a team maintains several related SOPs for variations on the same task, like one procedure for a standard request and a second for an expedited one. Having both in view at once makes it easier to keep the shared steps worded consistently and the differences between them deliberate rather than accidental, which matters more than it sounds like it should once two people are each updating a different version of what's supposed to be the same underlying process.
Before You Publish It
What to check before the SOP becomes the official version
Walk through the draft while actually doing the task, not just reading it at your desk. A step that looks complete on screen often turns out to skip a small action you do automatically, and that gap is far more obvious with your hands on the keyboard than it is reading silently from top to bottom.
Check every tool name, field name, and system reference against what's actually on screen right now. Interfaces change, and an SOP that still references a renamed button or a retired system will send a new hire looking for something that no longer exists, which is a worse failure than a missing step because it looks like their mistake rather than the document's.
Give the draft to someone who's never done the task, if you can, and watch where they hesitate. The point where someone genuinely unfamiliar with the process pauses and asks "wait, what do I do here?" is the single most reliable signal for where the SOP actually has a gap, more reliable than your own re-read, because you can't un-know the process to read it the way they're reading it.
Claude can turn a detailed walkthrough into a clean, numbered procedure quickly, but the judgment about whether that procedure actually matches how the work gets done, and whether it's complete enough for someone new to follow without asking a question, is still something only a real test run against the live task can confirm.
A good SOP survives its first real user
Describing a process in enough detail that someone else can actually follow it is a specific writing skill. Nightschool AI's free lessons cover real workplace writing tasks with Claude, including the judgment calls around what to spell out and what to leave to a separate exceptions section.
Frequently Asked Questions
What's the most important thing to tell Claude before it drafts an SOP?
Walk through the process the way you'd actually do it, including the real tool and field names and the small habitual checks you don't usually mention out loud. Those invisible steps are what a new hire actually needs.
How should I handle a step that depends on a condition?
State the branch explicitly in the step: if a condition is true, do one thing; if not, do another. A hidden decision buried inside a single step is the most common reason someone follows the wrong path.
Should exceptions be mixed into the main numbered steps?
No. Keep the normal path short and move edge cases to a separate exceptions section, with a short pointer in the main steps noting where to check if the current case doesn't fit the normal pattern.
How do I know if my SOP draft actually has a gap?
Walk through it while physically doing the task, or ask Claude to read it as someone unfamiliar with the process would and flag anything undefined. Both surface gaps that are invisible once you already know the process.
Can Claude help keep an SOP consistent with a related policy document?
Keeping both in the same Claude Project, as described at support.claude.com's Projects help page, makes it easier to reference the policy while drafting and to check for drift between the two later.
What should an SOP say about when the task is finished?
State a clear endpoint: exactly what the task looks like when it's genuinely done. Without one, the reader is left guessing whether they've finished or missed a step that was supposed to come after the last one written.
How should I update an SOP after the real process changes?
Give Claude the existing SOP and describe what's different now, and ask it to call out exactly which steps changed. That helps people who memorized the old version notice what's actually different instead of relearning the whole document.
Who should review a draft SOP before it's published?
Someone who's never done the task, if possible. Where they hesitate or ask what to do next is a more reliable signal of a real gap than your own re-read, since you can't read it the way someone unfamiliar with the process does.
An SOP only works if someone new can actually follow it
The structure is reusable every time. Walking through the real process, including the parts you'd normally skip, is the part worth doing right.