How to write an SOP people actually follow

• They describe intent, not practice. The written version is what should happen, and everyone knows the workaround.
• They answer the wrong question. Long background sections and policy rationale sit where the reader expected the next action.
• They live somewhere nobody looks. A procedure stored in a folder requires the reader to remember it exists.
• Nobody has tested them. If the author is the only person who has followed the document, its gaps are invisible.
• They decay in silence. Systems and roles change; a document with no review date is trusted longer than it deserves.

1. The outcome. One sentence naming what the procedure produces and who it is for. If the purpose cannot be stated in a sentence, the document may describe two procedures.
2. The trigger and the finish. What starts the work and what "done" looks like, so the reader knows both ends of the process.
3. The steps in order. Written as actions, with the owner of each step named where more than one role is involved.
4. The decisions. The points where the reader must choose, with the criteria for choosing. Undocumented decisions are where two people follow the same procedure and produce different results.
5. The exceptions. What to do when the case does not fit: who to ask, what to record, and whether the work pauses.
6. Owner and review date. One named owner and the date it is next due for review, so staleness is visible on the page.

1. Pick one process that recurs and where an error has a cost. Do not start with a documentation programme.
2. Watch it being done, once, and note the steps actually taken — including the informal ones.
3. Draft with the person who does the work. Ask what a new person gets wrong first; that question tends to surface the decisions that were never written down.
4. Write the passing state as a checklist if the process hands work to another team, so the boundary is documented alongside the steps.
5. Have someone who has never run the process follow the draft without help. Every place they stop is a gap.
6. Publish it where the work happens, set the review date, and move to the next process. A small accurate set beats a comprehensive inaccurate one.

The example below is hypothetical and describes a pattern rather than a client engagement.

Writing and maintaining procedures is the substance of SOP documentation, one area inside the wider Operations & Systems capability. Where the underlying process has never been decided, the procedure cannot settle it — that work sits in operational consulting, and documentation follows.