How to Build an IT Playbook That People Actually Use

The offboarding doc says, in step 4: "Remove the user from all relevant groups."

Which groups? Active Directory? Microsoft 365? The customer-facing SharePoint sites? The shared inboxes? The Slack workspace? The expense system? The CAD license server? The VPN ACL? The vendor portals where they had their own SSO accounts?

The doc was written three years ago by an IT manager who has since left. The person now responsible for offboardings has read it twice, decided it's incomplete, and is now mentally maintaining her own version of the real procedure. When she leaves, that version goes with her.

This is what an IT playbook looks like when it fails. It exists. It's even mostly written. It just isn't used, because using it would slow people down more than ignoring it. The work gets done from memory and tribal knowledge, and the doc rots on the shelf as a record of what someone used to think the process was.

Why Most IT Playbooks Don't Survive Contact With Reality

A playbook fails in three predictable ways.

It's written generically. "Configure security policies appropriately." "Ensure compliance with company standards." These read like compliance language because they were written for an audit, not for the person actually doing the work at 4:30 on a Friday. The right level of detail for a runbook is "if you need to do X, run this exact command, expect this exact result, escalate to Y if you don't see it."

It's not where people look. The doc lives in a SharePoint site nobody bookmarked, three folders deep, in a Word file last modified before the merger. When the person who needs it is in the middle of a problem, they're not going to find it. They'll Google something, ask in Teams, or guess.

It's never reviewed. It was right when it was written. The Active Directory schema has changed since then. The MDM platform was replaced. The HR system that used to feed user creation now uses a different API. The doc still references all the old systems. Reading it actively misleads.

When all three failure modes compound, you don't have a playbook. You have an archive of what IT used to look like, plus a person who knows what it really looks like now.

What a Playbook Should Cover

Not everything. The mistake most IT teams make is trying to document every system end-to-end. You end up with hundreds of pages nobody reads.

The playbook should cover the recurring, multi-step, mistake-sensitive operations. Things that happen often enough that consistency matters, and have enough steps that someone doing them once a quarter will skip one.

For most SMBs, that's a fairly contained list:

• New user onboarding — create account, group memberships, license assignments, mailbox setup, password issuance, hardware provisioning, software installation, day-one access verification
• User offboarding — disable account, revoke MFA, transfer mailbox and OneDrive, capture group memberships, collect hardware, revoke SaaS access, retain or delete data per policy
• Hardware refresh — imaging or autopilot enrollment, application install set, user data migration, license reassignment, decommission of the old device
• Common ticket flows — password resets that don't go through self-service, Outlook profile rebuilds, printer redeploys, license assignment changes, conference room AV troubleshooting
• Incident response basics — suspected phishing, possible malware, lost device, account compromise
• Routine maintenance — backup verification, patch status review, license utilization review, expired account cleanup

That's not a hundred pages. That's twenty short runbooks, each one or two pages, each tightly scoped to a single recurring operation.

We've made our own onboarding, offboarding, and access-change runbooks available as intake forms precisely because they're the highest-friction recurring operations in most environments.

What Makes a Runbook Actually Get Used

It's short

If a runbook is longer than two pages, somebody will scroll past the middle. Aim for one page if you can. The format we use is:

1. When to use this — one sentence
2. Prerequisites — what you need before starting (credentials, info, approvals)
3. Steps — numbered, specific, no "configure appropriately"
4. Verification — how to confirm it worked
5. Common issues — the two or three things that go wrong and how to fix them
6. Escalation — who to call if it's not working and why

That's it. No history section. No long preamble. No table of contents.

It's findable

A wiki page nobody can locate is the same as no wiki page. We index runbooks by the operation, not the system: "Offboard user," not "Active Directory > User Management > Termination Procedures." The IT person searching at 4:30 on Friday is thinking "I need to offboard somebody," not in a taxonomy of systems.

A search bar that works matters. Tags matter. A simple flat index — one wiki page that links to every runbook — matters more than a beautiful folder hierarchy.

It's owned

Every runbook has a name on it. Not a team, a person. That person is responsible for keeping it current. When the MDM platform changes, that person updates the affected runbooks within a defined window. When somebody finds a step that's wrong, they tell the owner, and the owner fixes it the same week.

Without ownership, the runbook drifts. With ownership, it stays useful.

It's reviewed on a cadence

We review our internal runbooks quarterly. It's not a big ceremony — the owner reads through theirs, runs through the steps mentally, fixes anything that drifted. Most updates are a sentence or two. The point isn't the changes; it's that the document gets touched by the person responsible, four times a year, on a schedule.

Documents that aren't touched on a schedule will eventually be wrong. Documents that are touched on a schedule stay close to reality.

The Hardest Part Isn't the Writing

The hardest part is the cultural one. Teams that have always operated from memory feel like writing things down is bureaucratic overhead. The first time you write a runbook, somebody on the team will read it and say "I already know how to do this." The point isn't that they know how to do it. The point is that the next person doesn't, and the bus factor matters.

For environments where one IT person carries the operational knowledge, this is existential. When that person leaves or is out, the operation stops being able to do the things they knew how to do. A playbook is the cheapest form of insurance against that risk.

This is the kind of operational discipline that distinguishes reactive IT from operational IT. Reactive teams improvise. Operational teams have a playbook, and they use it.

What We Do for Clients

When we take over an environment, one of the first things we build is the runbook set. We don't import a generic template — we write the runbooks for that specific environment, with the actual systems, actual group names, actual escalation contacts. It's a few weeks of work upfront and it pays off the first time a tech who's never touched that client's environment can complete an offboarding correctly in twenty minutes.

If you want help building yours, or auditing what you already have, our IT consulting team can scope it. We'll tell you what's worth documenting, what isn't, and what the minimum viable playbook looks like for an operation your size.