Customer Escalation Detection Prompt

This prompt is a binary gate for support operations teams who need to identify high-risk customer interactions before they become churn events. It classifies a support conversation as either 'escalate' or 'normal' and provides the supporting signals, urgency classification, and a confidence score. Use this prompt inside a triage pipeline, a human-handoff workflow, or a real-time agent-assist system. It is designed for production systems that require a clear go/no-go signal, not a nuanced sentiment score. The prompt expects multi-turn conversation context and optional customer account metadata to make its determination.

The ideal user is an engineering lead or support operations manager integrating AI into an existing ticket or chat system. Required context includes the full conversation transcript, a customer account tier or health score if available, and a defined escalation policy. Do not use this prompt for general sentiment analysis, post-interaction surveys, or marketing churn prediction. It is not a replacement for a full customer health model. The prompt is optimized for low-latency, high-recall detection of immediate escalation risks—angry language, legal threats, repeated unresolved issues, or explicit cancellation intent. It will underperform on subtle, long-term dissatisfaction signals that lack explicit triggers in the conversation.

Before wiring this into a production system, define what 'escalate' means for your team: immediate human handoff, priority queue routing, or a manager callback. Calibrate the confidence threshold against a labeled dataset of at least 200 conversations, measuring both false positives (unnecessary escalations that waste agent time) and false negatives (missed escalations that lead to churn). The prompt includes a confidence_score field for threshold tuning. Start with a low threshold (0.6) to catch more risks, then adjust upward as you measure operational impact. Always log the full prompt response alongside the conversation ID for audit and threshold recalibration.

This prompt template is designed to be copied directly into your prompt layer and adapted by replacing the square-bracket placeholders with your actual inputs. It produces a structured binary escalate/normal decision along with sentiment signals, churn risk indicators, and urgency classification. The template assumes you have already assembled the conversation context, customer profile data, and any relevant policy or routing rules before invoking the model.

textCopy
You are an escalation detection classifier for a customer support operations team. Your task is to analyze a customer interaction and determine whether it requires immediate escalation to a human agent or specialist team.

## INPUT

### Conversation
[CONVERSATION]

### Customer Profile
[CUSTOMER_PROFILE]

### Escalation Policy
[ESCALATION_POLICY]

## OUTPUT SCHEMA

Return a single JSON object with exactly these fields:

{
  "decision": "escalate" | "normal",
  "confidence": 0.0-1.0,
  "urgency": "critical" | "high" | "medium" | "low",
  "primary_reason": "string summarizing the main escalation trigger",
  "sentiment_signals": {
    "frustration_level": "none" | "mild" | "moderate" | "severe",
    "anger_indicators": ["list of specific phrases or patterns"],
    "urgency_language": ["list of urgency-expressing phrases"]
  },
  "churn_risk_indicators": {
    "risk_level": "none" | "low" | "medium" | "high",
    "signals": ["list of churn-related phrases or behaviors"],
    "account_value_at_risk": "string or null"
  },
  "required_expertise": ["list of skills or departments needed"],
  "context_summary_for_agent": "concise 2-3 sentence summary for the human agent receiving the handoff"
}

## CONSTRAINTS

- If the customer explicitly requests a manager, supervisor, or escalation, decision MUST be "escalate".
- If the conversation contains threats of legal action, regulatory complaints, or safety concerns, decision MUST be "escalate" and urgency MUST be "critical".
- If the issue has been unresolved for more than [UNRESOLVED_THRESHOLD] turns or [TIME_THRESHOLD] hours, decision MUST be "escalate".
- If the customer mentions canceling their account, switching to a competitor, or requesting a refund above [REFUND_THRESHOLD], churn_risk_indicators.risk_level MUST be at least "medium".
- Do NOT escalate for routine questions, password resets, or documented self-service issues unless other escalation criteria are met.
- If confidence is below [CONFIDENCE_THRESHOLD], set decision to "escalate" as a safety measure.

## EXAMPLES

### Example 1: Clear Escalation
Input: Customer says "I've been transferred three times already. Get me your manager now or I'm closing my account."
Output: {"decision": "escalate", "confidence": 0.97, "urgency": "high", "primary_reason": "Explicit manager request combined with churn threat", ...}

### Example 2: Normal Interaction
Input: Customer says "Can you help me reset my password? I can't find the link in the email."
Output: {"decision": "normal", "confidence": 0.95, "urgency": "low", "primary_reason": "Routine self-service issue with no escalation triggers", ...}

### Example 3: Borderline Case
Input: Customer says "This is the fourth time this month this has happened. I'm getting really tired of this."
Output: {"decision": "escalate", "confidence": 0.72, "urgency": "medium", "primary_reason": "Repeated unresolved issue with growing frustration", ...}

## RISK LEVEL
[RISK_LEVEL]

If RISK_LEVEL is "high", prefer escalation when any ambiguity exists. If RISK_LEVEL is "low", only escalate on explicit policy matches.

To adapt this template, replace each square-bracket placeholder with your actual data. [CONVERSATION] should contain the full multi-turn transcript. [CUSTOMER_PROFILE] should include account tier, tenure, and recent support history. [ESCALATION_POLICY] should encode your team's specific routing rules. [UNRESOLVED_THRESHOLD], [TIME_THRESHOLD], [REFUND_THRESHOLD], and [CONFIDENCE_THRESHOLD] should be tuned to your operational tolerance for false positives versus missed escalations. [RISK_LEVEL] acts as a global sensitivity control. After adapting, run this prompt through your evaluation harness using the test cases described in the Testing and Evaluation section before deploying to production.

The Customer Escalation Detection Prompt is designed to sit inside a support operations pipeline, not as a standalone chatbot. It should be invoked after every customer message or after a configurable window of turns (e.g., every 3 messages) to detect emerging escalation signals. The prompt expects a multi-turn conversation history, customer metadata, and a defined output schema. Wire it as a stateless function call within your support platform's middleware, triggered before the agent sees the ticket or before an automated reply is sent. The model's binary escalate/normal decision should be treated as a high-precision signal, not a final authority—false negatives (missed escalations) are more costly than false positives, so tune thresholds accordingly.

For implementation, wrap the prompt in a service that handles input assembly, model invocation, output validation, and logging. First, assemble the [CONVERSATION_HISTORY] by pulling the last N turns from your ticket system, including timestamps and speaker roles. Inject [CUSTOMER_METADATA] such as account tier, churn risk score, and recent ticket volume from your CRM. Call the model with temperature=0 and response_format set to JSON to enforce the output schema. Validate the response against a strict JSON Schema that checks for the escalation_decision enum (escalate or normal), a confidence_score between 0 and 1, and a non-empty reasoning string. If validation fails, retry once with the validation error appended to the prompt as a correction hint. Log every decision, the raw conversation, and the model's reasoning to your observability platform for later analysis and threshold tuning.

For high-risk workflows, route all escalate decisions to a human review queue with a 5-minute SLA. Attach the model's reasoning and a summary of the detected signals (sentiment, churn risk, urgency) to the ticket so the human agent can verify quickly. Track false-positive and false-negative rates weekly by sampling decisions and comparing them to actual outcomes (e.g., churn within 7 days, customer satisfaction scores). Use these metrics to adjust the confidence_score threshold—start at 0.7 and lower it if you're missing real escalations. Avoid wiring this prompt directly to automated actions like refunds or account changes; the output should gate human attention, not trigger irreversible business logic.