IT Runbooks: How to Write Them (with Template and Examples)
What separates a runbook people actually use from documentation that rots: the anatomy of a good runbook, a copy-paste template, three worked examples, and how runbooks become the knowledge an AI help desk answers from.
A runbook is a step-by-step procedure for one specific operational task: resetting a locked account, provisioning a new-hire laptop, rotating a certificate. Not policy, not architecture docs — the exact steps, in order, that get the task done the same way every time regardless of who (or what) executes them.
Good runbooks are the highest-leverage documents an IT team writes: they turn tribal knowledge into something delegable, survivable, and — increasingly — automatable. Here’s how to write ones people actually use, with a template and worked examples.
Runbook vs. playbook vs. SOP
| Document | Scope | Example |
|---|---|---|
| Runbook | One task, exact steps, deterministic | “Reset a locked Entra ID account” |
| Playbook | One scenario, decision points, judgment required | “Suspected phishing incident response” |
| SOP | Policy-level: what must happen and who is responsible | “All access changes require manager approval” |
The distinction matters because they fail differently: a runbook with decision points buried in prose gets misexecuted; an SOP written as steps goes stale the first time tooling changes.
Anatomy of a runbook people actually use
- Title = the question. Name it the way someone would ask: “How to connect to the VPN,” not “Network Access Procedure v2.” Runbooks are found by search — in a wiki or by an AI agent — and search matches questions.
- Preconditions up front. What access, tools, and information the executor needs before step 1. Nothing kills trust like discovering at step 6 that you needed admin rights at step 1.
- Numbered steps, one action each. Exact menu paths, exact commands, expected output after each significant step.
- Verification. How to confirm it worked — the step everyone skips writing and everyone needs.
- Failure branches + escalation. The two or three most common ways it goes sideways, and exactly who/where to escalate when it does.
- Owner and review date. Stale runbooks are worse than none: they generate tickets and destroy trust in every other document. Date them, own them, review on a cadence.
The template
Copy, paste, fill in:
Title: How to [task, phrased as the question employees ask]
Owner: [name] · Last reviewed: [date] · Audience: [IT only / any employee]
Preconditions: [access, tools, info needed before step 1]
Steps:
1. [One action. Exact path/command. Expected result.]
2. […]
Verify: [How to confirm success]
If it fails: [Common failure → what to do. Else escalate to [owner] via [channel] with [what info].]
Three worked examples
1. Account lockout (IT-executed)
Title: Unlock a locked Entra ID account
Preconditions: Helpdesk-admin role; requester identity verified via MFA or manager confirmation — never by email alone.
Steps: 1. Entra admin center → Users → search the UPN. 2. Check sign-in logs for the lockout source (stale mobile session is the usual culprit). 3. Unlock / reset per policy; temp password delivered to recovery email only. 4. Require password change at next sign-in.
Verify: User confirms sign-in; sign-in log shows success.
If it fails: Repeated relocks → hunt the stale session (old phone, cached credential). Suspected compromise → stop, invoke the security playbook.
2. VPN setup (employee-facing)
Title: How do I connect to the VPN?
Preconditions: Company laptop, MFA enrolled.
Steps: 1. Install [client] from [self-service portal / MDM]. 2. Sign in with your company email → approve the MFA prompt. 3. Select the [region] gateway. 4. Toggle Connect.
Verify: Status shows Connected; [internal URL] loads.
If it fails: “Credentials invalid” → your password recently changed; sign out and back in. Still stuck → ask in #it-help with a screenshot of the error.
3. New-hire provisioning (IT-executed, multi-system)
Title: Provision IT for a new hire
Preconditions: Signed offer in HRIS; start date; role/team (drives app bundle); shipping address.
Steps: 1. Create the directory account from the role template — never clone a user (permission sprawl). 2. Assign the team’s app bundle via groups, not individual grants. 3. Enroll the laptop in MDM; ship. 4. Day-one: MFA + password setup during onboarding session.
Verify: New hire signs into email, Slack, and one core app before end of day one.
If it fails: Missing app access → check group membership before touching individual permissions. Escalate hardware delays to [owner] 48h before start date.
Writing rules that keep runbooks alive
- One task per runbook. The 40-page “IT handbook” is where answers go to hide.
- Steps, not policy. “Settings → VPN → Add” resolves; “access is governed by the network policy” creates a follow-up ticket.
- Write at the moment of the second ask. The first time a question comes in, answer it. The second time, answer it in a runbook and share the link. Your queue tells you exactly what to write next.
- Review on tool changes, not calendars alone. The VPN runbook dies the day you switch VPN vendors — update it in the migration checklist.
Runbooks are agent knowledge now
There’s a newer reason to write runbooks well: they’re no longer just for humans. An AI help desk answers employee questions from your runbooks — retrieving the right one, answering with the source cited, and resolving the request without a human touching it. Every runbook you write once now resolves the question every time it’s asked. The same properties that make a runbook good for people — question-shaped title, exact steps, failure branches — are exactly what make it good retrieval material for an agent. Write once, resolve many.