How to Write SOPs Your Team Will Actually Use

Why most SOPs never get opened

Most standard operating procedures fail for a boring reason: they were written to look thorough rather than to be used. A twelve-page document with headers, sub-headers and a table of contents feels professional when you're writing it, but nobody opens a twelve-page document to find out how to process a refund while a customer is waiting on the phone. They ask a colleague instead, and the document quietly stops mattering.

The second common failure is writing the procedure from memory of how the task used to be done, rather than watching or asking the person who does it now. Processes drift in small, unrecorded ways — a new supplier, a workaround for a software quirk, a step someone added after a near-miss. A procedure written from memory documents the past, not the present, and the first time someone follows it exactly and it doesn't work, they stop trusting every SOP you've written.

The fix for both problems is the same: keep the document short enough to be read in under a minute, and write it with the person actually doing the work today, not from what you assume they do.

The single-screen SOP format

A workable SOP fits on one screen without scrolling, and always contains the same seven elements in the same order, so people learn the shape and can scan it fast under pressure. Consistency of format matters more than any individual field — someone reading their fifth SOP from your business should already know where to look for the trigger and where to look for the steps.

1. Purpose — one sentence: why this procedure exists and what it protects against if skipped
2. Trigger — the exact event that starts this procedure ('a customer emails asking for a refund')
3. Steps — numbered, written as actions, in the order they actually happen, not the order that seems logical
4. Tools and access needed — the specific systems, logins or physical items required to complete it
5. Definition of done — the one-line check that confirms the task is actually finished, not just attempted
6. Owner — the named person responsible for keeping this procedure accurate
7. Review date — when this gets checked again, regardless of whether anything seems to have changed

If you can't fit the steps on one screen, the task is probably two procedures pretending to be one. Split it.

Writing steps people will actually follow

Write each step as an action with a verb at the start — 'open the refunds tab', 'check the order date against the returns policy', 'issue the refund via Stripe' — rather than a description of the system. Descriptions read like documentation; actions read like instructions, and instructions get followed under time pressure.

Be specific about judgement calls rather than glossing over them. If a step involves a decision — refund or not, escalate or not — say what the decision criteria actually are, and state clearly whether the person doing the task has the authority to make that call alone or needs to check first. An SOP that hides a judgement call inside a vague instruction like 'use discretion' is not actually a procedure; it's a suggestion that someone else has to interpret differently every time.

Where a step is genuinely complicated — a multi-screen software workflow, for instance — link to a short screen recording or a reference document rather than trying to describe every click in text. Text is good for sequence and judgement; screen recordings are better for exact software navigation.

Building SOPs with the person doing the work

The most reliable way to capture an accurate procedure is to have the person who does the task write the first draft, or narrate it to you step by step while you write it down, rather than you writing it from what you assume happens. This surfaces workarounds and judgement calls that never made it into any previous documentation because they became habit rather than instruction.

If the task is entirely in your own head and nobody else does it yet, write it the next time you do it yourself, taking notes at each step rather than relying on memory afterwards. Trying to reconstruct a procedure from memory after the fact reliably misses steps that have become automatic to you.

Once a draft exists, have a different person — ideally someone new to the task, or at least new to this specific procedure — try to follow it exactly as written, with no help. Anywhere they get stuck or have to guess is a gap in the document, not a failure on their part, and it should be fixed before the SOP is treated as finished.

Where SOPs should live

An SOP that lives somewhere people don't naturally look is the same as no SOP at all. Store procedures as close as possible to where the work happens: in the tool being used if it supports notes or pinned documents, in a shared drive folder structured by task rather than by department, or in a lightweight knowledge base linked directly from the relevant tool.

Avoid burying procedures inside long onboarding documents, old email threads, or a founder's personal notes app. If someone has to ask you where to find a procedure, the storage location has already failed, regardless of how good the document itself is.

• Group SOPs by the task or role they support, not by an internal department structure nobody outside the founder understands
• Make the folder or index the very first thing a new starter is shown, before anything else
• Pin frequently used SOPs somewhere more visible than a general folder — a shared channel or a bookmarked page
• Keep a single master index, even a simple spreadsheet, listing every SOP, its owner and its review date

Keeping SOPs from going stale

A procedure that was accurate a year ago and hasn't been checked since is a liability, not an asset, because people trust it by default and only discover it's wrong when something goes wrong following it. Every SOP needs a named owner — the person accountable for its accuracy, not necessarily the person who does the task most often — and a review date that triggers a check regardless of whether anyone has flagged a problem.

The most reliable moment to update a procedure is the moment the process actually changes, not at an annual review. Build a habit of treating 'we changed how we do X' as automatically including 'update the SOP for X' as part of the same piece of work, rather than a separate task that gets deprioritised.

When you do run a scheduled review, the fastest check is to have someone follow the procedure exactly as written and flag anywhere it doesn't match reality. This catches drift far more reliably than simply re-reading the document, because re-reading tends to confirm what you already believe rather than test it.

Common mistakes when writing SOPs

A handful of habits reliably undermine SOPs even when the intent behind them is good.

• Writing procedures as prose paragraphs instead of numbered steps, which people skim rather than follow
• Documenting the ideal process rather than the one actually followed, including its legitimate workarounds
• Leaving out judgement calls entirely rather than stating the decision criteria and who owns the decision
• No named owner, so nobody feels responsible when the procedure is wrong
• No review date, so procedures rot silently until someone follows a wrong one and something breaks
• Storing SOPs somewhere only the founder remembers to check

Where to start if you have nothing documented yet

Do not attempt to document everything at once. Start with the five to ten questions you personally answer most often in a typical week — these are, by definition, the procedures with the highest immediate return on the time spent writing them, because they're already interrupting you regularly.

Write those first, in the single-screen format, with a named owner (which may be you initially, transferred to someone else once the task is delegated) and a review date three to six months out. Add new procedures steadily as new recurring questions surface, rather than trying to anticipate every process the business might ever need documented.