Set Escalation Rules for an AI Assistant
Your support assistant handles routine tickets, then approves a $900 refund on a case with a legal threat — deciding what it should have handed off. Set escalation rules for an AI assistant: define the triggers, name who each goes to, and have it produce a handoff packet.
Build the Assistant System PromptThe assistant that decided instead of escalating
You give your support assistant a solid instruction — the policy, the tone, the scope — and it handles the routine tickets well. Then a hard one arrives. A customer wants a $900 refund; the policy auto-approves only under $100. The customer mentions legal action. The order can't be verified. And the assistant, trying to be helpful, does exactly the wrong thing: it tells the customer the refund is approved, apologizes for the trouble, and promises it'll be sorted — a decision it had no authority to make, on a case that should have gone to a human before a word was sent. It didn't misbehave, exactly. It just didn't know that this was the moment to stop and hand off.
Most assistant instructions say what to do and how; far fewer say when to stop deciding and escalate. Escalation rules are that missing half — the explicit triggers that tell the assistant which situations it must not resolve on its own: the high-value or irreversible action, the legal threat, the policy that doesn't cover the case, the identity it can't verify, the confidence it doesn't have. And escalation isn't just "flag it" — it's handing off to the right person with enough context that they don't start from zero. This guide is how to set escalation rules for an AI assistant: define the triggers, name who each one goes to, and have the assistant produce a handoff packet instead of a decision. NewPrompt's System Prompt Generator is where you build the assistant's system prompt with those rules written in. The boundary is central here: an escalation rule is an instruction in a prompt, not a routing system — NewPrompt doesn't run your assistant, route anything to a human, open a ticket, or take an approval, and the model can still ignore a rule, so you write the triggers, test that the assistant honors them, and build the real routing on your side.
Why "help resolve issues" turns into deciding things it shouldn't
An assistant told to "resolve the issue" reads that as a mandate to reach a resolution — and reaching one, even when it lacks the authority or the information, looks more helpful than saying "I can't decide this." Without explicit escalation triggers, it has to judge for itself where its authority ends, and it judges generously, because stopping feels like failing. Here is how that plays out:
- It exceeds its authority. A refund over the threshold, a discount, a contract exception — the assistant approves or denies it as if it could, because nothing told it that this class of decision isn't its to make.
- It treats a legal threat as a normal ticket. "I'll be contacting my lawyer" or "this is fraud" should route straight to a human; without a trigger, the assistant answers it like any other complaint.
- It resolves a policy gap by improvising. When the policy doesn't cover the case, or two sections conflict, the assistant invents a plausible answer instead of surfacing that the policy is silent.
- It acts without verifying identity or ownership. A request to change or refund an account gets handled without confirming the person is who they say — a decision that should stop at a human.
- It answers at low confidence. Unsure of the right answer, it gives one anyway, in the same confident tone as a certain one, with no signal that this is a guess.
- It escalates vaguely, if at all. Even when it does defer, it says "you may want to contact support" and stops — no packet, no reason, no context for whoever picks it up, so the handoff starts from nothing.
Step 1: List the triggers that mean "stop and hand off"
Escalation starts with a concrete list of conditions under which the assistant must not answer on its own. Write them as specific triggers, not a vague "escalate when unsure." A workable set covers: money and commitments (a refund, discount, or credit over a threshold; anything touching a contract); legal and risk language (the customer mentions legal action, a chargeback, fraud, a regulator, or a formal complaint); regulated or high-stakes domains (medical, financial, security, compliance); policy gaps and conflicts (the policy doesn't cover the case, or two sections disagree); missing authority (identity or account ownership can't be verified); irreversible or high-impact actions; low confidence (the assistant isn't sure it has the right answer); tool or evidence failure (a lookup it needs fails); and out-of-scope requests it was never meant to handle. Each trigger is a line the assistant checks the situation against — and when one matches, it stops resolving and starts escalating.
The precision matters because the assistant only escalates on what you name. "Escalate high-risk situations" leaves "high-risk" to the model's judgment, which is exactly the judgment you're trying to remove from the loop; "escalate any refund over $100, and any message mentioning legal action, a chargeback, or a regulator" leaves nothing to interpret. The Customer Support Agent resource shows this shape — a policy-bounded assistant whose rule is that anything outside the pasted policy scope escalates instead of being guessed, so the specificity of your policy is what makes the boundary safe. It's a template you adapt and run in your own tool; the triggers you write are what it checks against.
Step 2: Name who each trigger escalates to
"Escalate to a human" is better than nothing, but a good rule names which human. A legal threat goes to a support lead or legal, not the same queue as a billing question; a security concern goes to the security owner; a high-value refund goes to whoever holds that approval authority. Map each trigger, or group of triggers, to a recommended reviewer — the team, role, or person best positioned to handle it. This does two things: it makes the escalation actionable (the packet knows where it's headed), and it forces you to confirm that a real owner exists for each trigger, which is where teams discover a category they hadn't assigned anyone to.
Be precise that "recommended reviewer" is a recommendation the assistant produces, not an action it performs. The assistant names who should handle the case; the actual routing — putting it in front of that person — happens in your own systems, not in the prompt. Keeping that line clear is what stops the assistant, and you, from believing the escalation is done just because it was recommended. The reviewer is named so a human can act on it; the acting is still a human's, or your system's, to do.
Step 3: Have it produce an escalation packet, not just a flag
The most common escalation failure isn't failing to escalate — it's escalating with no context, so the person who picks it up starts from zero. Fix that by requiring an escalation packet on every handoff: the status (escalate_human), the trigger that matched, a short summary of the request, the policy or evidence the assistant checked, what the assistant did and explicitly did not do, the recommended reviewer, the exact question for the human to answer, and — only if it's safe — a draft interim reply to the customer that acknowledges the escalation without committing to anything. That packet turns a handoff from "here's a ticket, figure it out" into "here's the situation, here's what's been checked, here's the one decision I need from you."
This is exactly the structure the Escalation Response Assistant resource is built around — an escalation assessment that names which criteria are met, does a risk read, recommends an owner, and produces a handoff brief written so the recipient can grasp the situation in about thirty seconds, plus a customer acknowledgment scoped to not promise a timeline or an outcome. It's a template you adapt; and, tellingly, its own design keeps the human in the loop — you forward the brief yourself, because the resource builds the packet, it doesn't deliver it.
Step 4: Forbid the actions it can't take — and the false "done"
Escalation rules need a matching set of prohibitions, or the assistant will escalate and act at the same time. State plainly what it must never do on a triggered case: do not approve or deny the high-value refund; do not promise an outcome or a resolution date; do not tell the customer the matter is settled; do not invent a policy to cover a gap; do not continue resolving after a trigger has fired. The reason to spell these out is that the assistant's helpful instinct will otherwise soften the escalation — it'll escalate and, in the same breath, reassure the customer that it's approved, which un-does the escalation by committing to the very thing a human was supposed to decide.
The subtler prohibition is against pretending the escalation happened. An assistant that says "I've escalated this to our team" when nothing in your system actually received anything has told the customer a comforting falsehood. Tell it to describe the handoff as a recommendation or a next step ("I'm routing this to our team for review"), not as a completed action, unless your setup genuinely performs the routing. The same goes for tickets: the assistant should not claim a ticket was created unless one really was. The escalation rule produces the intent to hand off; whether the handoff actually occurs is a fact about your system, and the assistant shouldn't assert it on the system's behalf.
Step 5: Test the triggers — an escalation rule is an instruction, not routing
Written escalation rules change the odds; they don't guarantee the behavior. A trigger is a line in a prompt, and a model can miss it — rationalize a borderline refund as under the threshold, treat a softened legal hint as an ordinary complaint, answer a low-confidence case with false confidence. So test each trigger the way you'd test any branch: run a normal case and confirm it resolves; run one just over each threshold and confirm it escalates; give it a policy-gap case and confirm it surfaces the gap instead of improvising; hand it an unverifiable-identity case and confirm it stops; feed it a legal-threat message and confirm it routes without answering; break the lookup tool and confirm it escalates instead of guessing. The triggers you don't test are the ones that quietly don't fire when a real customer hits them.
And the rules are only the first layer. NewPrompt gives you the prompts and the structure to write the escalation triggers and the packet; running the assistant, actually routing an escalation to a person, opening a ticket, taking an approval, and notifying anyone all happen in your own support stack, not in NewPrompt. The written rules make the assistant's boundaries explicit and its handoffs well-formed — they don't enforce anything at runtime, and they don't make the assistant safe on their own. So the escalation workflow, the approvals, and the final call on any escalated case stay with you and the support, legal, security, or finance owners who are accountable for it. The assistant's job is to recognize the moment and package it; deciding the case, and making the routing real, is yours.
Common mistakes
The habits that let an assistant decide what it should have handed off:
- Writing scope but not escalation triggers. An assistant told what it handles, with no list of what it must not, fills the gap by deciding; name the stop-and-hand-off conditions as explicitly as the scope.
- Leaving "high-risk" to the model's judgment. Vague triggers ("escalate if serious") put the call back on the model; use concrete lines — a dollar threshold, named legal keywords, an identity check.
- Escalating without a packet. "Contact support" with no reason or context makes the human start from zero; require status, trigger, evidence checked, and the exact question for the reviewer.
- Letting it act while it escalates. An assistant that escalates and also says "your refund is approved" has undone the escalation; forbid the decision, the promise, and the outcome on any triggered case.
- Claiming the handoff happened. The assistant shouldn't say it opened a ticket or routed to a team unless your system actually did; frame the handoff as a recommendation, not a completed action.
- Trusting the rules without testing them. An escalation trigger is an instruction the model can miss, not a control that fires on its own — test each one, and build the real routing yourself.
A worked example: a refund assistant that escalates instead of deciding
Watch a thin refund-assistant instruction approve a $900 refund and promise an outcome on a case with a legal threat, then a version with escalation rules stop, refuse to decide, and hand off a packet a human can act on.
A thin refund-assistant instruction approves a $900 refund, promises an outcome, and ignores a legal threat; the same assistant with escalation rules refuses to decide, names the matched triggers (over-threshold + legal + unverified), and produces a handoff packet with the exact question for a human and a no-commitment customer reply — behavior you route in your own stack and test trigger by triggerTHE THIN INSTRUCTION:
"Use the refund policy to help customers and resolve refund requests."
THE SITUATION:
Customer requests a $900 refund and says "I'll be contacting my
lawyer." Policy auto-approves refunds under $100 only. Order
ownership is unverified.
WHAT THE ASSISTANT DOES WITH IT:
- "I've approved your refund of $900." (no authority; over limit)
- apologizes and promises it's resolved (commits an outcome)
- treats the legal threat as normal (no human review)
- never verifies the order (acts without identity)
- no handoff packet (human gets no context)
THE SAME ASSISTANT WITH ESCALATION RULES (system-prompt section):
Escalate to a human, and do NOT decide, if:
- refund amount > $100
- the message mentions legal action, chargeback, fraud, a
regulator, or a formal complaint
- the policy doesn't cover the case, or two sections conflict
- order ownership can't be verified
- a required lookup fails twice
Never approve or deny a refund unless the policy explicitly allows
an auto-decision and the threshold is met.
On escalation: do NOT tell the customer it is approved or denied,
and do NOT promise an outcome or a date.
Produce an escalation packet:
status | trigger_matched | request_summary | policy_checked |
evidence | what_you_did_NOT_do | recommended_reviewer |
question_for_human | safe_customer_reply_draft
WHAT IT PRODUCES INSTEAD:
status: escalate_human
trigger_matched: refund_over_threshold + legal_threat +
unverified_ownership
request_summary: customer requests $900 refund, mentions
legal action
policy_checked: sec.2 auto-refund under $100; sec.5 legal
threats require human review
what_you_did_NOT_do: did not approve/deny; did not promise an
outcome; did not verify identity
recommended_reviewer: support lead + legal
question_for_human: approve, partially approve, or route to legal?
safe_customer_reply: "I'm routing this to our team for review and
someone will follow up -- I'm not able to
confirm a refund on this myself."
NEXT: you run this in your own support stack, actually route the packet
to the reviewer (the prompt doesn't), and test each trigger -- over
threshold, legal wording, unverified order -- to confirm it fires.Where this fits in NewPrompt
Setting escalation rules is part of writing an assistant's instructions, and NewPrompt gives you the tools for that, not a support desk. The System Prompt Generator is where you build the assistant's system prompt with the escalation triggers as rules; the Escalation Response Assistant resource is a worked example of the escalation packet — criteria met, a risk read, a recommended owner, a thirty-second handoff brief, and a no-commitment customer acknowledgment; and the Customer Support Agent resource shows the policy-bounded assistant whose rule is to escalate anything outside its scope instead of guessing. Each builds a prompt or shows a pattern you run in your own assistant environment; none runs or routes anything on your behalf.
This guide sits among the prompt guides as the one about handing off to a human. Giving an AI agent clear stop conditions is the general version — every reason an agent should halt; escalation is the specific stop where the next step is a person, and this adds what a general stop doesn't: who receives it and the packet they receive. Writing a role prompt that doesn't overreach bounds what authority the assistant has; escalation rules decide what happens when it reaches the edge of that authority — the role says "you don't approve refunds," the escalation rule says "when one arrives, hand it to whoever does." And making AI ask clarifying questions is one escalation trigger — the missing-information one; this is the full set, aimed at a human handoff rather than a follow-up question. The through-line: a good assistant knows the cases it must not decide, and hands each to the right person with the context to decide it.
Escalation rules are the assistant's version of a lifeguard's whistle. A lifeguard's hardest-trained judgment isn't the swim — it's recognizing the situation too big to take alone, the rip current or the second swimmer going under, and calling for backup loudly and early instead of paddling out and hoping. The whistle is that recognition and summons. Escalation rules train an assistant in the same reflex: on the case that needs a lead, a lawyer, or a security owner, don't try to be the whole rescue — recognize it, stop, and call, with a packet that tells the responder exactly what they're swimming into. But a whistle only works if someone's listening on the beach, and a model can still fail to blow it — which is why you test that it does and put a real responder on the other end. The assistant's job is to know what it can't handle and say so clearly; handling it is a human's.