Summarize escalation patterns across recent incidents to surface root causes

advancedClaude OpusCustomer ServiceEscalationsescalationsroot-causeexecutive-reviewcx-operationssynthesis

Use case

Use this when you have a backlog of executive escalations, severe support tickets, or churn-risk accounts and you need to brief leadership on what is actually going wrong. The output is a root-cause-oriented brief that distinguishes one-time fires from systemic issues — the kind of analysis that drives a real ops change, not another all-hands apology.

The prompt

You are the head of escalations at {{company_name}}. You are preparing a monthly escalation review for the executive team. Your job is to look across {{escalation_count}} recent escalations and surface patterns — not retell each ticket.

Inputs:
- Time window: {{time_window}}
- Escalation source: {{source}} (e.g., exec inbox, severity-1 tickets, churn-risk flag from CSM, social complaint surfaced to leadership)
- Per-escalation record (provided in {{escalations}}): account name, ARR, segment, trigger event, root cause hypothesis, resolution status, days open, owner team
- Known initiatives in flight: {{known_initiatives}}

Produce an executive escalation review with:

1. **Headline (3 sentences max)** — what is the single most important pattern this month, in plain language an executive can repeat in a board meeting.
2. **Pattern clusters (3–6)**. For each:
   - Pattern name and one-line description
   - Number of escalations in the cluster, total ARR at risk, segments affected
   - Root-cause hypothesis (process, product, people, or pricing) — pick one primary
   - Whether this is **new**, **recurring**, or **escalating** vs. prior periods
   - Owning team and current status (no owner / owner identified / fix in flight / fix shipped, not yet validated)
3. **The one-offs** — escalations that do NOT fit a pattern. List briefly so they don't pollute the systemic view.
4. **What is and isn't working** — for each known initiative in {{known_initiatives}}, mark whether escalation data supports that it is moving the needle, with evidence.
5. **Three asks for the executive team** — specific, scoped decisions or resource asks, each tied to a pattern cluster. Not "we need to do better at X."
6. **Watchlist** — 2–3 emerging weak signals that are not yet patterns but could become next month's headline.

Rules:
- Distinguish a pattern (≥3 escalations with the same root cause) from a coincidence.
- Quantify ARR at risk per cluster — leadership prioritizes by dollar exposure, not ticket count.
- Do not blame individual reps or CSMs by name. Focus on systems.
- If the data is insufficient to call something a pattern, say so explicitly. Do not over-claim.

Variables

{{{{company_name}}}}Replace with your {{company name}}
{{{{escalation_count}}}}Replace with your {{escalation count}}
{{{{time_window}}}}Replace with your {{time window}}
{{{{source}}}}Replace with your {{source}}
{{{{escalations}}}}Replace with your {{escalations}}
{{{{known_initiatives}}}}Replace with your {{known initiatives}}

Example

Input

company_name: Northwind Payments
escalation_count: 27
time_window: April 2026
source: combined (exec inbox + sev-1 tickets + CSM churn-risk flags)
escalations: |
  1. Acme Logistics — $480K ARR — Mid-market — payout delay 6 days — root cause: ACH file rejected by partner bank — owner: Payments Ops — open 9 days
  2. Brightline Co. — $120K ARR — SMB — dashboard showing wrong balance — root cause: caching bug — owner: Engineering — resolved
  3. Coastal Freight — $640K ARR — Enterprise — payout delay 4 days — root cause: ACH file rejected by partner bank — owner: Payments Ops — resolved
  4. DiamondPoint — $95K ARR — SMB — billing dispute on overage — root cause: pricing page unclear — owner: Pricing — open 14 days
  5. Evergreen Retail — $210K ARR — Mid-market — payout delay 5 days — root cause: ACH file rejected (different partner bank) — owner: Payments Ops — open 6 days
  [... 22 more, including 4 more ACH-related, 3 more billing-overage disputes, 2 SSO outages, and assorted one-offs ...]
known_initiatives: |
  - "ACH partner-bank redundancy project" (kicked off Feb, owner: Payments Ops)
  - "Pricing page rewrite" (in design, owner: PMM)
  - "Self-serve billing FAQ in Help Center" (shipped March 15, owner: Support)

Output

# Northwind Payments — Escalation Review, April 2026

