How to Document SOPs and Runbooks

SOP and runbook documentation is the work of turning a process that lives in someone's head into a reference another person can follow. An SOP explains a business process with owners, handoffs, exceptions, and success measures. A runbook explains a repeatable operational procedure with prerequisites, exact steps, expected results, rollback, and escalation.

The difference matters because teams often document too late. A founder, ops lead, or senior engineer carries the real process in memory until onboarding, vacation, an incident, or a client handoff exposes the gap. A useful document preserves the messy reality of the process, then makes it specific enough that a new hire can run it without guessing.

Why undocumented process quietly costs you

Undocumented work creates hidden queues. People wait for the one person who knows the exception path. New hires ask the same questions. Client delivery depends on Slack memory. On-call work depends on who happened to be present last time the incident happened.

Bad documentation can be just as expensive. A vague SOP says "review the request" without naming who reviews it, what they check, or what happens when it fails. A vague runbook says "run the sync script" without the command, directory, expected output, verification step, rollback, or escalation path. The document exists, but the operator still needs the expert.

What the manual process looks like

Done by hand, documenting a process takes five passes:

1. Capture the current state from the person who runs it today, including rough notes, old docs, screenshots, and exceptions.
2. Choose the format: SOP for a business process with people and handoffs, runbook for an operational procedure with exact actions.
3. Map owners, inputs, outputs, decision points, waits, rework, and manual steps.
4. Draft the document to the right structure, then add every known exception and edge case.
5. Test the draft against the new-hire bar: could someone unfamiliar run this correctly on the first try?

The hard part is not formatting. The hard part is refusing to smooth over the messy parts, because those are usually the parts that make the document valuable.

What an agent can automate

An agent helps because the work is structured, repetitive, and checklist-heavy:

• Choose the right artifact. The agent decides whether the input should become an SOP or a runbook based on the job, not the title someone gave it.
• Map the current process. It turns notes into steps, owners, handoffs, inputs, outputs, decisions, waits, rework, and manual work.
• Preserve exceptions. It asks for and records the "usually X, but sometimes Y" paths instead of flattening the process into a clean but false happy path.
• Draft to the right template. SOPs get purpose, scope, RACI, process flow, detailed steps, exceptions, metrics, and related documents. Runbooks get purpose, prerequisites, exact procedure, expected results, failure branches, verification, troubleshooting, rollback, escalation, and history.
• Self-critique. The agent checks its own draft against the new-hire bar and revises vague steps, missing expected results, missing failure branches, and unowned handoffs before asking for approval.

The agent can also propose streamlining, but the proposal stays separate from the reference. A cleaner process that removes an important safeguard is worse than a clunky process the team can trust.

The guardrails that make it safe

Documentation changes can alter how a team works. That is why the approval gate matters. The agent can draft the SOP or runbook and propose before-and-after improvements, but it should not overwrite a live team reference or remove a safeguard without sign-off.

The other guardrail is specificity. Every step must have enough detail to run: exact commands, paths, values, expected results, and failure branches where relevant. If the agent cannot verify a decision or an exception, it should ask the human instead of guessing. The approval item should make those open questions visible.

Set it up in Task Machine

The SOP & runbook documenter playbook installs an Ops Agent, four documentation and process skills, the SOP documenting workflow, the goal that defines reliable references, and a follow-up to start the first documentation run. Setup takes a few minutes. You need a Task Machine workspace and permission to install playbooks (workspace owners have it). Document storage access is not required up front. Until it is connected, the agent works from attached exports and process notes.

1. Find the playbook

Open Playbooks in your workspace and search for "SOP" or "runbook", or browse the Operations category. The card shows that the playbook creates the ops agent, skills, goal, and workflow.

2. Preview what it installs

Preview & install opens the full contents before anything is created: the Ops Agent, process-doc, runbook, process-optimization, and documentation skills, the documenting workflow, the goal, and the start follow-up. Confirm that the workflow ends in approval before a draft becomes the team reference.

3. Define the process

Start setup asks for the process name, operators or teams, inputs and outputs, and exception paths. Name the process the way your team does. Add the people who run it today and the exceptions that usually derail handoffs.

4. Generate and review

Generate customized playbook bakes those details into the workflow prompts and agent instructions. Review the generated setup for the correct process name, operators, inputs, outputs, and exception paths before installing.

5. Install

Install customized playbook creates the agent, skills, workflow, and goal. A follow-up arrives in your inbox to start SOP & runbook documenting. The first run maps the process, drafts the right artifact, self-critiques it, revises it, and waits for your approval before anything becomes the reference.

What good looks like

Use three checks before trusting the new document:

• New-hire pass. Someone unfamiliar can follow the draft without asking what a step means.
• Exception coverage. The document includes the common edge cases, not only the happy path.
• Owner clarity. SOPs name responsible, accountable, consulted, and informed roles. Runbooks name escalation paths and rollback steps.

Common questions

When should a process become an SOP instead of a runbook? Use an SOP when the work is a business process with people, handoffs, ownership, and decisions. Use a runbook when the work is a repeatable operational procedure that needs exact steps, verification, troubleshooting, rollback, and escalation.

Should the agent improve the process while documenting it? It can propose improvements, but those should be reviewable before-and-after changes. The approved reference should never silently remove a step, safeguard, or owner.

What source material does the agent need? Rough notes are enough to start. Better inputs include old docs, screenshots, sample requests, recent handoffs, command history, and a list of known exceptions.

Can this work before document storage is connected? Yes. The agent can draft from attached notes and exports. Connecting document storage lets it search for an existing reference to update instead of creating a duplicate.