SLA Breach Risk Routing Prompt

This prompt is for operations engineers building proactive breach detection into routing middleware. Its job is to assess whether current queue depth, agent availability, and elapsed time create an SLA breach risk and to determine the correct escalation path. Use this prompt when you need a deterministic, auditable risk score that controls queue reordering, agent allocation, or management escalation before a breach occurs. The prompt assumes you have real-time queue metrics, agent status data, and defined SLA targets available as structured inputs. It is designed to be called synchronously within a routing decision loop, where its output directly influences the next action the system takes.

Do not use this prompt for post-breach reporting, root-cause analysis, or customer-facing breach notifications. It is not designed to explain why a breach happened or to generate a narrative summary for stakeholders. It is also not a substitute for a full capacity planning model; it makes a point-in-time risk assessment based on current state, not a long-term forecast. The prompt works best when the inputs are fresh (seconds old, not minutes) and when the SLA targets are expressed as concrete time thresholds. If your queue metrics are sampled infrequently or your agent status data is stale, the risk score will be unreliable and may trigger false escalations.

Before deploying this prompt, ensure you have a well-defined escalation policy that the prompt's output can map to. The prompt will return a risk level and a recommended action, but your application layer must enforce what those actions mean—such as reordering a queue, paging an on-call engineer, or moving a ticket to a manager's review bucket. Pair this prompt with a validation layer that checks for missing or out-of-range input fields, and log every risk assessment with its inputs and outputs for auditability. In high-stakes environments, consider adding a human approval step for critical risk scores before automated actions are taken.

This prompt template is designed to be embedded in a routing middleware function. It takes a support ticket and its current operational context—queue depth, agent availability, and elapsed time—and produces a structured risk assessment. The output is not a conversational reply; it is a machine-readable JSON object that your application can use to re-prioritize a queue, trigger a PagerDuty alert, or move a ticket into an escalation workflow. The template uses square-bracket placeholders for all dynamic inputs, making it safe to copy directly into your codebase as a string literal or a version-controlled prompt asset.

textCopy
You are an SLA breach risk assessment engine. Your only job is to analyze the provided ticket and queue context and return a structured JSON risk assessment. Do not generate conversational text, apologies, or markdown formatting outside the JSON block.

## INPUT
[TICKET_DETAILS]

## QUEUE CONTEXT
[QUEUE_CONTEXT]

## OUTPUT SCHEMA
Return a single JSON object with the following fields:
- "breach_risk": string, one of "NONE", "LOW", "MEDIUM", "HIGH", "IMMINENT"
- "risk_factors": array of strings, the specific factors contributing to the risk level (e.g., "queue_depth_exceeded", "sla_window_95_percent_consumed", "no_available_agents")
- "recommended_action": string, one of "standard_routing", "priority_queue", "immediate_escalation", "on_call_alert"
- "action_rationale": string, a brief, evidence-based explanation for the recommended action
- "escalation_target": string or null, the specific team or on-call group to alert if escalation is recommended

## CONSTRAINTS
- Base your assessment strictly on the provided ticket and queue context. Do not infer information not present.
- The SLA window is defined in the queue context. If it is missing, treat the risk as "LOW" and note the missing data in "risk_factors".
- If the ticket is already in a "breached" or "resolved" state, set "breach_risk" to "NONE" and "recommended_action" to "standard_routing".
- Do not recommend escalation for normal queue fluctuations. A "HIGH" or "IMMINENT" risk requires a specific, time-bound threat of missing the SLA target.

To adapt this template, replace [TICKET_DETAILS] with a structured string containing the ticket's priority, status, creation timestamp, and current SLA target. Replace [QUEUE_CONTEXT] with a snapshot of the current operational state: the number of tickets ahead in the queue, the number of available agents with the right skills, and the average handle time for this ticket type. In production, these placeholders should be populated by your application layer, not by the model. The output schema is intentionally strict; you should validate the returned JSON against this schema before acting on the recommended_action. A common failure mode is the model returning a plausible but incorrect escalation_target. Always cross-reference this field against your live on-call rotation before dispatching an alert.

This prompt is designed to sit inside a routing middleware layer, not as a standalone chatbot. It should be invoked when a support ticket, incident, or task enters a queue and the system needs to decide whether to escalate based on SLA breach risk. The prompt expects structured input—current queue depth, agent availability, elapsed time, SLA target, and ticket priority—and returns a structured escalation decision. Do not call this prompt on every queue event; instead, trigger it on a scheduled heartbeat (e.g., every 60 seconds for active queues) or on ticket arrival when the queue is already above a warning threshold. This prevents unnecessary model invocations during normal operations and keeps latency predictable.

Wire the prompt into a decision function that first hydrates the required variables from your queue monitoring system, ticket system, and workforce management tool. The function should construct the prompt payload, call the model with a low temperature (0.0–0.2) for deterministic routing decisions, and parse the JSON output. Validate the output against a strict schema: the escalation_decision field must be one of escalate, warn, or no_action; the confidence field must be a float between 0.0 and 1.0; and the reasoning field must be a non-empty string. If validation fails, retry once with the same payload and a note in the system prompt that the previous output was malformed. If the second attempt also fails, log the failure and default to a safe fallback—typically warn with a human review flag—rather than silently dropping the event. For high-severity queues (e.g., Sev1 incidents), always require a human to confirm any escalate decision before it triggers paging or notification workflows. This human-in-the-loop gate prevents alert fatigue from model over-escalation during normal queue fluctuations.

Log every invocation with the input variables, model output, validation result, and final routing action. This audit trail is critical for tuning the prompt over time and defending routing decisions during incident reviews. Monitor for over-escalation by tracking the ratio of escalate decisions to actual SLA breaches over a rolling 7-day window; if the prompt escalates more than 20% of tickets that do not breach SLA, recalibrate the thresholds or add a cooldown period. Also monitor for under-escalation by tracking missed SLA breaches where the prompt returned no_action. Use these metrics to drive prompt version updates, not to silently override the model. Finally, do not use this prompt as the sole arbiter of SLA compliance—it is a risk detection signal, not a replacement for deterministic SLA timers and queue monitors that should run independently in your infrastructure.