## Headline
Payout delays caused by ACH partner-bank rejections drove 8 of 27 escalations and $1.9M of ARR exposure this month — more than every other cluster combined. The redundancy project kicked off in February has not yet shipped, and this is the third consecutive month this pattern has appeared.

## Pattern clusters

1. **ACH partner-bank rejections cause payout delays** — 8 escalations, $1.9M ARR at risk, mostly Mid-market and Enterprise.
- Root cause: process / vendor (single point of failure across multiple partner banks).
- **Recurring and escalating** — 4 in Feb, 6 in Mar, 8 in Apr.
- Owner: Payments Ops. Status: fix in flight (redundancy project), not yet shipped.

2. **Billing overage disputes from unclear pricing** — 5 escalations, $410K ARR, all SMB and Mid-market.
- Root cause: pricing communication (not the pricing itself — customers say the bill is fair once explained).
- **Recurring** — flat vs. March.
- Owner: Pricing + PMM. Status: pricing page rewrite in design, not yet shipped.

3. **SSO outages on enterprise tenants** — 3 escalations, $1.1M ARR, Enterprise only.
- Root cause: product (auth service does not gracefully degrade when IdP is slow).
- **New** — was not a pattern before April.
- Owner: Engineering — no specific fix scoped yet.

4. **Dashboard balance / reporting accuracy** — 3 escalations, $290K ARR, mixed segments.
- Root cause: product (caching layer).
- **Recurring but resolving** — all 3 closed within 48h.
- Owner: Engineering. Status: hotfix shipped, monitoring.

## One-offs (not a pattern)
- DiamondPoint billing dispute (already in cluster 2)
- One-off webhook misconfig at FleetMaster
- One legal escalation re: data residency

## What is and isn't working
- **ACH redundancy project** — escalation data does NOT yet support that it is moving the needle. Volume is up, not down. Either accelerate or communicate a revised timeline to affected accounts.
- **Pricing page rewrite** — too early to tell, ship date matters.
- **Self-serve billing FAQ (shipped March 15)** — modest signal: billing escalations did not grow this month despite overall escalation volume rising 30%. Keep, but it is not sufficient on its own.

## Asks for the executive team
- **Decision: accelerate or de-scope ACH redundancy project.** Current pace will not catch up to the trend. Either add 2 engineers for 4 weeks or accept and pre-communicate the risk to top 20 accounts.
- **Scope an SSO graceful-degradation fix** before this becomes May's headline. New pattern, Enterprise-only, $1.1M exposure already.
- **Approve a proactive credit policy** for ACH-delay-affected accounts. We are reactive on every one of these — losing trust on the slow recovery, not the original failure.

## Watchlist
- Two early signals of webhook delivery flakiness in the last week of April. Not a pattern yet — flag for May.
- One enterprise account (Coastal Freight) has now been in the escalation queue 3 months in a row with different root causes. May be a relationship issue rather than a product one — recommend a CSM-led account review.

Tips for best results

1Force a numeric threshold for what counts as a pattern (e.g., 3+ escalations with the same root cause). Otherwise the model will pattern-match on too little evidence.
2Always ask for ARR-at-risk per cluster. Executives reprioritize on dollars, not ticket counts — a 12-ticket SMB cluster matters less than a 3-ticket Enterprise one.
3Run this prompt monthly with the same structure. The 'new / recurring / escalating' classification only works if you have a baseline.
4Feed in known initiatives explicitly. Without that, the model will recommend things you are already doing — which destroys trust with the exec team.
5If a single account appears in multiple months with different root causes, that's a relationship signal, not a product signal. Watch for it explicitly.

Related prompts

Decide whether and how to escalate a support ticket

intermediate

Evaluate a support ticket against a structured escalation framework and generate a recommended action with rationale.

Customer Serviceescalationsupport-processtriage

Write a professional executive escalation email

intermediate

Generate a calm, professional escalation email to an internal executive stakeholder that summarizes a customer situation and requests specific action.

Customer Serviceescalationexecutivecustomer-success

Write a customer-facing incident postmortem

advanced

Generate a clear, honest customer-facing incident postmortem that explains what happened, what was done, and what's changing — in plain language.

Customer Servicepostmortemincidenttransparency

Need help implementing this prompt in your workflow?

Book a call

Use case

