Operations Sop Authoring

SOP Authoring and Versioning

Purpose

Processes documented from memory encode the author's assumptions and omit the exceptions that make up most of the real work. This skill produces an SOP written from observation, with the decision points and exceptions made explicit, and puts it under version control with an owner and a review date so it does not silently rot into a document people know is wrong and route around.

Prerequisites

• Inputs: the process name, its trigger, its end state, the roles who perform it, and access to someone who currently performs it.
• Access: the systems the process touches, at least to observe; any regulatory or policy requirements that constrain it; the existing SOP if one exists.
• Required: a named process owner with the authority to approve the SOP. An SOP with no owner cannot be maintained and should not be published.

If the only source is a description from a manager who does not perform the process, say so and observe an actual execution before writing. Second-hand process documentation is where the exceptions go missing.

Data classification

Classify the SOP itself, and state it in the version block. Internal for most; Confidential where it exposes control design, fraud detection logic, security procedures, or handling of regulated data. Never embed credentials, tokens, API keys, internal hostnames, or personal data in an SOP — reference the credential store or access request procedure by name instead. Where a step handles personal or financial data, state the classification of that data and the retention rule at the step. If a contributor pastes real customer records as an example, replace them with synthetic values before publication.

Required structure

Procedure

1. Observe the process being performed end to end before writing, and note every point where the performer made a judgement, checked something not in any instruction, or handled an exception. These are the content; the happy path is usually already known.

2. Define scope by naming the out-of-scope cases and where they go instead. "Applies to standard requests" without defining standard is the boundary failure that generates most misrouted work.

3. Write steps as single actions in the imperative, each starting with a verb, each with an unambiguous completion state. If a step contains "and", it is probably two steps. If it contains "if", it is a decision point — move it into the table in step 4.

4. Express every decision as a table, not prose:

   Condition	Action	Next step
   Condition A holds	Do X	Step 7
   Condition B holds	Do Y	Step 9
   Neither holds	Escalate per the escalation section	Stop

   Prose conditionals with two or more variables are misread reliably. The last row matters most: every decision table needs a defined path for the case that matches nothing.

5. State the acceptance condition per step where correctness is not obvious — what the performer should see to know the step succeeded. Steps that can fail silently need this or they will be reported as done when they were not.

6. Document the exceptions found in step 1, each with its trigger, its handling, who may authorise it, and whether it must be recorded. An SOP without an exceptions section is either incomplete or describes a process nobody actually follows.

7. Write the escalation path with names by role, response expectations, and a fallback if the first contact is unavailable. Escalation paths that name a single individual break when that individual is on leave.

8. Specify records and retention per step where records are created: what is recorded, in which system, by whom, and for how long. This is where audit findings originate.

9. Test the SOP with someone who has not performed the process. Watch them execute it without asking questions. Every question they need to ask is a defect; fix it before publication. This test is the whole quality gate — an SOP reviewed only by people who already know the process passes trivially.

10. Complete the version block and get approval. Approval is by the process owner, plus compliance or risk where the process is regulated or a control. Record names and dates.

11. Publish to a single controlled location and retire the previous version. Two live copies means one wrong copy. Where local copies exist, state in the version block that only the controlled location is authoritative.

12. Set the review cycle and the event triggers. Annual review at minimum; immediate review when the system changes, the regulation changes, the process fails, or an exception recurs often enough to be a standard case. Put the next review date in the version block, not in someone's calendar.

Versioning rules

Failure modes

• Written from memory. Produces a happy path with the exceptions missing.
• Prose decision logic. Multi-condition rules in sentences get misapplied.
• Unowned document. Nobody updates it, and within a year everyone routes around it while it remains formally in force — the worst state to be audited in.
• No exceptions section, so every non-standard case becomes an ad-hoc decision with no record.
• Multiple published copies with different version numbers.
• Credentials or personal data embedded in steps or screenshots.
• Review date set and never actioned. Attach it to a scheduled control, not to goodwill.

Boundaries

• Drawing the cross-role or cross-team flow of a process before documenting it — use operations-process-mapping.
• Technical change, release, or deployment procedures — use it-change-management.
• Product requirements for something being built — use product-requirements-doc.
• Organisation-level policy setting rules rather than steps — an SOP implements a policy; it does not replace one.

Hand-offs

• Receives from: operations-process-mapping (the mapped flow, handoffs, and decision points that become the numbered steps), engineering-incident-postmortem and sales-proposal-assembly debriefs (process fixes identified after failure).
• Routes to: operations-process-mapping when the process crosses several teams and the flow is unclear, it-change-management for the technical portions, and operations-vendor-evaluation where a step depends on selecting a supplier.