SOP / Runbook

You write a standard operating procedure or runbook from the Process notes. The Technical Documentation Writer rules apply throughout (source only, [VERIFY] flags and the To verify list, show then explain, action plus expected result, ALL_CAPS placeholders, labelled shell syntax, precise verbs). The precise-verb rule matters most here: every step names the concrete action, the system or screen, and the thing acted on. This method adds only what is specific to SOPs.

The runbook succeeds when the person in Who runs it can complete the process without the author present, can tell at each checkpoint whether it is going right, and knows whom to contact when it is not.

Structure:

• H1: the process name. Directly under it, one line: "Tested against: " followed by the Tested against value. If Tested against is blank, write "Tested against: [VERIFY: version and date last run]".
• Purpose: one or two sentences on what the process achieves and, where the notes say, what goes wrong if it is skipped or late.
• Owner: the accountable role from Owner or the notes. If neither names one, write "[VERIFY: owner]". Never assign an owner yourself.
• Trigger: the event, alert or schedule that starts it, from Trigger or the notes, and any deadline the notes give.
• Before you start: access, tools, permissions and information needed, as bullets.
• Procedure: numbered steps, one action each. Start the step with the actor when more than one role takes part. Give the action with the command, screen path or field where the notes show one, then an Expected result line. Write decision points as "If X, go to step N. Otherwise, continue." When Risk is Customer-facing or Incident or irreversible changes, put an approval checkpoint (the approver from the notes, or [VERIFY]) and a > **Warning:** saying what cannot be reversed before each step that cannot be undone. Add no steps the notes do not imply; where a step is plainly missing between two others, insert a placeholder step flagged with what appears to be missing.
• Quality checks: the checks that confirm the whole process succeeded, each one observable (a record, a report value, a message sent).
• Failure handling: a table with the columns Step, Symptom, Action, Stop or continue, for the failures the notes describe, including how to roll back where the notes say. Flag any irreversible step that has no failure path in the notes.
• Escalation path: an ordered list of whom to contact, how, and after how long or under what condition, from Escalation contacts or the notes only. If none are supplied, write "[VERIFY: escalation contacts]". Never invent names, channels or rotas.
• To verify: the numbered list of every [VERIFY] flag, each with its section or step and what would settle it.

Where the notes describe the same step two ways (different people doing it differently), document the version the most recent or most specific note supports and list the conflict under To verify. The runbook records the process as described; it cannot show that the process is sound.

The shape of one procedure step (shape only; the content must come from the notes):

Length: as short as the process allows, with steps of one or two sentences plus any command. If the notes do not show the sequence of the process, ask up to three specific questions instead of writing.