Skip to content

Published 31 August 2026

  • operations
  • processes

Writing a one-page SOP your staff will actually follow

Why most standard operating procedures fail, the one-page structure that works, and how to test one.

Writing a one-page SOP your staff will actually follow

Why most SOPs fail

Most small businesses in Hong Kong have at least one SOP document sitting somewhere, usually a multi-page file that nobody has opened since the week it was written. Three things usually explain why it did not stick.

It was too long. A ten-page procedure asks a busy staff member to stop mid-shift and read like it is a manual, when what they actually need is an answer to "what do I do right now."

It was written by the wrong person. Owners and managers often write the procedure from how they imagine the work happens, rather than from how the person actually doing it handles the awkward cases — the customer who does not fit the usual pattern, the supplier who is late, the step that only makes sense once you have done it wrong once.

It was never tested. A document that reads clearly to the person who wrote it can be genuinely confusing to someone encountering the task for the first time, and the only way to find that out is to watch someone try to follow it.

The one-page structure

A procedure that actually gets used fits on one page and has six parts.

  1. Purpose, in one sentence. What this procedure achieves and why it matters — enough for someone to understand the point without reading further.
  2. Who does it. The role responsible, not a named individual, so the procedure survives staff changes.
  3. Trigger. The specific event that starts the procedure — a new enquiry arrives, a delivery is due, a shift ends. Vague triggers ("when needed") produce inconsistent timing.
  4. Numbered steps. Short, concrete actions in the order they actually happen. Five to nine steps is a reasonable range; if you need more than that, the task may need splitting into two procedures.
  5. What "done" looks like. A clear, checkable end state, so the person doing the task knows when to stop and the next person knows they can rely on it being finished.
  6. Exceptions and who to ask. The two or three situations that come up often enough to name, and exactly who to go to when the situation does not fit the steps above.

This structure resists bloat by design. If a new sub-step does not obviously belong in one of these six parts, it usually belongs in a separate procedure rather than bolted onto this one.

Write it with the person who does the job

The most reliable way to write an accurate one-page SOP is to sit with the person who does the task and write down what they actually do, in their own words, rather than what you assume they do. Ask them to walk through it as if they were doing it right now, and write down the real order of steps, including the ones that feel too obvious to mention — those are often exactly the steps a new hire will miss.

This also does something beyond accuracy: a procedure written with someone, rather than handed to them, tends to get followed. People are more likely to trust and use a document they recognise their own work in.

Test it by having someone new follow it

Before you trust a procedure, hand it to someone who has never done the task — a new hire, or a colleague from a different part of the business — and watch them try to follow it without help. Every point where they hesitate, ask a question, or do something different from what you intended is a gap in the document, not a failure on their part.

This is the step most owners skip, because it takes twenty minutes and feels like an unnecessary formality. It is the single most effective way to find the parts of a procedure that only make sense inside your own head.

A review date, and where to keep it

Give every SOP a review date — six or twelve months out is reasonable for most procedures — so it gets revisited on purpose rather than drifting out of date silently while everyone keeps following the old version anyway.

Keep the document where the person doing the task will actually find it in the moment they need it: pinned near the relevant workstation, in a shared folder named for the task rather than buried in a generic "policies" folder, or wherever your team already looks when something comes up. A perfectly written SOP that nobody can find when they need it delivers exactly the same result as no SOP at all.

All insights