Most standard operating procedures fail the same way: they are written once, in a burst, by someone who half-remembers the process, and then never opened again. The goal is not to have an SOP. It is to write one your team reaches for.
Start with the person doing the work
The knowledge you need is almost never in someone's head as a tidy list — it is in their hands. So watch them do it, or talk them through it step by step. Capture the real process, including the "oh, and if this happens, we do that" parts. Those exceptions are usually where things go wrong, which makes them the most valuable thing to write down.
One action per step
An SOP is not an essay. Each step should be a single, concrete action, in the order it happens, starting with a verb. "Check", "Send", "Approve", "Record". If a step has three things buried in it, it is really three steps.
- Number the steps in the true order of the work.
- Say who does each step, if more than one person is involved.
- Show what "done" looks like for each one.
Show the decisions, not just the steps
Real processes branch. The moment a step is "it depends", make the decision explicit: if this, then that; otherwise, the other. A small decision point on the page saves a dozen "quick questions" later, and it is exactly the part people forget when they document from memory.
Keep it somewhere it stays alive
The best SOP still rots if it lives in a PDF no one can edit. Keep it in a format your team can update — and give it an owner and a version. A procedure that is easy to change is a procedure that stays true, which is the only kind anyone trusts.
Want your process captured properly? See the process & SOPs service or start a project.