Enterprise Account Escalation Prompt Template

This prompt is designed for support engineers and platform builders who need to route enterprise customer requests to named support engineers, Technical Account Managers (TAMs), or executive escalation paths. It validates the account tier, checks for bypass conditions, and produces a structured escalation decision with handling instructions. Use this prompt when a standard queue dispatch is insufficient and the request requires a deterministic, auditable escalation that respects commercial agreements and customer segmentation logic.

The ideal user is an AI platform engineer embedding this prompt into a support routing middleware or a support operations lead configuring an escalation workflow. Required context includes the customer's account tier, contract entitlements, request severity, and any active bypass flags (e.g., executive outreach, security incident, or SLA breach risk). The prompt expects these inputs to be resolved before invocation—it does not perform account lookup or contract parsing itself. Instead, it operates on pre-resolved fields passed in via the [INPUT] placeholder, making it suitable as a decision step within a larger pipeline that already handles data retrieval and normalization.

Do not use this prompt for general ticket triage, non-enterprise accounts, or cases where the escalation path is already hardcoded in application logic. It is not a replacement for a rules engine when the routing decision is simple and static. Avoid using it when the account tier is unknown or ambiguous—resolve tier ambiguity upstream first. For high-risk domains such as healthcare or finance, always require human review of the escalation decision before execution, and log the full prompt context and output for audit purposes.

This prompt template is designed to be wired directly into a support routing middleware layer. It expects live account context and ticket data from your application and returns a deterministic escalation decision. The template uses square-bracket placeholders for all dynamic fields—replace these with values from your CRM, ticketing system, or account database before sending the prompt to the model. The output schema is strict JSON so downstream dispatch logic can act on the result without parsing ambiguity.

textCopy
You are an enterprise support routing classifier. Your job is to analyze an incoming support request and the associated account context, then produce a structured escalation decision.

## INPUT
- Account Tier: [ACCOUNT_TIER]
- Contract SLA: [CONTRACT_SLA]
- Account Health Score: [ACCOUNT_HEALTH_SCORE]
- Named Support Engineer: [NAMED_SUPPORT_ENGINEER]
- TAM Assignment: [TAM_ASSIGNMENT]
- Executive Sponsor Flag: [EXECUTIVE_SPONSOR_FLAG]
- Request Category: [REQUEST_CATEGORY]
- Request Severity: [REQUEST_SEVERITY]
- Request Summary: [REQUEST_SUMMARY]
- Elapsed Time Since Submission: [ELAPSED_TIME]
- Current Queue Depth: [CURRENT_QUEUE_DEPTH]

## CONSTRAINTS
- Do not escalate standard-tier accounts to named support engineers unless the request severity is Critical.
- Do not bypass the TAM for enterprise accounts unless the executive sponsor flag is true.
- If account health score is below [AT_RISK_THRESHOLD], flag for retention-aware handling.
- If elapsed time exceeds [SLA_BREACH_THRESHOLD] minutes, escalate immediately regardless of queue depth.
- If the request category is [EXCLUDED_CATEGORY], route to standard queue with a note that this category is out of scope for enterprise escalation.

## OUTPUT SCHEMA
Return ONLY valid JSON with this structure:
{
  "escalation_decision": "escalate" | "standard_queue" | "tam_review" | "executive_escalation",
  "target_assignee": string | null,
  "priority_override": boolean,
  "sla_breach_risk": "high" | "medium" | "low",
  "retention_flag": boolean,
  "handling_instructions": string,
  "bypass_reason": string | null,
  "confidence": "high" | "medium" | "low"
}

## EXAMPLES
Input: Enterprise tier, Critical severity, executive sponsor true, elapsed 45 minutes.
Output: {"escalation_decision": "executive_escalation", "target_assignee": "[TAM_ASSIGNMENT]", "priority_override": true, "sla_breach_risk": "high", "retention_flag": false, "handling_instructions": "Notify TAM and executive sponsor immediately. Bypass standard queue.", "bypass_reason": "Executive sponsor flag active with critical severity.", "confidence": "high"}

Input: Standard tier, Low severity, no executive sponsor, elapsed 10 minutes.
Output: {"escalation_decision": "standard_queue", "target_assignee": null, "priority_override": false, "sla_breach_risk": "low", "retention_flag": false, "handling_instructions": "Route to standard support queue. No escalation required.", "bypass_reason": null, "confidence": "high"}

## RISK LEVEL
[RISK_LEVEL]

Adapt this template by replacing each placeholder with live data from your application context. For high-risk deployments where incorrect escalation could breach contractual SLAs or frustrate strategic accounts, add a human review step before the dispatch action executes. Log every routing decision with the full input context and model output so operations teams can audit escalation patterns and tune thresholds over time.

Before shipping, run this prompt against a golden test set that includes edge cases: trial accounts with enterprise-like request categories, recently downgraded accounts, accounts with missing TAM assignments, and requests that arrive during grace periods. Validate that the JSON output parses correctly and that the escalation decision matches expected behavior for each test case. If the model returns low confidence, route to a human review queue rather than silently dispatching.

This prompt is designed to sit between your ticket ingestion layer and your queue dispatch logic. It should be invoked after account tier detection and entitlement verification have already run, receiving their structured outputs as part of the [ACCOUNT_CONTEXT] input. The prompt's job is to decide whether standard routing is sufficient or whether an enterprise escalation path—named support engineer, TAM, or executive escalation—must be activated. Because this decision can bypass normal queues and consume expensive human resources, the implementation harness must enforce strict validation on both the input data and the output decision before any routing action occurs.

Wire the prompt into your application as a synchronous decision step with a mandatory validation layer. The application must: (1) assemble [TICKET_DETAILS], [ACCOUNT_CONTEXT] (including tier, SLA, health score, and VIP flags), and [REQUEST_TYPE] from upstream systems; (2) invoke the model with the prompt template; (3) parse the JSON output and validate that escalation_required is a boolean, escalation_path matches an allowed enum of your actual escalation queues, and justification contains specific evidence from the input context rather than generic language; (4) if validation fails, retry once with the validation errors injected into [CONSTRAINTS]; (5) if the retry also fails, default to a human-review queue with the failed output attached. Log every decision—including the full prompt, model response, validation result, and final routing action—for audit and prompt iteration. For high-risk accounts where the escalation decision could trigger executive visibility, insert a human approval step before the escalation is actually dispatched, regardless of model confidence.

Model choice matters here. Use a model with strong instruction-following and structured output capabilities. If your platform supports it, use structured output mode (JSON mode with a schema) rather than relying solely on the prompt's [OUTPUT_SCHEMA] instructions. This reduces parsing failures. Set temperature low (0–0.2) to minimize creative variation in justification text. Implement a circuit breaker: if more than 5% of decisions in a rolling window fail validation or require human review, pause automated escalation routing and alert the platform team. The most common production failure mode is the model recommending escalation for accounts that appear enterprise-like based on company name or domain but lack the actual contract tier to justify it—your validation layer should cross-check the model's account_tier_used field against the authoritative tier from your account system, not just trust the model's extraction.