You are the head of escalations at {{company_name}}. You are preparing a monthly escalation review for the executive team. Your job is to look across {{escalation_count}} recent escalations and surface patterns — not retell each ticket. Inputs: - Time window: {{time_window}} - Escalation source: {{source}} (e.g., exec inbox, severity-1 tickets, churn-risk flag from CSM, social complaint surfaced to leadership) - Per-escalation record (provided in {{escalations}}): account name, ARR, segment, trigger event, root cause hypothesis, resolution status, days open, owner team - Known initiatives in flight: {{known_initiatives}} Produce an executive escalation review with: 1. **Headline (3 sentences max)** — what is the single most important pattern this month, in plain language an executive can repeat in a board meeting. 2. **Pattern clusters (3–6)**. For each: - Pattern name and one-line description - Number of escalations in the cluster, total ARR at risk, segments affected - Root-cause hypothesis (process, product, people, or pricing) — pick one primary - Whether this is **new**, **recurring**, or **escalating** vs. prior periods - Owning team and current status (no owner / owner identified / fix in flight / fix shipped, not yet validated) 3. **The one-offs** — escalations that do NOT fit a pattern. List briefly so they don't pollute the systemic view. 4. **What is and isn't working** — for each known initiative in {{known_initiatives}}, mark whether escalation data supports that it is moving the needle, with evidence. 5. **Three asks for the executive team** — specific, scoped decisions or resource asks, each tied to a pattern cluster. Not "we need to do better at X." 6. **Watchlist** — 2–3 emerging weak signals that are not yet patterns but could become next month's headline. Rules: - Distinguish a pattern (≥3 escalations with the same root cause) from a coincidence. - Quantify ARR at risk per cluster — leadership prioritizes by dollar exposure, not ticket count. - Do not blame individual reps or CSMs by name. Focus on systems. - If the data is insufficient to call something a pattern, say so explicitly. Do not over-claim.

Variables

{{{{company_name}}}}Replace with your {{company name}}

{{{{escalation_count}}}}Replace with your {{escalation count}}

{{{{time_window}}}}Replace with your {{time window}}

{{{{source}}}}Replace with your {{source}}

{{{{escalations}}}}Replace with your {{escalations}}

{{{{known_initiatives}}}}Replace with your {{known initiatives}}

Example

Input

company_name: Northwind Payments
escalation_count: 27
time_window: April 2026
source: combined (exec inbox + sev-1 tickets + CSM churn-risk flags)
escalations: |
  1. Acme Logistics — $480K ARR — Mid-market — payout delay 6 days — root cause: ACH file rejected by partner bank — owner: Payments Ops — open 9 days
  2. Brightline Co. — $120K ARR — SMB — dashboard showing wrong balance — root cause: caching bug — owner: Engineering — resolved
  3. Coastal Freight — $640K ARR — Enterprise — payout delay 4 days — root cause: ACH file rejected by partner bank — owner: Payments Ops — resolved
  4. DiamondPoint — $95K ARR — SMB — billing dispute on overage — root cause: pricing page unclear — owner: Pricing — open 14 days
  5. Evergreen Retail — $210K ARR — Mid-market — payout delay 5 days — root cause: ACH file rejected (different partner bank) — owner: Payments Ops — open 6 days
  [... 22 more, including 4 more ACH-related, 3 more billing-overage disputes, 2 SSO outages, and assorted one-offs ...]
known_initiatives: |
  - "ACH partner-bank redundancy project" (kicked off Feb, owner: Payments Ops)
  - "Pricing page rewrite" (in design, owner: PMM)
  - "Self-serve billing FAQ in Help Center" (shipped March 15, owner: Support)

Output

# Northwind Payments — Escalation Review, April 2026

## Pattern clusters

## One-offs (not a pattern)
- DiamondPoint billing dispute (already in cluster 2)
- One-off webhook misconfig at FleetMaster
- One legal escalation re: data residency

Tips for best results

1Force a numeric threshold for what counts as a pattern (e.g., 3+ escalations with the same root cause). Otherwise the model will pattern-match on too little evidence.

2Always ask for ARR-at-risk per cluster. Executives reprioritize on dollars, not ticket counts — a 12-ticket SMB cluster matters less than a 3-ticket Enterprise one.

3Run this prompt monthly with the same structure. The 'new / recurring / escalating' classification only works if you have a baseline.

4Feed in known initiatives explicitly. Without that, the model will recommend things you are already doing — which destroys trust with the exec team.

5If a single account appears in multiple months with different root causes, that's a relationship signal, not a product signal. Watch for it explicitly.