Most SOPs fail before they're tested. The problem isn't the format — it's that they're written to be filed, not to be followed. A 12-page SOP that lives in a wiki gets consulted once and then ignored. A 6-step SOP embedded in the workflow tool gets executed every single time. The difference between an SOP that gets followed and one that doesn't is almost never the quality of the writing.
Start with the failure mode, not the process. Before writing any steps, ask: when this process breaks, where does it break? The answer tells you where the SOP needs to be most specific. If it breaks at the approval step — because nobody knows who approves, or approvals happen via Slack with no record — then the approval step needs more detail than the standard steps. If it breaks at handoffs — because the person completing step 3 doesn't notify the person responsible for step 4 — then handoff triggers need to be explicit.
Write for the role, not the person. 'Marcos will upload the document to the shared drive' is a bad SOP step. 'The Compliance Manager uploads the signed version to the audit folder before end of day on the deadline' is a good one. The difference: the second specifies a role (not a name), an action (upload the signed version), a destination (the audit folder), and a timing constraint (end of day on the deadline). Every SOP step should have all four elements.
Evidence is not a checkbox — it's a specification. The most important part of each SOP step is not the description of the action; it's the definition of what proof of completion looks like. 'Completed' is not a proof standard. 'Screenshot of the approval email attached to the task record' is. 'Signed document in the audit folder, filename [YYYY-MM-DD]-[control-name]-approved.pdf' is. Write the evidence standard before you write the step. The step should produce the evidence, not describe it.
Version your SOP from day one. Give it a version number (v1.0), a review date (not 'annually' — a specific date), and an owner (a role, not a person). When the SOP changes, increment the version, note what changed and why, and archive the previous version. In a compliance context, the version history of an SOP is itself an evidence artifact — it shows that the organization maintains and improves its standards, not just documents them once and forgets.
The sign that your SOP is working is not that people say they followed it — it's that the workflow records prove it. When every run of an SOP-backed workflow produces a timestamped record of who did what, when, with what evidence, you have a compliance program. When you're still asking people 'did you follow the process?', you have a documentation project.