Customer Escalation Risk Assessment Prompt Template

This prompt is designed for support operations teams who need to programmatically assess whether a customer message signals an impending escalation—such as a legal threat, regulatory complaint, executive reach-out, or churn risk from a high-value account. The primary job-to-be-done is triage: before a human agent even reads the ticket, the system should flag high-risk messages for priority routing, supervisor review, or specialized handling. The ideal user is an engineering lead or AI builder embedding this assessment into a support ticketing pipeline, where latency, consistency, and false-positive control matter more than conversational fluency.

Use this prompt when you have a stream of unstructured customer messages (email, chat, ticket body) and need a structured risk score with cited evidence. It is appropriate when your team has defined what 'escalation risk' means in operational terms—such as legal language, refund demands, regulatory mentions, or executive CCs—and can provide 3–5 labeled examples of high-risk and low-risk messages. Do not use this prompt for real-time chat interventions where the model must also generate a reply; it is an assessment-only classifier. Do not use it as a substitute for a legal review pipeline; it flags risk signals, not legal conclusions. If your definition of risk changes frequently, pair this prompt with an example refresh workflow to prevent drift.

The prompt template below is designed to be copied into your application harness. It expects you to supply labeled examples, a risk taxonomy, and a JSON output schema. Before deploying, you must validate the output against your schema, set a confidence threshold for auto-escalation, and route low-confidence or borderline cases for human review. Start by running the prompt against a golden dataset of 50–100 labeled tickets to measure precision and recall, then tune your examples and threshold before production traffic.

This prompt template is designed to be copied directly into your prompt management system, orchestration code, or evaluation harness. It uses square-bracket placeholders for all dynamic inputs, allowing you to swap in the customer message, risk categories, few-shot examples, and output schema without rewriting the core instruction. The template assumes you have already curated a set of labeled examples that demonstrate high-risk, medium-risk, and low-risk escalation signals specific to your product and support domain.

textCopy
You are a support triage specialist assessing customer escalation risk. Your task is to analyze the customer message and determine the likelihood that this issue requires escalation beyond standard Tier 1 support.

## RISK CATEGORIES
[RISK_CATEGORIES]

## FEW-SHOT EXAMPLES
Review these labeled examples to understand the risk signals and expected output format:

[EXAMPLES]

## CUSTOMER MESSAGE
[INPUT]

## OUTPUT SCHEMA
Return a valid JSON object matching this schema:

[OUTPUT_SCHEMA]

## CONSTRAINTS
- Cite specific phrases or signals from the customer message as evidence for your risk assessment.
- If the message contains mixed signals, explain which signals dominate and why.
- If you cannot determine risk with confidence, set risk_level to "uncertain" and explain what additional information would help.
- Do not invent details not present in the customer message.
- [CONSTRAINTS]

To adapt this template, start by defining your [RISK_CATEGORIES] as a clear list of risk levels with descriptions—for example, high_risk: immediate escalation required, medium_risk: monitor and escalate if unresolved within 24 hours, low_risk: standard handling. Populate [EXAMPLES] with at least three to five labeled input-output pairs per risk category, ensuring you include edge cases such as polite-but-urgent language, vague threats, and multi-issue messages. Define [OUTPUT_SCHEMA] as a concrete JSON structure with fields like risk_level, confidence_score, evidence_signals, recommended_action, and missing_information. Use [CONSTRAINTS] to add domain-specific rules, such as "if the customer mentions legal action, set risk_level to high_risk regardless of tone" or "if the customer references a previous unresolved ticket, increase risk by one level." Before deploying, run this prompt against a golden test set of at least 50 labeled messages and measure precision and recall for high-risk detection. If false positives exceed your operational threshold, add negative examples showing low-risk messages that contain superficially alarming language but do not warrant escalation.

This prompt is designed to be called as a single-turn classification step within a larger support operations pipeline. The typical integration point is immediately after a new customer message arrives and before any automated response is sent. The application layer should extract the customer message text, load any relevant account history or prior ticket context, and inject both into the [CUSTOMER_MESSAGE] and [CUSTOMER_CONTEXT] placeholders. The [ESCALATION_EXAMPLES] block should be populated from a curated example library maintained separately from the prompt template—this allows operations teams to add new risk signals without modifying the core prompt logic. The [OUTPUT_SCHEMA] placeholder should contain a strict JSON schema definition that the model must follow, including required fields for risk_score (integer 1-5), risk_signals (array of strings with evidence quotes), false_positive_check (boolean), and recommended_action (enum: auto_respond, flag_for_review, immediate_escalation).

After the model returns its response, the application harness must perform structured output validation before any downstream action is taken. Parse the JSON output and validate that risk_score is an integer between 1 and 5, that each risk_signal entry includes a direct quote from the customer message, and that recommended_action matches one of the allowed enum values. If validation fails, implement a single retry by re-invoking the prompt with the original inputs plus the validation error message appended to the [CONSTRAINTS] block—for example, 'Your previous output failed validation: risk_score must be an integer between 1 and 5. Please correct and resubmit.' If the retry also fails validation, log the failure and route the ticket to a human review queue with the raw model output attached for diagnosis. For high-risk scores (4-5), always require human confirmation before sending any customer-facing communication, regardless of validation success. Log every assessment with the model version, prompt version, input hash, output, validation result, and final routing decision for audit and drift monitoring.

Model choice matters for this workflow. Use a model with strong instruction-following and structured output capabilities—GPT-4o, Claude 3.5 Sonnet, or equivalent. Avoid smaller or older models that may struggle with the combination of few-shot example interpretation and strict JSON schema adherence. If latency is critical, consider using a faster model for initial classification and escalating ambiguous cases (risk scores 2-4) to a more capable model for re-assessment. Implement a confidence threshold: if the model's output includes internal uncertainty markers or the false_positive_check field is true, route to human review even if the risk score is low. The example library should be version-controlled alongside the prompt template, and any change to the example set should trigger a regression test run against a golden dataset of known escalation and non-escalation cases before deployment. Never allow this prompt's output to directly trigger account restrictions, refunds, or public responses without a human-in-the-loop approval step.