# Operations Sop Authoring

> Writes and versions a standard operating procedure that a competent new person can execute unaided — scope, role prerequisites, numbered steps with decision points, exception handling, escalation, and a controlled version block with owner, effective date, and review cycle. Use when documenting a repeatable business process or revising an existing SOP; trigger on 'write an SOP', 'document this process', 'we need a runbook for X', 'update the procedure', 'this process only lives in one person's head'. Not for drawing the cross-team flow of a process (use operations-process-mapping), not for a one-off product requirement (use product-requirements-doc), and not for a technical change or deployment procedure (use it-change-management).

- Skill: `alihusains/operations-sop-authoring` (Agent Skill)
- Install (CLI): `npx skillmds@latest add alihusains/operations-sop-authoring`
- Raw SKILL.md: https://api.skillmd.com/api/skills/alihusains/operations-sop-authoring/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: alihusains (https://skillmd.com/u/alihusains)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/alihusains/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

| Section | Contents |
| --- | --- |
| Version block | Version number, owner, approver, effective date, next review date, classification, change summary |
| Purpose | What the process achieves and why it exists |
| Scope | What is in, what is explicitly out, and which SOP covers the out cases |
| Roles | Each role, what it does here, and the access or authority it needs |
| Prerequisites | Access, tools, training, and inputs needed before step 1 |
| Procedure | Numbered steps, one action each, with decision points as a table |
| Exceptions | The known non-standard cases and how each is handled |
| Escalation | Trigger, who to contact, expected response time, and the fallback |
| Records | What must be recorded, where, and for how long |
| Related documents | Upstream and downstream SOPs, policies, and forms |
| Revision history | Every version, date, author, and what changed |

## 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

| Change | Version step | Requires re-approval | Requires re-communication |
| --- | --- | --- | --- |
| Typo, formatting, link fix | Minor (1.0 → 1.1) | No | No |
| Clarified wording, same behaviour | Minor | Process owner only | In the next routine update |
| Changed step order, new step, changed decision rule | Major (1.x → 2.0) | Yes | Yes, before the effective date |
| Changed control, approval threshold, or regulated handling | Major | Yes, including compliance or risk | Yes, with training where required |
| Process retired | Final version marked superseded | Yes | Yes, naming the replacement |

## 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.