Sentiment-Triggered Escalation Prompt for Customer Interactions

This prompt is designed for support platform engineers who need a deterministic, auditable trigger to move a conversation from an automated AI agent to a human support representative based on the customer's emotional state. Its core job is to analyze a single customer message for extreme negative sentiment, frustration signals, or churn risk indicators, and output a structured escalation decision. The ideal deployment point is mid-conversation, injected after each customer turn, allowing the system to react before the interaction deteriorates further. You should use this prompt when the cost of a missed escalation (customer churn, public complaint) is higher than the operational cost of a human review, and when you need a consistent, loggable reason for every handoff decision.

This prompt is not a general-purpose sentiment analyzer. Do not use it for post-interaction analytics, batch processing of transcripts, or generating customer satisfaction scores. It is explicitly tuned for extreme negative signals and is intentionally insensitive to mild frustration or neutral sentiment to prevent over-escalation. The prompt requires the full conversational context leading up to the current message to distinguish genuine escalation triggers from sarcasm, benign venting, or strong language that is not directed at the company. Without this context, the model cannot reliably differentiate a customer saying 'this is terribly broken' from one saying 'I had a terrible day, but your product helped.' Always provide at least the last three conversation turns as context.

Before implementing this prompt, define your operational thresholds for handoff timing and ensure your routing middleware can act on the structured output. The prompt is designed to produce a decision, not to generate the message sent to the customer. Pair it with a separate handoff message prompt or a static message template. Avoid deploying this prompt in isolation without an evaluation harness that measures both false-positive escalations (sending easy cases to expensive humans) and false negatives (missing a customer who is about to churn). Start by running it in shadow mode against historical transcripts to calibrate your risk tolerance before enabling live automated handoffs.

This prompt template is designed to be wired directly into a customer interaction pipeline—such as a support chat, email intake, or voice transcript processor. It accepts the raw customer message and a configurable risk threshold, then returns a JSON object containing an escalation decision, the sentiment classification, extracted evidence phrases, and a recommended handoff timing. The template uses square-bracket placeholders that your application must replace at runtime. The output schema is strict, so configure your model to return JSON and validate the result against the expected fields before acting on the escalation decision.

textCopy
You are a sentiment analysis classifier for customer support interactions. Your only job is to detect extreme negative sentiment that requires human intervention.

## INPUT
Customer message: [CUSTOMER_MESSAGE]

## CONFIGURATION
Escalation threshold: [ESCALATION_THRESHOLD] (1-10 scale, where 10 is maximum severity)
Context window: [CONTEXT_WINDOW] (number of previous messages to consider, if available)
Previous messages: [PREVIOUS_MESSAGES]

## CLASSIFICATION RULES
1. Analyze the customer's emotional state, not the factual content of their complaint.
2. Distinguish between:
   - Benign venting or sarcasm (do NOT escalate)
   - Constructive frustration with clear resolution path (do NOT escalate unless severity exceeds threshold)
   - Extreme anger, threats, despair, or churn signals (escalate)
3. If the customer mentions canceling, legal action, regulatory complaints, or harm to themselves or others, escalate regardless of threshold.
4. If sarcasm is detected, reduce the severity score by 2 points before comparing to threshold.
5. Do not escalate based on profanity alone. Profanity plus a clear threat or extreme emotion is required.

## OUTPUT SCHEMA
Return ONLY valid JSON with this exact structure:
{
  "escalate": boolean,
  "severity_score": number (1-10),
  "sentiment_category": "extreme_negative" | "frustrated" | "neutral" | "positive" | "sarcastic",
  "primary_emotion": string,
  "evidence_phrases": [string],
  "churn_risk": "high" | "medium" | "low" | "none",
  "recommended_action": "immediate_handoff" | "next_available" | "monitor" | "none",
  "reasoning": string,
  "sarcasm_detected": boolean
}

## CONSTRAINTS
- Do not include any text outside the JSON object.
- Evidence phrases must be exact quotes from the customer message.
- If severity_score is below [ESCALATION_THRESHOLD], escalate must be false.
- If churn_risk is "high" or sentiment_category is "extreme_negative", escalate must be true.

