Write an Escalation Runbook Your AI Agent Can Actually Use

The problem isn't the AI — it's the missing decision tree

When a support team installs an AI agent and then complains it escalates too much — or not enough — the root cause is almost never the model. It's that nobody wrote down the rules humans follow intuitively. Your senior support lead knows, without thinking, that a billing dispute over $500 goes to the account manager and a suspected data breach goes to the on-call engineer within five minutes. The AI agent doesn't know any of that until you tell it explicitly.

An escalation runbook is that document. It lives in your help center or internal knowledge base, the AI agent references it before deciding to page a human, and it removes the guesswork on both sides.

Start with your actual escalation taxonomy, not a generic one

Pull your last 60 days of tickets and sort them by the resolution path. You're looking for clusters: tickets that a human closed without any special access, tickets that required a tool action only an engineer can take, and tickets where a customer was at risk of churning or had a legal or security dimension.

Those clusters become your runbook categories. A typical small SaaS team ends up with four to six:

• Self-service close — the AI resolves it without human involvement
• Soft escalation — AI answers but flags the thread for a human follow-up within 24 hours
• Billing escalation — routed to whoever owns revenue, with the invoice and plan details pre-collected
• Technical escalation — routed to engineering on-call with error logs and reproduction steps pre-collected
• Churn-risk escalation — routed to the account owner with usage data and sentiment summary
• Security / legal escalation — immediate page, no AI response sent to the customer

If your taxonomy comes from real ticket data, the AI agent's classification will be far more accurate than if you design it from first principles.

Write each category as a decision block, not prose

Prose runbooks fail because the AI agent — and your human agents — have to interpret them. Decision blocks remove interpretation. Each block answers four questions in order:

1. What triggers this category? Be literal. "Customer mentions they cannot log in and password reset has not worked after two attempts" is usable. "Login issues" is not.

2. What must the agent collect before escalating? List the exact fields: account ID, plan tier, error message verbatim, browser and OS if relevant, whether the customer has already contacted support before on this issue. The AI agent should not page a human until this information is in the thread. This single requirement cuts the back-and-forth that makes human agents dread escalations.

3. Who gets the page, and how? Naming a role is better than naming a person. "On-call engineer via PagerDuty" survives personnel changes. "Slack DM to @dana" does not.

4. What SLA governs the response? Write the actual time window. "First human response within 15 minutes during business hours, 60 minutes outside" gives the agent something to communicate to the customer and gives you something to measure.

Connect the runbook to your AI agent's knowledge base

In Chattering, you add the escalation runbook as an internal document — one the agent reads but never quotes directly to customers. Mark it clearly in the filename or front matter as [INTERNAL — DO NOT SURFACE TO CUSTOMER]. The agent uses it to make routing decisions and to know what to collect; it doesn't paste runbook text into chat responses.

Then test it deliberately. Run synthetic tickets through each category and check whether the agent collects the right fields before escalating, routes to the correct target, and holds the ticket open with an accurate time expectation for the customer. Gaps in test results point to gaps in the runbook, not gaps in the model.

Build in a review loop, not a launch-and-forget cadence

A runbook that isn't updated becomes a liability. Schedule a 30-minute review every quarter. Pull escalations that humans re-routed after the AI sent them the wrong way — that's your correction list. Pull escalations where the human immediately closed the ticket without adding information — that's your over-escalation list.

Two numbers worth tracking: the ratio of escalations that arrive at a human with complete context versus incomplete, and the ratio of escalations that humans close in under two minutes (a strong signal the AI should have handled it). Both are visible in Chattering's shared inbox without custom reporting.

What good looks like

A mature escalation runbook means your AI agent almost never pages a human empty-handed. The human opens the escalated thread and has the account context, the customer's exact words, the error or event that triggered the escalation, and a clear category label. They resolve the ticket faster, and they stop dreading the AI's handoffs. That outcome is entirely a writing problem, not a technology problem.