PairedOps · standard operating procedure
One process, written so someone else can run it
Fill this in while you watch the work happen, not from memory afterwards. If a step needs judgement, say so in section 05 rather than pretending it is mechanical, because that is the line between what an agent can carry and what the operator has to own.
01 · Why this exists
One sentence. What breaks in the business if this stops happening.
02 · Trigger and cadence
What starts it: a date, an event, a message, a threshold. And how often.
03 · Systems and access
Every system the process touches, and who can grant access to it. This is the section that holds up more handovers than any other.
| System | What it is used for | Access granted by |
|---|---|---|
04 · The steps
In order, in plain language, one action per line. Write what a competent stranger would need, not what you would need.
| # | Step | Where it happens | Person or agent |
|---|---|---|---|
| 01 | |||
| 02 | |||
| 03 | |||
| 04 | |||
| 05 | |||
| 06 | |||
| 07 | |||
| 08 |
05 · The decisions that need a human
Name the step, the call being made, and who makes it. Anything on this list is why the function has an owner rather than a script.
| At step | The decision | Made by | Needs client sign off |
|---|---|---|---|
06 · Exceptions
The cases that break the happy path, and what to do about each. If you cannot name three, the process has not been watched for long enough yet.
07 · What done looks like
The check that proves it worked, not the feeling that it did.
08 · Where it is recorded, and who to escalate to
The two rules that keep an SOP alive
Review it the first time it is wrong, not on a schedule. And keep the decisions section honest: the moment a judgement call gets written up as a mechanical step, the process starts producing work that nobody owns.
PairedOps · Human Ops + AI Ops · pairedops guides