How to write standard operating procedures that actually get used

Executive overview

Most SOPs fail because they are too long, cover the wrong topics, or lack clear ownership. A good SOP is a bite-sized, written instruction set — like MapQuest directions for a specific destination you visit often.

The seven-step method produces a usable SOP in 15 minutes or less by focusing on start, stop, key steps, purpose, inputs, outputs, and continuous improvement.

Keep SOPs under eight steps, modular, and owned by the person doing the work.

Choosing the right topics and owner

• Write SOPs only for tasks done repeatedly — not every possible scenario.
• Title each SOP as "How to [action]" to keep scope tight.
• Assign two roles: a subject matter expert (strategy) and an owner (writes and maintains it).
• The owner should be the person who does the task long-term.
• New hires writing SOPs in their first 90 days is an effective onboarding method.

Capturing the procedure (steps 4–5)

• Define the start: what triggers the process.
• Define the stop: the last action that signals completion.
• Fill in only the key steps between start and stop — aim for fewer than eight.
• Write each step as a mini result (an outcome), not an activity description.
• Keep SOPs modular: one SOP per discrete task, not one mega-SOP per large goal.
• Large processes (e.g. "how to create a video") become a collection of small, combinable SOPs.

Purpose, inputs, and outputs (step 5)

• Purpose: one sentence on why this process exists.
• Inputs: resources, software access, or files needed before starting.
• Outputs: what success looks like — measurable and qualitative.

Adding detail and FAQs (step 6)

• Give yourself five minutes maximum to add detail under each step.
• Link, screenshot, or note only what is genuinely needed to avoid confusion.
• Leave the FAQ section blank or very short on the first draft — add to it over time.
• Resist over-engineering: gaps are filled iteratively, not upfront.

Using and improving SOPs (step 7)

• Use the SOP alongside the actual task on first run — compare what you do vs. what it says.
• Give team members permission to edit, not just comment.
• Innovation at the task level (e.g. using AI to speed up a step) should come from the person doing the work.
• Version history in tools like Google Docs, ClickUp, or Notion protects against over-eager edits.