Confidence-Driven Routing Prompt for Support Tickets

This prompt is designed for support automation pipelines that classify incoming tickets and route them to specialized queues. Its primary job is to act as a confidence gate: when the model is uncertain about the classification, the ticket is flagged for human review instead of being auto-routed. Use this when the cost of misrouting a ticket—such as sending a billing dispute to a general FAQ queue—is higher than the cost of a human review. The prompt produces a structured routing decision containing a destination queue, a confidence score, and a boolean escalation flag, making it directly consumable by downstream workflow engines.

Do not use this prompt for real-time chat routing where latency is measured in milliseconds. The structured output and reasoning steps add overhead better suited for asynchronous ticket processing. This prompt assumes you have defined destination queues, a configurable confidence threshold, and a downstream system that can consume the structured routing decision. Before deploying, you must map your actual support taxonomy to the [QUEUE_DEFINITIONS] placeholder and set the [CONFIDENCE_THRESHOLD] to a value calibrated against your historical misrouting tolerance. A common starting threshold is 0.85, but this should be tuned using a golden dataset of pre-labeled tickets to balance auto-routing rates against misrouting risk.

This prompt is most effective when integrated into a broader human-in-the-loop workflow. The escalation flag should trigger a review queue where human agents see the original ticket, the model's top predicted classes with scores, and a pre-formatted decision prompt. Avoid using this prompt in isolation without eval checks. You should regularly test routing accuracy and escalation rates against a held-out test set to detect drift in model behavior or changes in ticket distribution. If your support taxonomy changes, update the [QUEUE_DEFINITIONS] and re-run your calibration suite before promoting the new prompt version to production.

This prompt template is the core instruction set for a confidence-driven routing system. It takes a support ticket as input and produces a structured routing decision. The model is instructed to classify the ticket, estimate its own confidence in that classification, and then make a routing decision based on a configurable threshold. The output is a strict JSON schema, making it suitable for direct integration into an automated triage pipeline. Before using this template, you must define your support queues, the classification taxonomy, and the minimum confidence score required for automated routing.

textCopy
You are a support ticket routing classifier. Your task is to analyze a support ticket and produce a routing decision.

## INPUT
[TICKET_CONTENT]

## CLASSIFICATION TAXONOMY
[SUPPORT_QUEUES]

## INSTRUCTIONS
1.  **Classify:** Determine the single most appropriate destination queue for this ticket from the provided taxonomy.
2.  **Self-Assess:** Estimate your confidence in this classification on a scale from 0.0 (no confidence) to 1.0 (certain). Briefly state your reasoning.
3.  **Route:** Compare your confidence score to the auto-resolution threshold of [CONFIDENCE_THRESHOLD].
    *   If confidence is **at or above** the threshold, the routing decision is "autonomous_route".
    *   If confidence is **below** the threshold, the routing decision is "escalate_to_human".

## CONSTRAINTS
*   Do not answer the ticket. Only classify and route.
*   If the ticket content is empty or nonsensical, classify it as "unclassifiable" with a confidence of 0.0.
*   Your reasoning for the confidence score must be a concise, single sentence.

## OUTPUT_SCHEMA
You must respond with a single, valid JSON object matching this exact schema:
{
  "classification": {
    "destination_queue": "string",
    "confidence_score": "number",
    "confidence_reasoning": "string"
  },
  "routing_decision": "autonomous_route" | "escalate_to_human",
  "escalation_context": "string" // A brief summary of the ticket and the reason for escalation. Use an empty string if routing autonomously.
}

To adapt this prompt for your production system, replace the placeholders with your specific context. [TICKET_CONTENT] should be the full text of the incoming support request. [SUPPORT_QUEUES] must be a clear, structured list of your internal routing destinations, such as 'Billing, Technical Support, Account Management, Refunds'. The [CONFIDENCE_THRESHOLD] is a critical business parameter; start with a value like 0.85 and adjust based on your tolerance for misrouted tickets versus the cost of human review. The output is designed to be parsed by an application. If routing_decision is "autonomous_route", your system should forward the ticket to the destination_queue. If it is "escalate_to_human", your system should post the entire JSON payload, including the escalation_context, to a human review queue. Always validate the JSON output against the schema before acting on the decision to prevent downstream failures from malformed model responses.

This prompt is designed to be called synchronously within a ticket processing pipeline, typically after initial data extraction and before any automated response or agent assignment. The application layer must supply the full ticket payload—including subject, body, customer metadata, and any prior conversation context—as the [INPUT]. The [CONSTRAINTS] placeholder should be populated with a machine-readable routing policy: a list of valid destination queues, the minimum confidence threshold for auto-routing (e.g., 0.85), and any mandatory escalation categories (e.g., billing disputes, account closures). The [OUTPUT_SCHEMA] must enforce a strict JSON contract with fields for destination_queue, confidence_score, escalation_flag, and escalation_reason. Do not rely on the model to remember the schema; always include it inline or via structured output API parameters.

After receiving the model response, the application must validate the output before acting on it. Check that destination_queue is a non-empty string matching one of the allowed queues, that confidence_score is a float between 0 and 1, and that escalation_flag is a boolean. If escalation_flag is true, verify that escalation_reason is present and non-empty. If validation fails, retry once with the same prompt and append the validation error to the [CONSTRAINTS] as a correction hint. If the retry also fails, log the failure and route the ticket to a designated manual_review queue with the raw model output attached for diagnosis. For high-risk ticket categories defined in your routing policy, consider requiring a second-pass verification: run the prompt again with a slightly different system message and compare the two routing decisions. If they disagree, escalate to human review regardless of confidence score.

Model choice matters here. Use a model with strong instruction-following and structured output support, such as GPT-4o or Claude 3.5 Sonnet, and enable JSON mode or structured outputs if the provider supports it. Set temperature to 0 to minimize variance in routing decisions. Log every routing decision with the ticket ID, model version, prompt version, raw input, raw output, validation result, and final routing destination. This audit trail is essential for debugging misroutes and for demonstrating routing consistency to stakeholders. For production observability, emit a metric on the ratio of auto-routed to escalated tickets; a sudden spike in escalations may indicate a model behavior change, a data distribution shift, or a prompt regression. Wire this metric into your alerting system with a threshold tuned to your historical baseline.