Customer Support Escalation Routing Prompt

This prompt is a routing and escalation decision engine for support operations teams and AI engineers building automated ticket triage systems. Its job is to analyze an incoming support ticket and produce a structured routing decision: whether the ticket requires human intervention, what priority it should receive, which expertise tags apply, and a concise handoff summary for the assigned agent. It is not designed to draft customer-facing replies, suggest solutions, or diagnose technical issues. Its sole output is a machine-readable escalation payload that sits between your intake layer and your human agent queue.

Use this prompt when you already have a defined support taxonomy, an agent skill matrix, and an SLA framework with clear priority definitions. The prompt expects these as input context so it can map ticket attributes to the correct escalation path. It works best embedded in a middleware service that receives raw ticket data, calls the LLM, validates the structured output against a schema, and then routes to the correct queue or agent. Do not use this prompt for real-time chat triage where latency requirements are sub-second, for drafting customer responses, or for tickets that require deep technical root-cause analysis. It is a classification and routing tool, not a resolution tool.

Before deploying, you must calibrate the priority scoring against your historical ticket data and test routing accuracy across your ticket categories. Common failure modes include over-escalation of routine issues when the taxonomy is too coarse, under-escalation of subtle severity signals, and hallucinated expertise tags that don't match your actual agent skills. Plan to run this prompt against a golden dataset of 200-500 labeled tickets and measure routing accuracy, priority agreement with human labelers, and handoff summary completeness before putting it in a production routing path. If your support volume exceeds 10,000 tickets per month, consider pairing this prompt with a lightweight classifier model for the initial binary human-vs-automation decision to control LLM costs.

This template is the core instruction set you will send to the model for every escalation routing decision. It is designed to be copied directly into your prompt management system, IDE, or orchestration layer. Every square-bracket placeholder must be replaced with live data from your ticketing system before the model call. Do not ship this template with unresolved placeholders; your application code should perform the substitution.

textCopy
You are a support escalation router. Your job is to analyze a customer support ticket and produce a structured routing decision. You do not reply to the customer. You do not resolve the issue. You only route.

## INPUT
[TICKET_CONTENT]

## CONTEXT
- Customer tier: [CUSTOMER_TIER]
- Customer history summary: [CUSTOMER_HISTORY_SUMMARY]
- Current SLAs and contractual obligations: [SLA_CONTEXT]
- Available support queues and their expertise: [QUEUE_DEFINITIONS]

## CONSTRAINTS
- If the ticket contains a security vulnerability report, a legal threat, or an executive escalation request, you must route to the [CRITICAL_ESCALATION_QUEUE] regardless of other factors.
- If the ticket mentions personally identifiable information (PII), payment data, or credentials, flag it for redaction review before routing.
- Do not route a ticket to a queue that lacks the required expertise tags.
- If no single queue matches all required expertise, recommend the closest match and flag the gap.
- If the ticket is ambiguous and you cannot determine the required expertise, recommend routing to the general triage queue and request clarification.

## OUTPUT_SCHEMA
Return a single JSON object with these fields:
- "recommended_queue": string (must match a queue name from QUEUE_DEFINITIONS)
- "priority_score": integer (1-5, where 5 is critical and 1 is low)
- "required_expertise_tags": array of strings (from the defined expertise taxonomy)
- "routing_confidence": float (0.0 to 1.0)
- "context_summary": string (a 2-3 sentence summary of the issue for the human agent)
- "escalation_flags": array of strings (any flags that require special handling, e.g., "PII_DETECTED", "LEGAL_THREAT", "EXECUTIVE_ESCALATION", "AMBIGUOUS_REQUEST")
- "gap_notes": string or null (if expertise gaps exist, explain what is missing)

## EXAMPLES
[FEW_SHOT_EXAMPLES]

## RISK_LEVEL
[HIGH_STAKES_ROUTING: true/false]

Adapt this template by replacing each placeholder with data from your system. [TICKET_CONTENT] should contain the full ticket body, including subject, description, and any attachments transcribed to text. [QUEUE_DEFINITIONS] must be a structured list of available queues with their expertise tags, such as billing: ["payments", "refunds", "subscriptions"]. [FEW_SHOT_EXAMPLES] should include at least three input-output pairs that demonstrate correct routing for common, ambiguous, and critical cases. When [HIGH_STAKES_ROUTING] is true, the model should apply stricter confidence thresholds and prefer escalation over autonomous routing.

Before deploying this prompt, validate that your substitution logic handles missing or malformed inputs gracefully. If [CUSTOMER_HISTORY_SUMMARY] is empty, the model should still produce a routing decision based on the ticket content alone. If [QUEUE_DEFINITIONS] is incomplete, the model should flag the gap rather than hallucinate a queue name. Always log the raw prompt, the model response, and the final routing decision for audit and debugging. For high-stakes routing scenarios, require a human reviewer to confirm the model's recommendation before the ticket is assigned.

This prompt is designed to sit inside a support ticketing pipeline, not as a standalone chat interface. The application layer should call the model after a ticket is created or updated, passing the full ticket body, customer history, and any recent agent notes as [INPUT]. The model returns a structured routing decision that the application must validate before acting on it. Do not use this prompt for real-time chat routing without first buffering the conversation into a complete ticket payload—partial conversations produce unreliable priority scores and expertise tags.

Wire the prompt into a pre-processing step that assembles the [INPUT] from your ticketing system (Zendesk, Intercom, Salesforce, etc.). Include: ticket subject, body, customer tier, recent order IDs, and the last three agent notes if available. The application should then call the model with a strict JSON output schema and validate the response before routing. Validation checks must include: priority_score is an integer between 1-5, required_expertise is a non-empty array of strings matching your internal skill taxonomy, escalation_reason is a non-empty string, and context_summary does not exceed 300 tokens. If validation fails, retry once with the same input and an added [CONSTRAINTS] block that includes the specific validation error. If the second attempt fails, route to a default queue and log the failure for review.

For model choice, prefer models with strong JSON mode and instruction-following (GPT-4o, Claude 3.5 Sonnet, or Gemini 1.5 Pro). Set temperature=0 to maximize routing consistency. If you are processing high volumes (>1000 tickets/hour), consider a smaller model (GPT-4o-mini, Claude 3 Haiku) with a confidence threshold check: if the model's self-reported confidence is below 0.85, escalate to a human reviewer before routing. Log every routing decision with the full prompt, response, validation status, and final queue assignment. This log is essential for auditing routing accuracy and detecting prompt drift over time.

Human review gates should be triggered when: (a) priority_score is 4 or 5, (b) required_expertise includes 'billing' or 'security', (c) the customer tier is 'enterprise' or 'vip', or (d) the model's confidence is below your threshold. In these cases, post the routing recommendation to a review queue rather than auto-assigning. The reviewer sees the context_summary, escalation_reason, and the original ticket, and can override the routing decision. Track override rates by reason—if a specific expertise tag or priority level is consistently overridden, update your prompt examples or skill taxonomy.

What to avoid: Do not use this prompt to auto-close tickets or send customer-facing messages. The routing decision is an internal operational signal, not a customer communication. Do not skip validation—unchecked model outputs will eventually produce malformed JSON, hallucinated expertise tags, or missing priority scores that break downstream automation. Do not route based on priority_score alone without considering required_expertise; a low-priority ticket that requires a scarce skill (e.g., 'integrations') may still need immediate attention from the right team.