How to Write SOPs with Claude

The structure of a good SOP

Purpose — the one or two sentences that say what the procedure achieves and why it exists.
Scope — which situations, products, or teams it covers, and what it deliberately leaves out.
Roles & responsibilities — who performs each step and who to escalate to when something goes wrong.
Prerequisites — access, tools, or information someone needs before they start.
Numbered steps — one action per step, written so a new hire could follow it without asking a question.
Exceptions & escalation — what to do when a step does not apply or something breaks.
Revision history — when it last changed and why, so readers can trust it is current.

Write it step by step with Claude

Purpose and scope — “Interview me about how we handle [process] and draft the purpose and scope for an SOP from my answers.”
Steps — “Turn these notes into numbered steps, one clear action per step.”
Roles — “Add a roles and responsibilities section: [team] does the steps, [role] approves exceptions.”
Exceptions — “Add an exceptions and escalation section covering what happens if [edge case].”
Tightening — “Read this SOP as a new hire would and flag any step that is ambiguous.”

Review and approval

Ask Claude to draft the SOP as a page and leave it unpublished until it has been reviewed — for example, “publish this SOP for the Operations team, unpublished until it’s approved.” Share the page with the people who need to sign off, and have them comment or edit directly in OpenDocs.

Regulated teams need more than a review by email. The Compliance plan adds an approval step, so a page can require a reviewer to sign off before it publishes, and read acknowledgments, so a reader has to confirm they read the current version. Together they give you a record that an SOP was reviewed before it went live and read by the people it applies to.

Publish it and keep it current

Once it is approved, ask Claude to publish the page to the right space. Every later edit, by a person or by Claude, is saved as a page revision, so you always have a trail of what changed in an SOP and when.

SOPs drift out of date quietly. Periodically ask Claude to compare the published SOP against how the team actually works today — for example, “compare the published [SOP name] page to what I just described and flag anything that’s changed” — so drift gets caught in a five-minute check instead of during an audit.

Frequently asked questions

Can Claude write an entire SOP from scratch?

Yes, but the result is better if you give Claude the real steps first, for example by pasting notes or asking it to interview you about the process. Claude is strongest at structuring, tightening, and formatting a process you already know, not inventing one from nothing.

How do I make sure people actually follow the SOP once it's published?

Publish it to a space your team already reads. On the Compliance plan you can also require a read acknowledgment, so a reader confirms they read the current version, and require approval before a change goes live.

What does the Compliance plan add for SOPs?

The Compliance plan adds an approval step, so a page can require a reviewer to sign off before it publishes, and read acknowledgments, so readers confirm they read the current version. That suits regulated teams that need proof an SOP was reviewed and read.

How often should I update an SOP?

Update it whenever the underlying process changes, and periodically ask Claude to compare the published SOP against how the team actually works today, so drift gets caught early rather than during an audit.