BW-201c · Module 2

SOPs and Process Docs — Writing Procedures People Will Actually Follow

4 min read

A Standard Operating Procedure is the most specific form of process documentation — it describes exactly how to perform a specific task, in a specific context, to a specific standard. The discipline of writing SOPs is the discipline of knowing the difference between what must be specified (the steps that, if done incorrectly or inconsistently, produce bad outcomes) and what can be left to practitioner judgment (the steps where variation is acceptable or even desirable).

Most SOPs fail not because they are inaccurate but because they are written at the wrong level of specificity. The SOP that is too high-level tells the practitioner what to do without telling them how to do it — it is a process description masquerading as a procedure. The SOP that is too granular tells the practitioner how to breathe while performing a task that every competent practitioner already knows how to do — it is an insult masquerading as documentation. The craft is calibration.

Do This

  • Specify every step where incorrect execution produces a meaningfully different outcome
  • Include the verification step after each critical action — how does the practitioner know they did it correctly?
  • Write SOPs from the practitioner's perspective, in the second person: "You will..." or "Select..."
  • Include the exceptions — what to do when the standard path is not available

Avoid This

  • Write SOPs at the process level ("complete the data entry phase") without the procedural detail
  • Specify steps where practitioner judgment is both appropriate and more effective than a rule
  • Write SOPs from the system's perspective ("the user should...") rather than the practitioner's
  • Omit the error state — what happens when something goes wrong, and what to do about it

The format for SOPs is more constrained than other documentation forms. Numbered steps, in sequence, with verification checkpoints at critical junctures. No prose paragraphs that require the practitioner to extract the steps — the steps should be immediately visible. Each step should begin with an action verb: Click, Select, Enter, Verify, Escalate. The practitioner following an SOP is not reading for understanding. They are following instructions. Design for following, not for understanding.

A specific note on verification steps: every critical action in an SOP should be followed by a verification step that tells the practitioner how to confirm the action was successful. 'Click Submit.' is a step. 'Click Submit. Verify that the confirmation screen displays the transaction ID before proceeding.' is a procedure. The verification step catches errors at the point where they can still be corrected — before they propagate through the rest of the process.

SOPs should be validated, not merely reviewed. The distinction: a review is a subject-matter expert reading the SOP and confirming it is accurate. A validation is a practitioner following the SOP step-by-step in the actual operating environment and confirming it produces the intended outcome. Reviews catch content errors. Validations catch procedural gaps — the steps that are accurate in isolation but create confusion in sequence, the verification criteria that do not match what the practitioner actually sees on the screen. Validate before you publish.