Multi-Team Ticket Routing Prompt Template

This prompt is designed for operations and platform engineering teams that manage multiple support queues and need a reliable, auditable way to route incoming tickets. The core job-to-be-done is to replace brittle, rule-based routing with a few-shot classifier that learns your team taxonomy directly from historical examples. The ideal user is a technical lead or engineer who has access to a corpus of previously routed tickets and needs to integrate routing decisions into an existing ticketing API. You should use this prompt when your routing destinations are stable, your ticket volume justifies automation, and you require consistent, explainable decisions that include confidence scores and fallback rules.

This approach is not a fit for every situation. Avoid using this prompt if your team structure or routing taxonomy changes daily, as the few-shot examples will drift out of date and require constant maintenance. It is also not a replacement for a full NLU pipeline when you need to extract complex entities or perform multi-step reasoning before routing; this prompt focuses on classification, not deep ticket analysis. Finally, do not use this prompt in isolation for high-stakes tickets where a misroute could cause a security incident or a regulatory breach—always pair it with a human-in-the-loop review step for those cases. The prompt works best as a component in a larger triage system, not as the sole decision-maker.

Before you copy the template, gather at least 5–10 representative examples per routing destination, including edge cases where tickets could reasonably go to two different teams. These examples are the engine of the prompt; without them, the model will default to guessing. Once you have your examples, integrate the prompt into your application with a validation layer that checks the output schema, enforces your confidence threshold, and logs every decision for audit. The next section provides the copy-ready template and explains how to adapt the placeholders to your environment.

This prompt template implements a multi-team ticket routing classifier that uses few-shot examples to teach the model your routing logic. Instead of writing brittle rule descriptions, you provide labeled examples showing which team handles each type of ticket. The model returns a structured JSON routing decision with confidence scores, fallback handling, and evidence extraction. Replace every square-bracket placeholder with your organization's actual team definitions, routing rules, and example tickets before deploying.

textCopy
You are a support ticket routing classifier. Your job is to read an incoming support ticket and route it to exactly one team based on the ticket's content, urgency, and technical domain.

## TEAM DEFINITIONS
[TEAM_DEFINITIONS]

## ROUTING RULES
[ROUTING_RULES]

## CLASSIFICATION EXAMPLES
Here are labeled examples showing correct routing decisions:

[LABELED_EXAMPLES]

## INCOMING TICKET
Ticket ID: [TICKET_ID]
Subject: [TICKET_SUBJECT]
Body: [TICKET_BODY]
Customer Tier: [CUSTOMER_TIER]
Attachments: [ATTACHMENT_DESCRIPTIONS]

## OUTPUT INSTRUCTIONS
Return a JSON object with these fields:
- "routed_team": The team identifier from TEAM DEFINITIONS that should handle this ticket
- "confidence": A float between 0.0 and 1.0 indicating routing confidence
- "reasoning": A brief explanation of why this team was selected, citing specific evidence from the ticket
- "alternative_teams": An array of other teams that could potentially handle this ticket, ordered by relevance
- "requires_escalation": Boolean indicating whether this ticket needs immediate escalation
- "escalation_reason": If requires_escalation is true, explain why
- "missing_information": Array of questions that need answers before confident routing is possible

## CONFIDENCE THRESHOLDS
- If confidence is below [LOW_CONFIDENCE_THRESHOLD], route to [FALLBACK_TEAM] and flag for human review
- If confidence is between [LOW_CONFIDENCE_THRESHOLD] and [HIGH_CONFIDENCE_THRESHOLD], include alternative_teams and flag for optional review
- If confidence is above [HIGH_CONFIDENCE_THRESHOLD], route directly without review

## CONSTRAINTS
- Never route a ticket to a team not listed in TEAM DEFINITIONS
- If the ticket spans multiple domains, select the team best equipped to handle the primary issue
- For security incidents, always set requires_escalation to true regardless of confidence
- For [HIGH_PRIORITY_CUSTOMER_TIERS], apply [ESCALATION_OVERRIDE_RULES]
- If the ticket contains [SENSITIVE_DATA_INDICATORS], add a "data_handling_note" field to the output

To adapt this template for your organization, start by defining your team list in the [TEAM_DEFINITIONS] placeholder. Each team entry should include the team name, a unique identifier, their areas of responsibility, and any domain-specific keywords that help the model distinguish between similar teams. For example: billing_team: Handles invoice disputes, payment failures, subscription changes, and refund requests. Keywords: invoice, payment, charge, refund, billing cycle. Next, populate [LABELED_EXAMPLES] with at least 5-10 real or representative tickets per team, covering common cases, edge cases, and ambiguous cross-team scenarios. Each example should show the ticket content and the correct routing decision. Include negative examples where tickets were initially misrouted to teach the model boundary cases. Set [LOW_CONFIDENCE_THRESHOLD] to 0.6 and [HIGH_CONFIDENCE_THRESHOLD] to 0.85 as starting points, then adjust based on your tolerance for false positives versus missed escalations. The [FALLBACK_TEAM] should be a real team or queue that can manually triage uncertain cases—never route low-confidence tickets into a void.

Before deploying this prompt, build a validation layer in your application code that checks the model's JSON output against your team identifiers. Reject any routing decision that references a team not in your current team registry. Log every routing decision with the ticket ID, confidence score, and selected team for later evaluation. Set up a weekly review of low-confidence and fallback-routed tickets to identify gaps in your example coverage. If you notice consistent misrouting for specific ticket types, add those cases as new labeled examples rather than trying to fix the behavior through instruction changes alone. For high-risk domains like security incidents or legal matters, always require human approval before the routing decision takes effect, regardless of the model's confidence score.

The routing prompt is not a standalone artifact; it is a decision node inside a larger triage pipeline. The application layer is responsible for assembling the prompt with the correct [TICKET], [ROUTING_EXAMPLES], [TEAM_DEFINITIONS], and [CONFIDENCE_THRESHOLD] values before each call. The model returns a structured JSON payload containing the routed_team, confidence_score, fallback_teams, and evidence. Your harness must validate this output against the expected schema before acting on the routing decision. A common failure mode is treating the model's output as authoritative without checking whether the confidence score exceeds the configured threshold or whether the returned team ID actually exists in the current team roster.

Build the harness around a route_ticket function that accepts a ticket object and returns a routing decision. Inside this function, construct the prompt by injecting the ticket text, a curated set of few-shot examples drawn from a version-controlled example store, and the current team definitions from your routing configuration service. Call the model with response_format set to json_schema (or the equivalent structured output mode for your provider) using a schema that enforces routed_team: string, confidence_score: float, fallback_teams: array of strings, and evidence: string. After receiving the response, run three validation checks: (1) schema conformance, (2) team ID existence against the live team registry, and (3) confidence threshold comparison. If confidence is below the configured [CONFIDENCE_THRESHOLD], route to the designated fallback queue or a human triage review step. Log every routing decision with the ticket ID, model response, validation results, and final routing destination for later eval and drift analysis.

For high-volume production use, implement a lightweight retry strategy for transient model failures or malformed outputs. If the model returns invalid JSON or a team ID that does not exist, retry once with the same prompt. If the second attempt also fails, escalate to a human review queue and log the failure for prompt debugging. Do not retry more than twice on the same input; repeated failures indicate a prompt or example-set problem, not a transient error. Instrument the harness to emit metrics on routing latency, confidence score distributions, fallback rates, and human escalation rates. These metrics feed into your example drift detection and prompt regression testing workflows. Finally, version your prompt template and example sets together in the same repository as your harness code, and gate production deployments on eval runs that measure routing accuracy against a golden dataset of pre-classified tickets.