Your support agent gets a message from a customer threatening legal action over a $200 charge. The agent isn't sure what to do. They look for the escalation policy. There isn't one. So they do what everyone does when there's no policy: they ping their manager on Slack.

The manager is in a meeting. The customer waits 3 hours. By the time someone responds, the customer has posted on Twitter.

This happens because most teams either don't have an escalation policy or have one that's so complicated nobody remembers it.

The Problem with Most Escalation Policies

Companies tend to go in one of two directions.

No policy. Everyone escalates by instinct, which usually means bugging the most senior person available. This creates bottlenecks, inconsistent responses, and senior people who spend half their day handling escalations instead of doing their actual job.

Over-engineered policy. Five escalation tiers. Detailed flowcharts. Decision matrices. Sounds thorough. In practice, nobody consults a flowchart while a customer is waiting. The policy sits in a Google Doc that was last updated 8 months ago.

The sweet spot is a policy simple enough to memorize and complete enough to cover 90% of situations.

Two Tiers Is Usually Enough

For teams under 20 people, you need two escalation tiers. That's it.

Tier 1: Handled by the support agent. This is everything the agent has the knowledge, tools, and authority to resolve. Password resets, product questions, standard refunds, how-to guidance, bug reports (logging and routing them), and routine complaints.

Tier 2: Handled by a senior agent or manager. This is everything that requires specialized knowledge, higher authority, or judgment calls. Legal threats, security incidents, VIP accounts, technical issues that need engineering, billing disputes over $X amount, and anything the agent genuinely doesn't know how to handle.

That's the whole policy. If you can handle it, handle it. If you can't, escalate to tier 2.

The key is defining "can't handle it" clearly. And that comes down to two things: knowledge and authority.

Knowledge Escalation

The agent doesn't know the answer and can't find it in documentation. This is the most common escalation trigger.

"A customer is asking if we support SAML SSO with Okta and I have no idea." Escalate. The agent shouldn't guess or give a vague "I'll check and get back to you" if someone else can answer it in 2 minutes.

The fix for knowledge gaps is documentation, not just escalation. Every knowledge escalation should result in the answer being added to your internal knowledge base. The goal is that the same question doesn't trigger an escalation twice.

Track your knowledge escalations weekly. If the same topic escalates repeatedly, you have a documentation gap, not an escalation problem.

Authority Escalation

The agent knows what to do but doesn't have permission to do it. This is the more important escalation type because it's about decision-making, not information.

Common authority triggers:

Refunds above a certain amount. Most teams give agents authority to refund up to $50 or $100 without approval. Anything above that needs a manager. Pick a number that balances speed with risk. If 90% of your refund requests are under $50, a $50 limit means agents handle most refunds without escalation.

Legal or compliance mentions. Any time a customer mentions lawyers, legal action, regulatory complaints, or data deletion requests (GDPR/CCPA). These need someone with authority to make promises or involve legal counsel.

Account security. Suspected compromised accounts, requests for bulk data export, or anything that could affect account integrity. A wrong move here has serious consequences.

VIP or high-value accounts. If a customer represents $10,000/year in revenue and they're unhappy, the response needs more thought than a standard template. This doesn't mean agents can't handle VIP tickets. It means VIPs get faster routing to someone with decision-making authority.

Time-Based Escalation

Some tickets don't get escalated because they're hard. They get escalated because they're stuck.

Set a time-based escalation rule: if a ticket is unresolved after X hours, it automatically escalates to tier 2. The number depends on your SLA and ticket complexity. For most teams, 4 hours during business hours or 24 hours total is reasonable.

This catches the tickets that fall through the cracks. The agent who was "going to follow up after checking with engineering" but forgot. The ticket that needs info from another department that never responded. The customer who sent a vague message that nobody knew how to classify.

Time-based escalation isn't about blaming the agent. It's a safety net. Every team drops tickets occasionally. An automatic escalation at the time boundary ensures nothing stays unresolved for too long.

The Escalation Handoff

How you escalate matters as much as when you escalate. A bad handoff looks like this: agent reassigns the ticket to a manager with no context. Manager has to re-read the entire conversation, ask the customer to repeat information, and figure out what's already been tried.

A good handoff includes: a one-line summary of the issue, what's been tried, why it's being escalated, and what the customer is expecting. "Customer charged twice for March subscription. I confirmed the duplicate charge in Stripe. Company policy says I can refund up to $50 but this is $99. Customer is asking for immediate refund. Needs manager approval for the amount."

The tier 2 person can now resolve this in under a minute because they have everything they need.

How AI Fits In

AI classification can trigger automatic escalations based on message content. A message containing legal threats, profanity above a certain severity, or keywords indicating a security issue can skip tier 1 entirely and go straight to the right person.

This is faster than having an agent read the message, decide to escalate, write up the context, and reassign. AI reads the message in milliseconds, classifies the intent and severity, and routes it with the relevant context attached.

Supp's priority scoring adds another layer. Each ticket gets a priority score based on the intent, the customer's history, and the content. High-priority tickets get automatically surfaced, so urgent issues don't sit in a general queue waiting their turn.

The goal isn't to remove the agent from escalation decisions. It's to catch the obvious ones automatically (legal threat = immediate escalation, no agent judgment needed) and let agents focus their judgment on the ambiguous cases.