To adapt this template for your application, replace [CUSTOMER_MESSAGE] with the raw text from the current interaction turn. Set [ESCALATION_THRESHOLD] to an integer between 1 and 10 based on your operational tolerance—start at 7 for most support workflows and calibrate downward if you are missing genuine escalations. The [CONTEXT_WINDOW] and [PREVIOUS_MESSAGES] fields are optional but recommended for chat-based systems; pass the last 3–5 messages to catch escalation patterns that build across turns. After receiving the model response, validate that the JSON parses correctly, that severity_score is within range, and that the escalate boolean is consistent with the score and threshold. If validation fails, retry once with the same prompt before falling back to a default escalation to a human reviewer. For high-stakes domains such as healthcare or finance, always route escalated items to a human reviewer regardless of model confidence.

The sentiment-triggered escalation prompt is not a standalone chatbot response—it is a classification middleware component that sits between your customer interaction layer and your escalation routing system. In a typical deployment, every customer message passes through this prompt before any automated reply is generated. The prompt receives the raw message text plus optional conversation context, and returns a structured JSON payload containing the escalation decision, sentiment evidence, and recommended handoff timing. This payload then drives downstream routing: if escalate is true, the interaction is queued for human review with the provided priority level; if false, the message proceeds to your automated response pipeline. The implementation harness must treat this prompt as a deterministic gate, not a conversational agent, and should enforce strict output validation before any routing decision takes effect.

Wire the prompt into your application with a dedicated service function that accepts customer_message (string, required) and conversation_history (array of message objects, optional). The function should call your LLM with temperature=0 and a low top_p value to minimize variance in classification decisions. Parse the response against a strict JSON schema that validates the escalate boolean, sentiment_label enum (positive, neutral, negative, extreme_negative), evidence_spans array of quoted text excerpts, confidence_score float between 0 and 1, and recommended_handoff_timing enum (immediate, within_5_minutes, within_1_hour, next_business_day). If parsing fails, retry once with the same prompt plus the raw model output and a repair instruction: 'The previous output was not valid JSON matching the required schema. Return ONLY the corrected JSON object.' If the retry also fails, log the failure and escalate the interaction by default—a failed classification on a potentially distressed customer must default to human review, not silent automation. For high-throughput systems, implement a circuit breaker that temporarily routes all traffic to human review if the classification failure rate exceeds 5% in a rolling 5-minute window.

Model choice matters here. Use a model with strong instruction-following and JSON output capabilities, such as Claude 3.5 Sonnet, GPT-4o, or Gemini 1.5 Pro. Avoid smaller or older models that may struggle with the nuanced distinction between benign venting and genuine escalation triggers. If you are running this prompt at high volume, consider a two-tier architecture: a fast, cheap model for initial sentiment screening (flagging only extreme_negative cases), and a more capable model for secondary review of borderline cases where the confidence score falls between 0.4 and 0.7. Log every classification decision with the full prompt, model response, parsed output, and final routing action. These logs are essential for auditing escalation patterns, tuning thresholds, and defending against claims of missed escalations. Store them in a structured format that your observability stack can query—include trace_id, customer_id, timestamp, model_version, prompt_version, raw_response, parsed_output, validation_passed, and routing_decision. For regulated environments, retain these logs for the same duration as your customer interaction records.

Before deploying, run the prompt through a calibration test suite that includes known escalation cases (explicit threats, cancellation demands, repeated frustration signals), non-escalation cases (sarcasm, benign venting, constructive criticism, neutral inquiries), and adversarial edge cases (mock escalation language embedded in jokes, sentiment expressed in non-English phrases, frustration directed at a third party rather than your service). Measure false-positive rate (over-escalation) and false-negative rate (missed escalations) against your business tolerance. A reasonable starting target is <5% false-positive and <1% false-negative, but adjust based on the cost of unnecessary human review versus the cost of missing a distressed customer. Implement a post-escalation feedback loop: when a human reviewer resolves an escalated case, capture whether they agreed with the escalation decision. Use this feedback to periodically recalibrate your confidence thresholds and update your few-shot examples in the prompt template. Never silently retrain or fine-tune on this feedback without human review of the patterns—automated threshold adjustment can drift toward over-escalation if reviewers are lenient or under-escalation if reviewers are overloaded.