How to Write a Support Runbook Your Team Will Actually Use

What a runbook is (and isn't)

A runbook is a step-by-step response guide for a specific situation. "When a customer says they can't log in, do this." "When a payment fails, do this." "When we get a complaint about a specific feature, do this."

A runbook is not a policy document, an SLA document, or a general training manual. Those have their place, but they're not what an agent needs in front of them when dealing with an angry customer at 11pm.

What scenarios need a runbook

Start with your most frequent ticket types and your highest-stakes situations:

Login / password reset issues
Billing disputes or refund requests
Major feature outages or downtime
Data access or privacy requests
Escalation to engineering or management
Angry or threatening customers
VIP / enterprise client issues

Each of these gets its own runbook page — a single document that covers one scenario completely.

The runbook template

RUNBOOK: [Scenario Name] Last updated: [Date] · Owner: [Name] WHEN TO USE THIS RUNBOOK [One sentence: what triggers this? "When a customer reports they cannot log in to their account."] IMMEDIATE RESPONSE (First 5 minutes) 1. Acknowledge the ticket within [X] minutes using template: [link to template] 2. [Specific first action — check a status page, look up their account, etc.] 3. [Second action] DIAGNOSIS STEPS □ Check if their account exists: [how to check] □ Check if account is locked: [how to check] □ Check if there's a known system issue: [status page link] □ Check their last successful login: [how to find it] RESOLUTION PATHS If account is locked → [exact steps to unlock] If password reset email isn't arriving → [steps to resend / check spam / manual reset] If account doesn't exist → [steps to verify and create or direct to signup] If system-wide issue → [link to outage runbook] ESCALATE IF - Issue is not resolved after 30 minutes - Customer claims data loss - Customer is threatening legal action Escalate to: [Name / Slack channel / email] CLOSING THE TICKET Use template: [link] Follow up in 24 hours to confirm resolution.

💡 Keep it under one page. If an agent needs to scroll through 3 pages to find the right step, they won't use it. If the situation is genuinely complex, split it into multiple linked runbooks.

How to get your team to actually use runbooks

The most common runbook failure: they're written once and then forgotten. Three things prevent this:

Link runbooks from your tickets. When a ticket comes in, the agent should be able to click a tag or category and have the relevant runbook appear. Don't make them hunt for it in a folder.
Review runbooks when they're used. After any escalation or non-standard resolution, ask: "Was the runbook accurate? Did we follow it?" Update it if not.
Give runbooks a named owner. Every runbook has one person responsible for keeping it current. Without an owner, they rot.

The outage runbook: your most important one

The highest-stakes moment for any support team is when your product is down. An outage runbook should cover:

How to confirm it's a real outage vs isolated user issue
Who to page immediately
What to post on your status page and when
How to communicate with affected customers (template ready)
When to send a mass email vs wait for resolution
How to handle inbound ticket volume during the outage

This runbook should be printed and on the wall, not buried in a folder that requires two logins to access during a crisis.

Manage your support operations in Resolvo

Tickets, SLA tracking, team runbooks. Keep your whole team aligned. Free to start.

Start Free →