A Customer Escalation Prompt That Triages and Drafts the Reply

An escalated ticket isn't a normal ticket with a louder customer. It's a decision waiting to be made under time pressure: how bad is this, who needs to own it, and what's the next concrete move. Get those three wrong and a recoverable account churns. Most support teams make that call from a gut read of an angry thread at 4:55 on a Friday.

A customer escalation prompt does the unglamorous part first. It reads the ticket history, assigns a severity, routes to an owner, and names the next step, then drafts the reply. Triage and draft, in one pass, with the triage as structured fields you can sort and track.

This post shows how to build that prompt, why the severity-owner-next-step output contract matters more than the reply wording, and where a human still has to own the send.

Why support-macro listicles miss the escalation case

Search "customer escalation prompt" and the results are listicles of reply templates. Supportbench's 25 copy-paste support prompts includes a "summarize case history for escalation" prompt, but by its own description it returns a two-paragraph narrative, not severity, owner, or next-step fields. SurePrompts' 40 AI prompts for customer service has a manager-handoff script and an escalation-criteria matrix, both focused on human communication, neither producing structured triage output a tool can parse.

Those are fine for the easy 80%. The escalation is the other 20%, and it needs a decision, not a paragraph. A narrative summary tells you what happened. It doesn't tell you this is a P1, that it belongs to the named account manager, and that the next move is a callback within the hour.

That's the gap every listicle leaves open: no prompt that turns a messy escalation into a routable, sortable triage record. The reply is the part everyone solves. The triage is the part that actually saves the account.

What you can do with a customer escalation prompt

• Assign a severity (P1/P2/P3) from the ticket's content and sentiment
• Route the ticket to an owner using your team map
• Name a concrete next step with a timeframe, not "follow up soon"
• Draft a de-escalation reply that validates frustration without admitting fault prematurely
• Flag billing, legal, or churn-risk tickets for mandatory human review
• Output a structured record you can paste into your ticketing tool and sort

Anatomy of the prompt: variables, instruction, contract

Keep the inputs, the triage logic, and the output shape separate. The triage is the load-bearing part, so it gets the explicit contract.

VARIABLES
  {{ticket_history}}   full thread, oldest message first
  {{customer_tier}}    free / pro / enterprise
  {{team_map}}         issue type -> owner (billing: Sam, outage: on-call)

INSTRUCTION
  Read {{ticket_history}}. Assign severity from impact and
  sentiment. Route to an owner from {{team_map}}. Name one
  concrete next step with a timeframe. Then draft a reply
  that acknowledges the issue and states that next step.

OUTPUT CONTRACT
  severity:   P1 | P2 | P3
  owner:      <name or team from team_map>
  next_step:  <one action + timeframe>
  review:     REQUIRED if billing/legal/churn-risk, else OPTIONAL
  reply:      <drafted customer message>

Put the contract at the end of the prompt. When {{ticket_history}} runs long, a contract stated only at the top gets out-weighted by the recent context, and the model drifts back into a freeform summary. Restate the five fields on the final line and the structure holds. The same end-of-prompt discipline is what makes a Sentry error triage prompt reliably emit a severity instead of a wall of stack-trace prose.

Severity needs a rubric, not a vibe

Here's the stance: a severity field without a rubric is just the model's mood. "This sounds bad, call it P1" produces inconsistent triage across tickets and across runs. Define the levels in the prompt so two similar tickets get the same severity every time.

SEVERITY RUBRIC
  P1: paid customer blocked, public complaint, or explicit
      cancellation threat. Owner responds within 1 hour.
  P2: degraded experience, frustrated but not blocked.
      Owner responds same business day.
  P3: question or minor friction, no churn signal.
      Standard queue.

With the rubric inline, the model classifies against fixed criteria, the way an LLM-as-a-judge rubric scores against defined levels instead of an open-ended impression. Consistency is the whole value: you can trust the sort.

Step-by-step usage

1. Gather the thread

Paste the full {{ticket_history}}, oldest message first. The model reads sentiment trajectory, so a thread that escalated over three replies tells a different story than one angry first message. Order matters.

2. Set the tier and team map

Fill {{customer_tier}} and {{team_map}}. An enterprise P2 may outrank a free-tier P1 in your routing, so the tier lets the model weight accordingly. The team map routes the owner automatically.

3. Run and read the triage

Run the prompt. Read the triage block first. If review: REQUIRED, a human confirms severity and owns the next move before anything sends. The drafted reply is a starting point, never an auto-send for an escalation.

4. Send the decision, then the reply

Act on next_step immediately: page the on-call, schedule the callback, loop in the account manager. The reply goes out after the action is in motion, so the customer hears about a plan, not a promise.

5. Log and learn

Log the triage record. Over time you'll see which issue types keep hitting P1, which is a product signal, not a support one. That pattern feeds the renewal conversation.

Variables you'll set

Model behavior worth knowing

Claude reads sentiment trajectory across a long thread well and respects the review: REQUIRED flag when it's framed as a hard rule rather than a suggestion. GPT-4o classifies severity reliably once the rubric is inline, but without it tends to inflate everything to P1 when the tone is sharp. Both models draft warmer de-escalation copy when you tell them explicitly not to admit fault prematurely, since the default reflex is to apologize for things the company may not be liable for. State that boundary or the draft over-concedes.

Don't auto-send. The model reads tone, not contract terms or refund policy, so a billing or legal escalation drafted confidently can still be wrong on the facts that matter. The review: REQUIRED flag exists so the fast path skips the human checkpoint only where it's safe.

Getting started

1. Paste the escalated thread into {{ticket_history}}, oldest first
2. Set {{customer_tier}} and fill the {{team_map}}
3. Run the prompt and read the triage block before the reply
4. Act on next_step immediately for any P1
5. Confirm severity by hand on any review: REQUIRED ticket
6. Send the drafted reply once the action is in motion
7. Log the triage so recurring P1 issue types surface as a product signal

If the same accounts keep escalating, that's a health problem upstream of support. The Customer Health Monitor Agent Pack scores accounts before they blow up, and the Customer Feedback Synthesis Agent Pack turns recurring escalation themes into a product brief. Or browse the full catalog for the CS workflow packs.

Two related reads: the Sentry error triage prompt applies the same severity-first structure to engineering incidents, and the on-call handoff brief prompt shows how a structured handoff prevents the context loss that makes escalations worse.