;
};
An escalation policy is a short, written list of the conversations your AI agent must hand to a person, the signal that triggers each handoff, and what the person receives when it lands. Build it before launch from eight always-escalate categories (safety and crisis, identity and account takeover, fraud, legal and regulatory complaints, bereavement and vulnerable customers, high-value or irreversible actions, repeated failure, and an explicit request for a human), express each one as a trigger you can test, and then review the reasons behind every escalation on a fixed schedule.
The goal is not the lowest escalation rate. It is that the agent resolves what it safely can, and a person gets the cases where a wrong answer would hurt the customer or the business.
## Why write it down
A policy that only exists in people's heads can't be tested, drifts from the agent's configuration, and leaves no record of what should have happened when a sensitive conversation goes wrong. A written policy gives support, compliance and engineering one document to agree on, and becomes the source of your test cases.
## The always-escalate categories
Adapt the examples to your business, but think hard before removing a category.
| Category | Examples | Why a person must handle it |
| - | - | - |
| **Safety and crisis** | Self-harm, threats of violence, medical emergencies, abuse disclosures | The customer may need immediate help that a support flow can't provide. Speed and judgment matter more than resolution. |
| **Identity and account takeover** | "Someone changed my password", unrecognized logins, a request to change the email or phone on an account | A wrong action hands an account to an attacker. Verification often needs steps the agent can't perform. |
| **Fraud** | Unauthorized transactions, scam reports, suspicious payment requests | Time-sensitive, often has reporting duties, and the customer may be under pressure from a third party. |
| **Legal and regulatory complaints** | Threats of legal action, regulator or ombudsman mentions, formal complaints, data-subject requests | Many industries have rules on how complaints are logged and answered. Check your regulator's rules for your market. |
| **Bereavement and vulnerable customers** | A death in the family, serious illness, financial hardship, signs of confusion or distress | These customers need flexibility and care, and some regulators expect firms to identify and support them. |
| **High-value or irreversible actions** | Large refunds, account closure, deleting data, wire transfers, cancelling with penalties | The cost of a mistake is high and can't be undone. |
| **Repeated failure** | The customer repeats the same issue, the agent's answer was rejected twice, an action failed | The agent is not making progress. Continuing costs goodwill. |
| **Explicit request** | "Let me talk to a person", "agent", "human please" | Refusing or ignoring the request erodes trust. Decide how persistent a request must be before it is honored, and keep the bar low. |
## A decision framework for everything else
For every other intent, ask how much harm a wrong outcome causes, and whether the agent has what it needs to get it right (approved knowledge, a working action, a clear policy).
```mermaid theme={null}
---
title: Should this intent escalate?
---
flowchart TD
START(["New intent"]) --> CAT{"In an always-escalate category?"}
CAT -->|"Yes"| HUMAN(["Escalate to a person"])
CAT -->|"No"| HARM{"Wrong outcome is costly or irreversible?"}
HARM -->|"Yes"| GATE["Agent prepares, person approves"]
HARM -->|"No"| ABLE{"Approved knowledge or working action?"}
ABLE -->|"No"| FIX["Escalate for now and log the gap"]
ABLE -->|"Yes"| AGENT(["Agent resolves"])
AGENT --> FAIL{"Failure or customer asks?"}
FAIL -->|"Yes"| HUMAN
classDef source fill:#F7F7F7,color:#131415,stroke:#E8E8E8
classDef agent fill:#131415,color:#FFFFFF,stroke:#131415,stroke-width:3px
classDef surface fill:#FFFFFF,color:#131415,stroke:#131415
classDef human fill:#C3EE5E,color:#131415,stroke:#131415,stroke-width:2px
class START source
class AGENT agent
class CAT,HARM,ABLE,FAIL,GATE,FIX surface
class HUMAN human
```
In the middle path, the agent gathers the details and drafts the reply or action, and a person checks it before it reaches the customer or your systems. It is often the right first step for a sensitive intent you plan to automate later.
## How to express triggers
A trigger must be observable in the conversation or in your data. "Escalate angry customers" can't be tested; "escalate when the customer mentions a regulator, ombudsman or lawyer" can.
| Trigger type | How it works | Good example | Weak example |
| - | - | - | - |
| **Topic** | The conversation is about a listed subject. | "Escalate any report of an unauthorized transaction." | "Escalate payment problems." |
| **Risk signal** | Words or data that indicate danger or vulnerability, regardless of topic. | "Escalate if the customer mentions self-harm, a death in the family, or being pressured to pay." | "Escalate sensitive conversations." |
| **Confidence or failure** | The agent can't find an approved answer, an action fails, or the same issue repeats. | "Escalate when the customer has repeated the same unresolved issue three times." | "Escalate when the agent is unsure." |
| **Customer request** | The customer asks for a person. | "Escalate when the customer has asked for a human twice." | "Try to keep the customer with the agent." |
| **Value threshold** | A number in your data crosses a limit. | "Hand off refunds above the auto-approve limit." | "Hand off big refunds." |
Put thresholds in data, not prose: a refund limit belongs in a rule that reads the order amount, not in a sentence the model interprets. When a topic has a defined workflow (cancel, refund, address change), let the workflow decide when to hand off instead of listing the whole topic as a trigger.
## What to hand over
The person who picks up an escalation should never have to ask the customer to repeat themselves.
| Include | Why |
| - | - |
| Full transcript | The person sees exactly what the customer was told. |
| Escalation reason | Tells the person what kind of case it is before they read a word. |
| Verified customer identity and key account data | Avoids a second verification round. Mark clearly what was verified and what was only stated. |
| Actions attempted and their results | Prevents duplicate refunds, double cancellations and contradictory replies. |
| A short summary and the open question | Lets the person start from the decision that is needed. |
| What the customer was promised | Response time, next step, reference number. |
Tell the customer what happens next, promise only what your team can meet, and stop the agent replying once a person is assigned.
## Response-time expectations
Escalated cases are the hard ones, so give them their own targets per category rather than the queue default: a safety or account takeover case needs a much faster response than a refund over the limit. Decide what happens outside staffed hours for each category (for example an emergency resource for crisis cases, or an account freeze path for takeover reports), and make the handoff message match the target you can actually hit.
## Testing the policy
Every category gets test conversations, and all of them run before every change to prompts, rules or knowledge.
1. **Write positive cases** for each category, including indirect phrasing ("my mum passed away and her card is still being charged").
2. **Write near misses** that should not escalate, such as a customer asking how to report fraud in general, so you catch over-escalation too.
3. **Test multi-turn conversations.** Many triggers only appear in the third or fourth message, after the agent has already started a workflow.
4. **Test in every language you support**, and with typos, slang and mixed languages.
5. **Check the handover**, not only the decision: the ticket lands in the right queue with the transcript, reason and attempted actions.
## Reviewing escalation reasons over time
Tag every escalation with a reason from a fixed list, then read the distribution weekly. A useful taxonomy separates causes you fix in different places:
| Reason family | Examples | Where the fix lives |
| - | - | - |
| Knowledge | No content, conflicting content, partial content | Your help center and internal articles |
| Action | System not connected, API call failed | Engineering and your integrations |
| Customer | Asked for a person, input too unclear to act on | Conversation design, welcome message, clarifying questions |
| Policy | A rule or safety check required a handoff | Your policy itself: confirm it is still right |
Watch for two failure modes. **Over-escalation** shows up as policy escalations on topics the agent could handle, or customers asking for a person after the agent tried; read those conversations first. **Under-escalation** is invisible in escalation reports, because the conversation never escalated. Sample resolved conversations in your sensitive categories every week and check that none should have reached a person. Add every miss as a test case.
## Policy template
Copy this table into your policy document and fill one row per trigger.
| Category | Trigger (observable) | Trigger type | Destination queue | Response target | Customer message | Handover must include | Owner |
| - | - | - | - | - | - | - | - |
| Account takeover | Customer reports a login, password or contact change they did not make | Topic | Security team | Your target | "I've passed this to our security team, who will contact you..." | Transcript, verified identity, recent account changes | Security lead |
| Value threshold | Refund amount above the auto-approve limit | Value threshold | Billing | Your target | "A teammate will review this refund..." | Order, amount, eligibility check result | Billing lead |
## Common mistakes
* **Vague triggers** that can't be tested ("escalate frustrated customers").
* **Escalating whole topics** that have a working, rule-backed workflow.
* **No near-miss tests**, so over-escalation is only found after launch.
* **Handoffs without context**, so customers repeat themselves.
* **Only reading escalations**, never the resolved conversations where one was missed.
For examples of ticket types that should go to a person, see the blog post [When AI should escalate: 5 tickets to avoid](https://www.usefini.com/blog/automation-vs-escalation-in-ai-customer-support).
## Doing this in Fini
In Fini (usefini.com), each part of the policy maps to a specific setting:
* **Always-escalate categories:** write them as plain-language triggers in the *Escalation Topics* subsection of the Planning Prompt. The defaults cover legal or regulatory issues and persistent human requests (`agent_request_count >= 3`, `issue_repeat_count >= 3`); add your business-specific categories on top. See [Prompts](/en/configuration/prompts).
* **Value thresholds and workflows:** put limits in an Intent Rule branch that hands off by design, such as a refund above your limit. The branch ends in a handoff Reply that tells the customer a teammate will follow up. See [Rulebook](/en/automations/rulebook).
* **Topics that should always reach a person from the knowledge base:** set the article-level **Escalation** field to **Yes** on those articles, so hitting them triggers an escalation path. See [Articles](/en/knowledge/articles).
* **Widget handoff into your helpdesk:** a [Business Rule](/en/automations/business-rules) with the **On Escalation** trigger creates the ticket in your helpdesk.
* **"Agent prepares, person approves" and staying silent:** use an **Internal Comment** rule for sensitive intents, and **No Reply** with `Human Agent Assigned Equals True` so the agent never talks over a person. See [Reply Rules](/en/automations/reply-behavior).
* **Reviewing reasons:** every escalation is tagged with a reason in four families (Knowledge, Action, User, Policy). Read the escalation doughnut and the **Escalation reason** filter in [Analytics](/en/analytics).
* **Handover and testing:** how the handoff lands on each surface with the transcript, customer attributes and AI Steps trace is covered in [Escalation and handoff](/en/use-cases/escalation-and-handoff). To test the policy, create [Test Suite](/en/testing/test-suite) cases from real conversations for each category, and link them to a criteria group whose exact handoff check is marked **Required to pass**. Put near misses in a separate group that checks the agent did not hand off. Every fixed miss becomes a new case.
## Related
How Fini decides to escalate, the reason taxonomy and the handoff on each surface.
Escalation Topics in the Planning Prompt.
No Reply, Internal Comment and Direct Reply conditions.
Read and write endpoints, idempotency and confirmation before irreversible actions.
## Related topics
- [Preparing your APIs for an AI agent](/en/playbooks/preparing-apis.md)
- [Questions to ask an AI support vendor, with Fini's answers](/en/evaluate/questions-to-ask.md)
- [Running multilingual AI support well](/en/playbooks/multilingual-support.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.