How to Write SOPs Your Team Actually Follows

Every growing company eventually writes SOPs. Almost none of them get followed.

The failure is rarely the writing. It is that the document was produced as an artifact rather than as a tool — something to have, not something to use. A procedure nobody opens is indistinguishable from a procedure that does not exist.

Here is what separates the two.

Write for the person doing this at 6pm on a Friday

Your reader is not studying. They are mid-task, slightly rushed, and looking for one specific thing. Every decision about structure follows from that.

Lead with the action, not the context. "Raise a credit note" beats "Overview of the credit note process." Number the steps. Put the exception at the step where it happens, not in a preamble the reader skipped.

If a step requires judgement, say what the judgement is and who makes it. "Escalate if the value exceeds your approval limit" is useless without knowing the limit. "Escalate to the finance lead above ₹50,000" is a procedure.

One process, one page

A twelve-page document covering an entire department will not be read. Split it. Each SOP covers one process with one trigger and one end state.

If you cannot state the trigger in a sentence — "a customer asks for a refund", "a new hire accepts an offer" — the scope is wrong and the document is trying to be a manual.

Put it where the work happens

This is the single biggest determinant of whether an SOP gets used, and it has nothing to do with how well it is written.

An SOP in a shared drive folder is found by people who already know it exists. An SOP linked from the task where the work is done is found by everyone doing that work, at the moment they need it. The distance between the procedure and the point of use should be zero clicks.

The same applies to onboarding. A new hire should not be handed a folder. They should meet each procedure when they first hit the task it governs.

Give it an owner and a review date

An unowned document rots quietly. Someone changes the process, nobody updates the SOP, and six months later it is actively misleading — worse than nothing, because people follow it and get the wrong answer.

Every SOP needs a named owner and a date by which it will be checked. Not a vague commitment to keep things current; a date, on a specific person.

The other half of this is a route for corrections. The person who discovers the document is wrong is usually the person doing the task, and they need somewhere obvious to say so. If reporting a stale SOP takes more effort than working around it, everyone works around it.

Test it on someone who has never done the task

This is the cheapest quality check available and almost nobody does it.

Hand the SOP to someone unfamiliar with the process and watch them attempt it. Do not help. Every point where they hesitate is a gap — an unstated assumption, a missing threshold, a term only you use.

The author cannot see these gaps, because the author already knows the answer. A stranger finds them in ten minutes.

Keep a record of what changed

When a procedure changes, the change matters as much as the new version. Who changed it, when, and why. Six months later, when someone asks why the approval threshold moved, the answer should not be a guess.

This is also what turns SOPs from an internal convenience into something you can show an auditor, a client running due diligence, or a new operations lead trying to understand how the place works.

What good actually looks like

A short document with a clear trigger. Numbered steps written for someone in a hurry. Thresholds and decision rights stated explicitly. A named owner and a review date. Reachable from the task it governs, in one click or none. A visible history of changes.

None of this is difficult. It is just rarely done, because writing the document feels like the work — and the document was never the work. Getting it used is.

Start with your three highest-consequence processes: the ones where a mistake costs money, loses a customer, or creates a compliance problem. Write those properly. Leave the rest until someone asks.