SOP Writer

name: sop-writer
description: Converts a described process into a standard operating procedure through structured interviewing, capturing steps, exceptions, controls and escalation paths. Use when the user wants to document a process, write an SOP or runbook or capture how a task is done.

Most operational risk at an investment firm lives in processes that exist only in one person's head. The wire release, the capital call, the month-end NAV checklist, the trade-break resolution. A COO's test for an SOP is simple: could a competent new hire execute this correctly on day one and would a reviewer catch it if they didn't? Interview the process owner and produce a document that passes both halves of that test.

Inputs

• A description of the process, in any state. A rough brain dump, an old checklist, a transcript of someone explaining it. Anything.
• Any existing documentation, emails or screenshots about the process.

Workflow

1. Interview in structured rounds. Read what was provided, then ask what is missing. In batches of three to five questions, not one long interrogation. Two or three rounds is typical. Cover, in order:

• Trigger: what starts the process: a schedule, an event, a request? Who notices?
• Systems and access: every system touched and what permission level each step needs. "Log into the admin portal" is a step someone new cannot do without knowing which portal and who grants access.
• The real steps: walk through the most recent actual execution, not the idealized version. Useful probes: "What did you actually do last Tuesday?" / "Where do you usually have to wait for someone?" / "Which step do you double-check because it's bitten you before?" The gap between the described process and the last real execution is where the SOP's value is.
• Handoffs: where another person or team takes over, how they are notified and what happens if they are out.
• Exceptions: what goes wrong, roughly how often and what the operator actually does about each.
• Controls: the checks that catch errors: reconciliations, four-eyes review, system validations. For each control, who performs it and what evidence it leaves.
• Escalation: the specific conditions under which the operator should stop and call someone and whom, in what order.

2. Draft the SOP in the format below. Steps follow the one-action rule: one actor, one action, one system per step. A step that says "prepare and send the capital call notice after review" is three steps.

Example of correct granularity: 12. Preparer: export the capital call schedule from the fund admin portal (Investran > Reports > Capital Calls) as PDF. 13. Preparer: compare each LP's call amount against the allocation model (shared drive > Fund III > Capital Calls). Any variance: stop, see Exceptions E-2. 14. Reviewer (not the preparer): confirm wire instructions against the standing-instructions file. Never against instructions in the email thread.

3. Mark what you could not learn. Where the user could not answer, insert "[OPEN. Confirm with owner]" rather than a plausible guess. An SOP with visible open items is a working document; one with invented steps is a liability.

4. Offer the day-one read-back. Read the draft as a brand-new hire would and list what would still confuse them. Undefined jargon, steps assuming unstated knowledge, missing screenshots. Note where screenshots matter with "[insert screenshot]".

SOP format

1. Purpose and scope (two or three sentences, including what this SOP does NOT cover)
2. Owner and backup, by role
3. Trigger and frequency
4. Systems and access required (system, what it is used for, who grants access)
5. Procedure. Numbered steps per the one-action rule, with the actor named on each step
6. Exceptions. Numbered E-1, E-2... Each with its handling, referenced from the steps where they occur
7. Controls. What is checked, by whom, when and what evidence is retained
8. Escalation. Conditions and contacts, in order
9. Version, author, approval and next review date

Findings to surface alongside the draft

• Key-person risk: any step only one person can perform, flagged individually
• Control gaps: any irreversible action (wires, trade releases, external sends) with no independent check before it and any step where the preparer reviews their own work
• Undocumented dependencies: spreadsheets, personal email folders or individual logins the process silently relies on

Guardrails

• Never fabricate a step, system name or control to make the document look complete.
• Real executions beat idealized descriptions. Anchor the steps to the walkthrough.
• Keep the SOP as short as correctness allows; a procedure nobody reads protects nobody.