Escalation Thresholds by Ticket Category

The problem with a single escalation rule

Most small teams set one global rule: if the AI can't answer with enough confidence, escalate. Simple to configure, painful in practice. A password-reset question and a disputed charge both hit the same threshold and land in the same human queue with the same urgency. The agent triaging at 9 a.m. has to mentally re-sort what the routing logic already should have handled.

The fix isn't a smarter AI. It's category-specific thresholds — a deliberate decision, per ticket type, about when a human must take over and how fast.

Start by naming your actual categories

Before you touch any config, list the ticket types your team actually sees. Not the generic taxonomy from a support tool's dropdown — your real categories. For a typical small SaaS team these might be:

• Billing & payments — charge questions, refund requests, failed transactions
• Access & authentication — login failures, SSO errors, permission issues
• Product how-to — feature questions answerable from docs
• Bug reports — reproducible errors, data inconsistencies
• Account changes — plan upgrades, cancellations, seat adjustments
• Integrations — third-party connection failures, API questions

Keep the list to six or eight categories max. If you have twelve, you'll never maintain the thresholds.

Assign two variables per category

For each category, decide two things independently:

1. Escalation trigger — what condition forces a handoff. Options are confidence-based (AI scores its own answer below a cutoff), keyword-based (words like "refund", "cancel", "data loss" appear), turn-count-based (conversation exceeds N exchanges without resolution), or sentiment-based (user expresses frustration above a threshold).

2. Response-time SLA — once escalated, how quickly does a human need to respond. This is where teams conflate urgency with complexity. A billing dispute may be straightforward to resolve but urgent to acknowledge. A deep integration bug may be complex but tolerable to queue overnight.

Write both down explicitly. If you're using Chattering, you encode these as category routing rules that attach to your inbox and trigger human handoff with the full conversation context already attached — no copy-paste, no re-reading from the agent.

How to set the actual threshold by category

Here's the honest version: you don't know the right threshold before you have data. But you can make a defensible starting estimate by asking one question per category — what's the cost of a wrong AI answer here?

For billing & payments, the cost of a wrong answer is high: a customer who thinks a refund is coming when it isn't, or who cancels when a conversation could have retained them. Start with a tight trigger — escalate on any billing keyword, regardless of AI confidence. Don't try to let the AI resolve these.

For product how-to, the cost of a wrong answer is low if your docs are accurate. Start permissive — let the AI answer, escalate only if confidence is below your baseline or the user asks the same question twice in one session.

For bug reports, the cost of wrong AI handling is moderate but the complexity is high. The AI should acknowledge, collect reproduction steps, and escalate immediately to an engineer-facing queue — not try to resolve.

For access & authentication, speed matters more than complexity. A user locked out of their account loses trust every minute they wait. Escalate fast, even if the resolution is simple.

Build in a review cadence, not a set-and-forget

Escalation thresholds drift out of calibration. Your product ships new features, your docs fall behind, your ticket mix changes. A threshold that was right three months ago may now be either too tight (flooding humans with tickets the AI could handle) or too loose (letting the AI stumble through conversations it shouldn't touch).

Set a 30-day review: pull your escalation rate per category, look at the tickets that escalated but resolved in under two minutes (threshold too tight) and the ones the AI handled that generated a follow-up complaint (threshold too loose). Adjust one category at a time so you can attribute the change.

If you're a team of three or four, this review takes thirty minutes. Put it on the calendar the same day you configure the rules.

What to hand off, not just when

The threshold determines when a human takes over. Equally important is what arrives in the human's queue when they do. A bare escalation with no context forces the agent to re-read the entire conversation before they can respond — that's time your customer is waiting.

When Chattering escalates, the human receives the full transcript, the category tag, the AI's attempted answer (if any), and the trigger reason. That context window is what makes the SLA achievable. A human who picks up a billing ticket and already knows the customer tried to cancel twice in the same session can skip the preamble and get to resolution.

The practical starting point

If you're configuring this for the first time: pick your two highest-volume categories, set conservative thresholds (escalate more, not less), and run for two weeks. You'll have real data to calibrate before you extend the framework to every category. A framework you actually tune beats a theoretically complete one that no one revisits.