How to Write an SOP in 2026 (Step-by-Step, With Examples)

The biggest mistake first-time SOP writers make is picking a topic that's too broad — 'onboarding a customer' instead of 'sending the day-one welcome email'. Broad topics produce SOPs no one reads because they're too long to skim and too shallow to be useful in a specific moment. Pick a task that has a clear trigger ('a new signup arrives'), a clear done state ('the welcome email is sent and logged in the CRM'), and takes between 2 and 30 minutes end-to-end.

This is where 2026 tooling changes the economics. Open a tool like Haiku, Scribe, or Tango, hit record, and complete the task normally. The tool captures every click and keystroke, takes a screenshot at each meaningful step, and generates a titled, numbered draft in seconds. This is much faster than the old workflow of writing text first and taking screenshots later, and it produces more accurate SOPs because the recording *is* the ground truth.

If your task spans browser and desktop apps (say, downloading a report and processing it in Excel), pick a tool with native desktop capture. Haiku handles both; Scribe is browser-only on lower tiers.

AI-generated step titles are usually 80% right and 20% too generic. A step labelled 'Click the button' should become 'Approve the refund'. Rewrite titles for intent, not mechanics. Merge trivial steps ('scroll down', 'hover over icon') into the real action. Add a one-line 'why' underneath any step whose purpose isn't obvious from the screenshot.

• Rewrite generic titles for intent.
• Merge trivial mechanical steps.
• Add a one-line 'why' where intent isn't obvious.
• Blur any customer data or credentials in screenshots.
• Add short voice narration for the tricky steps if your tool supports it.

These four fields are what separate an SOP from a screen recording with captions. Trigger tells the reader when to run this SOP. Owner tells them who to bug if it's wrong. Escalation tells them what to do when reality doesn't match the doc. Last-updated tells them whether to trust it at all. Most SOP tools have fields or a template block for these; if yours doesn't, add them as the first paragraph.

Hand the SOP to someone who has never done the task and watch (silently) as they attempt it. Every time they hesitate, ask a clarifying question, or make a wrong click, mark the corresponding step. Those are your missing pieces. This 10-minute test catches more issues than any amount of self-review.

Publish the SOP to whichever knowledge surface your team actually uses — a wiki, Notion, Confluence, or the SOP tool's own hosting. Link to it from the tools where the work happens, not just from a folder. Then schedule a quarterly review with the owner. Without a scheduled review, expect the SOP to be outdated within a year and worse than nothing within two.