Every support team has informal resolution logic living in agents' heads. "For orders under $50, we just reship without asking for proof." "If they mention the word 'cancel,' flag it for retention." "That courier's tracking never updates — always add 2 days to their ETA when customers ask." This knowledge exists, it's real, and it's what makes experienced agents effective. The problem is that it can't be acted on by an AI unless it's written down.
A support ops playbook is the documentation layer that makes your tribal knowledge explicit. It's not a policy document for your website. It's not a training manual for new hires. It's a structured record of your actual resolution decisions — the rules that determine what action to take for a given customer situation — formatted so both your AI agent and your human agents can follow them consistently.
This post is a working template for building one. It's built around the tier-1 ticket categories that AI can act on, because that's where playbook documentation has the most leverage. But the structure applies to the full queue, not just the automatable part.
Step 1: Audit what you're actually resolving
Start from your closed-ticket data, not from what you think your queue looks like. Pull 90 days of closed tickets and categorize them by the underlying request type — not the subject line, not the channel, not the priority tag. What did the customer actually want?
You're building a frequency distribution of request types. The top 10–15 request types typically account for 70–80% of total volume in B2C support. Those are your playbook targets. Everything below the top 15 is long-tail — you'll document it eventually, but it's not where you start.
For each top request type, note: how often it arrives, how long it takes to resolve on average, how often it gets reopened, and whether the resolution varies by agent or is consistent. High volume + consistent resolution = strong AI candidate. High volume + variable resolution = playbook clarity problem first, automation second.
Step 2: Write the resolution rule for each tier-1 category
Each playbook entry has the same structure, regardless of ticket type. Write it in this format:
Intent: What is the customer trying to accomplish? One sentence, from the customer's perspective. "Customer wants to confirm their order has shipped and get an estimated delivery date."
Required data: What information must be retrieved or confirmed before taking action? "Order ID (from customer message or account lookup), current carrier tracking status, estimated delivery date from carrier."
Decision rules: The conditional logic that determines the resolution path. This is the core of the playbook entry — written as explicit IF/THEN statements, not prose. For example:
- IF carrier status is "in transit" AND ETA is within the stated shipping window: reply with current status + ETA, close ticket.
- IF carrier status is "in transit" AND ETA exceeds the stated shipping window by more than 3 days: reply with status + ETA + apology for delay, offer $5 credit per policy, close ticket.
- IF carrier status is "delivered" AND customer reports non-receipt: do not auto-close. Confirm delivery address, surface delivery scan, escalate to agent for investigation.
- IF carrier API returns error or no data: reply with "I'm having trouble retrieving your tracking status — our team will follow up within 2 hours," escalate to agent with priority flag.
Response template: The actual text the AI or agent sends, with placeholders for variable fields. This is distinct from a macro — it's tighter, purpose-built for this specific resolution path, not a general-purpose reply.
Exceptions that require human override: Situations where the decision rules don't apply. "Customer has a previous open ticket on this order — route to original agent. Customer expressed delivery frustration in prior interaction — agent review before sending."
Step 3: Set the confidence threshold for each entry
Not all tier-1 categories warrant the same confidence threshold for autonomous resolution. The appropriate threshold reflects two variables: the cost of a wrong resolution and the clarity of your intent detection.
Password reset is the simplest case: intent is unambiguous (there's basically no other reason a customer says "I can't log in"), the resolution is a single mechanical action, and the cost of a wrong action is near-zero (sending a reset email to the wrong person isn't harmful). Confidence threshold can be low — 60% is sufficient for autonomous action.
A refund request on a high-value item is more complex: intent can be ambiguous (they want a refund vs. they want an exchange vs. they want to express frustration without actually requesting a refund), the resolution has financial stakes, and a wrong action (issuing a refund when they wanted an exchange) requires a correction interaction. Confidence threshold should be high — 85%+ for autonomous action, medium confidence for agent review queue.
Document the threshold alongside the decision rules for each entry. This makes it operational — the AI's confidence calibration can be tuned to match the risk profile of each category rather than applying a single global threshold.
Step 4: Define the escalation path explicitly
Every playbook entry needs an escalation path: what happens when the AI cannot or should not resolve the ticket. Vague escalation instructions ("route to support team") create the same kind of ambiguity in your AI layer that vague resolution logic does — the system makes its best guess, and sometimes that guess is wrong in ways that compound the customer's frustration.
Useful escalation paths specify: which queue or agent group receives the ticket, what priority level it's tagged at, what context is included in the internal note, and whether the customer receives an immediate acknowledgment while waiting (and what that acknowledgment says).
A common omission: teams document what to do when the AI correctly identifies an escalation trigger but don't document what to do when the AI's escalation triggers fire incorrectly — a customer who gets escalated when they didn't need to be. This happens. The customer gets a "we're connecting you with our team" message and then waits for an agent to pick up what should have been a 15-second auto-resolution. Build a path for these too: if an agent receives an escalated ticket and determines the AI should have handled it, one-click routing back to the auto-resolution queue, not manual reply.
Step 5: Build the review cadence into the playbook itself
A playbook that isn't reviewed becomes outdated, and outdated playbooks cause the worst kind of automation failure: technically correct resolutions that are wrong because the policy changed. Your 30-day return window moved to 14 days. Your shipping carrier's SLA changed. A new product category has different handling rules. None of these are unusual events — they're the normal pace of business change in a B2C operation.
Each playbook entry should have a last-reviewed date and an owner. The owner is the person responsible for noticing when the policy or data that underlies the entry has changed and updating the entry before the change goes live. This is support ops work, not engineering work — no code change required, just documentation update.
A monthly 30-minute playbook review meeting is sufficient for most growing teams: walk through any entries that triggered high reopen rates or agent feedback flags in the previous month, check for known policy changes in the pipeline, and update accordingly. The discipline of the meeting matters more than its length.
The state of the playbook is the state of your AI's accuracy
We're not saying a comprehensive playbook guarantees accurate AI resolution — we're saying the quality of your AI resolution is bounded above by the quality of your playbook documentation. An AI working from vague or incomplete playbooks makes vague or incomplete decisions. The classifier can be excellent; if the resolution rules it's executing are wrong, the resolution will be wrong.
Teams that invest in playbook quality before optimizing their classifier accuracy consistently outperform teams that do it in the reverse order. It's faster to write a clear decision rule than to retrain a model. It's faster to audit a response template than to debug a confidence calibration. The playbook is the cheapest, highest-leverage component in the AI support stack — and it's the one most consistently underfunded in favor of the technology layer.
Treat it as a living operational document with an owner, a review cadence, and a direct line to your resolution quality metrics. That discipline is what separates AI support implementations that keep improving from ones that plateau at whatever accuracy the initial deployment happened to reach.