Home / SOPs & Documentation
01 · SOPs & Documentation

How to Write an SOP People Actually Follow

The Ops Manual · Updated 2026-07-18

Most SOPs are written once, filed somewhere sensible, and never opened again. The problem is rarely laziness. It's that the document was written for an auditor's shelf instead of a person mid-task. Here's the process that produces the other kind.

Before you write anything

Scope the SOP to one task with a clear start and finish — "issue a customer invoice", not "accounts". If the draft grows past two pages of steps, you're probably documenting two or three tasks; split them.

Then decide who it's for. An SOP for a trained technician can say "flush the system"; one for a fresh admin hire has to say which screen, which button, which file name. Write for the least experienced person who will realistically do the task.

The writing process

  1. Do the task and narrate it. The person who actually does the job walks through it for real — not from memory — while someone captures every step, click and decision. Memory smooths over the tricky bits; the walkthrough exposes them.
  2. Write the steps as commands. Start each step with a verb: "Open…", "Check…", "Send…". One action per step. If a step contains "and", it's usually two steps.
  3. Capture decisions as forks. Where the path branches ("if the client is on a retainer…"), write the condition and both branches explicitly. Unwritten decision points are where procedures quietly fail.
  4. State the finish line. Every SOP ends with what "done" looks like and any handoff: what gets filed, who gets told, what the record should show.
  5. Test it on someone who has never done the task. Sit on your hands while they follow it. Every question they ask is a missing step; every hesitation is an unclear one. Fix the document, not the person.
  6. Name an owner and a review date. One person is responsible for the SOP being true. Put a review cycle on it — even annually — so drift gets caught deliberately instead of during a crisis.
Common failure: writing the SOP from how the task should work rather than how it does. If the documented process and the real process differ, staff follow the real one and learn to ignore your documents in general.

Format: boring is a feature

Use the same skeleton every time — purpose, scope, owner, steps, exceptions, revision history. People stop reading documents that make them re-learn the layout each time. Keep sentences short. Use screenshots only where the interface is genuinely confusing; every screenshot is something else that goes stale.

In practice: the most-followed SOPs in small businesses are ugly. A tight, current, one-page procedure in a shared drive beats a beautiful out-of-date one in specialist software every single week.

Keeping it alive

An SOP earns trust by being right. Protect that:

  • Store every SOP in one agreed location — a single source of truth, linked from wherever work happens.
  • When someone finds a step that's wrong, the fix is part of the job, not a favour: they flag it or fix it that day.
  • When the process changes, the SOP changes in the same week — updating documentation is the last step of changing any process.
  • Review each SOP on its cycle, and retire the ones for tasks you no longer do. A graveyard of dead procedures buries the live ones.

For tasks with regulatory edges — payroll, leave, safety, privacy — link the current official guidance from the Fair Work Ombudsman, the ATO or the Office of the Australian Information Commissioner inside the SOP rather than copying figures into it. Rules change; your document shouldn't have to.

Official sources