Your best support agent goes on vacation. For two weeks, the rest of the team handles tickets they've never seen before. "How do we process a partial refund for an annual plan?" "What do we tell someone whose account was migrated to the new system?" "Where do I find the customer's subscription history?"

Nobody knows. Because the answers live in Sarah's head, and Sarah is in Portugal.

This is what happens when support knowledge isn't documented. Everything works fine when the right people are available. The moment they're not, quality drops off a cliff.

What a Runbook Is (and Isn't)

A runbook is a collection of step-by-step procedures for handling specific support scenarios. Unlike a knowledge base (which is for customers) or a training manual (which covers the why), a runbook is a reference for the how.

Each runbook entry answers: "A customer says X. What do I do?"

Keep entries short. If a runbook entry is more than 10 lines, it's too long. An agent should be able to glance at it mid-conversation and get what they need. If they have to read three paragraphs, they'll stop using the runbook.

Organize by What the Customer Says

Most internal documentation is organized by system or process. "Billing procedures." "Account management." "Technical troubleshooting." That structure makes sense to the person who wrote it. It doesn't make sense to the agent who's looking at a customer message and needs to know what to do right now.

Organize your runbook by the customer's words. The entry title should be the thing the customer says:

"I was charged twice" "I can't log in" "I want to cancel" "My order hasn't arrived" "I need to update my payment method"

When an agent gets a message, they search the runbook using the customer's phrasing. If the entry titles match how customers actually talk, agents find what they need in seconds.

Anatomy of a Good Entry

Each entry has four parts:

The trigger: what the customer says or asks. "I was charged twice" or "My invoice shows the wrong amount."

Diagnosis steps: what to check first. "Pull up the customer's billing history in Stripe. Check for duplicate charges in the last 30 days. Verify the amounts match."

Resolution: what to do based on what you find. "If duplicate charge confirmed: refund the duplicate, send [template A]. If charges are for different items: explain the breakdown, send [template B]. If the charge amount is wrong: escalate to billing team with account ID and screenshot."

Escalation criteria: when to pass it to someone else. "If the overcharge is more than $200, escalate to [person]. If the customer mentions legal action, escalate immediately."

That's it. Four sections, each a few lines. The whole entry fits on half a screen.

What to Document First

Don't try to document everything. Start with the entries that will save the most time.

Pull your ticket data for the last 60 days. Find the top 15 ticket types by volume. Write runbook entries for those 15 scenarios. You've now covered roughly 60 to 70% of what your agents encounter daily.

After that, add entries reactively. Every time an agent escalates because they don't know how to handle something, that becomes a new runbook entry. Every time a quality review catches an incorrect response, check if a runbook entry would have prevented it.

You'll build up to 30 to 50 entries within a few months. That's enough for most teams under 20 people.

Keep It Alive

The biggest runbook failure mode is stale content. You write it once, it's great for three months, then a process changes and nobody updates the runbook. Agents start ignoring it because they got burned by outdated instructions.

Assign a runbook owner. One person is responsible for keeping it current. When a process changes (new billing system, updated refund policy, new product feature), the runbook gets updated the same day. Not next week. The same day.

Quarterly reviews catch the stuff that drifts. Once every three months, have each agent flag any entries they've found to be outdated or incomplete. This takes 15 minutes per agent and keeps the whole document trustworthy.

Version-date each entry. Put a "Last updated: [date]" line at the bottom. If an agent sees an entry last updated 14 months ago, they know to verify before following it blindly.

Where to Put It

The runbook needs to be accessible within 2 clicks from wherever the agent works. If they have to leave their help desk, open a different app, search through a wiki, and find the right page, they won't use it.

Best options: a pinned document in your help desk's internal knowledge base (Zendesk has Guide, Intercom has Articles). Or a Notion/Confluence page with good search. Or even a shared Google Doc if your team is small and search works well enough.

Some teams pin the runbook link in their Slack support channel. Others embed it in their help desk sidebar. The exact tool doesn't matter. Accessibility does.

How AI Changes the Runbook

If you're using AI to classify and route support messages, the runbook concept evolves. AI handles the entries that are fully automatable (password resets, status checks, basic info requests). The runbook contains the entries that need human judgment.

AI can also suggest the right runbook entry to the agent. Customer sends a message, AI classifies it as a billing dispute, and the agent's interface shows the "billing dispute" runbook entry alongside the conversation. The agent doesn't search for it. It's already there.

This turns the runbook from a reference document into a real-time assistant. The agent still makes the decisions. The runbook provides the playbook. AI connects the two.

Supp's classification into 315 intents maps naturally to runbook entries. One intent, one entry. If your runbook covers your top 15 intents, and AI automatically surfaces the right entry for each message, your agents are working from the same playbook every time. Consistency goes up. Training time goes down. Sarah can go to Portugal without the team falling apart.