Support Ticket Label Assignment Prompt Template

This prompt is designed for support operations teams that need to route unstructured ticket text to the correct team, queue, or workflow at scale. It produces a primary category, subcategory, and priority flag from raw ticket descriptions, email threads, or chat transcripts. Use this prompt when you need consistent, auditable labels that feed downstream routing rules, analytics dashboards, or SLA enforcement logic. The prompt assumes you have a defined taxonomy of categories and subcategories. If your taxonomy changes frequently, you will need to update the [TAXONOMY] variable.

This prompt is not a replacement for a full ticket triage system. It does not draft replies, summarize customer history, or detect sentiment. It focuses exclusively on structured label assignment with confidence scoring. Before deploying, you must define your taxonomy, establish a confidence threshold below which tickets are routed to a human review queue, and log every classification with its confidence score and evidence span for auditability. A common failure mode is deploying this prompt without a human review path for low-confidence assignments, which can lead to misrouted tickets and SLA breaches.

Start by integrating this prompt into your ticket ingestion pipeline. When a new ticket arrives, pass the raw text to the prompt with your current taxonomy. Validate the output against your expected schema, and if the confidence score falls below your threshold, route the ticket to a manual triage queue. Monitor the distribution of categories and confidence scores over the first week to detect taxonomy drift or model confusion. Avoid using this prompt for real-time chat routing without a fallback classifier, as latency and model availability can vary.

This prompt template is designed to be pasted directly into your model's system message. It instructs the model to act as a support ticket classifier, ingesting unstructured ticket text and returning a structured JSON payload with a primary category, subcategory, priority flag, and a confidence score. The template uses square-bracket placeholders for your specific taxonomy, routing rules, and output constraints, making it adaptable to any support operations stack.

textCopy
You are a support ticket classification engine. Your task is to analyze the provided ticket text and assign structured metadata for routing and prioritization.

# TAXONOMY
Use the following controlled taxonomies for classification. Do not invent new categories.

Primary Categories:
[PRIMARY_CATEGORY_LIST]

Subcategories per Primary Category:
[SUBCATEGORY_MAP]

Priority Levels:
[PRIORITY_LEVEL_LIST]

# CLASSIFICATION RULES
1. Assign exactly one primary category that best matches the core issue described in the ticket.
2. Assign exactly one subcategory that is valid for the chosen primary category.
3. Assign a priority level based on the impact, urgency, and scope described in the ticket text. Use the following heuristics:
   [PRIORITY_HEURISTICS]
4. If the ticket text is ambiguous or contains conflicting signals, default to the lower-severity option and flag it for review.
5. If the ticket does not match any category, use the [OUT_OF_SCOPE_CATEGORY] label.

# CONFIDENCE SCORING
Provide a confidence score between 0.0 and 1.0 for each assigned label (category, subcategory, priority).
- 0.9-1.0: Clear, unambiguous match.
- 0.7-0.89: Probable match with minor ambiguity.
- 0.5-0.69: Best guess among several plausible options.
- Below 0.5: Flag for human review and set `needs_human_review` to true.

# OUTPUT SCHEMA
Return a single JSON object with the following structure. Do not include any text outside the JSON object.
{
  "ticket_id": "string",
  "primary_category": "string",
  "category_confidence": "number",
  "subcategory": "string",
  "subcategory_confidence": "number",
  "priority": "string",
  "priority_confidence": "number",
  "needs_human_review": "boolean",
  "review_reason": "string | null",
  "rationale": "string"
}

# CONSTRAINTS
[ADDITIONAL_CONSTRAINTS]

# INPUT
Ticket Text:
[INPUT]

To adapt this template for your environment, replace the placeholders with your operational specifics. [PRIMARY_CATEGORY_LIST] should be a comma-separated list like Billing, Login Issues, Bug Report, Feature Request. [SUBCATEGORY_MAP] requires a mapping, such as Billing: [Refund, Invoice Dispute, Payment Failure]. [PRIORITY_HEURISTICS] should encode your business rules, for example, P1 if core service is down for multiple users; P4 for cosmetic or minor requests. The [ADDITIONAL_CONSTRAINTS] placeholder can be used to inject rules like Never classify a ticket as P1 unless the text explicitly mentions a system outage. After pasting the prompt, immediately run it against a golden test set of 20-50 labeled tickets to verify that the model respects your taxonomy boundaries and that the confidence scores correlate with actual ambiguity. If the needs_human_review flag is triggered on more than 20% of tickets, re-evaluate your taxonomy granularity or confidence thresholds.

Integrating the Support Ticket Label Assignment prompt into a production workflow requires more than a single API call. The harness must enforce the output schema, handle low-confidence predictions, and route tickets to the correct downstream queue. A typical implementation wraps the LLM call in a service that validates the response against the expected JSON schema—primary_category, subcategory, priority_flag, and confidence_score—before any ticket is routed. If the model returns a malformed response, an unknown category, or a confidence score below the configured threshold, the harness should trigger a retry or escalate to a human review queue rather than silently misrouting the ticket.

Start by defining a strict output contract. Use a Pydantic model or JSON Schema validator to check that primary_category and subcategory exist in your approved taxonomy, priority_flag is one of [high, medium, low], and confidence_score is a float between 0.0 and 1.0. For model choice, a fast, cost-effective model like GPT-4o-mini or Claude Haiku is usually sufficient for this classification task, but you should log the model_id and prompt_version alongside every prediction for later audit. Implement a retry strategy with a maximum of two attempts: if the first call fails validation, resubmit with a repair prompt that includes the validation error message. If the second attempt also fails, log the failure, set the ticket's status to needs_review, and push it to a human triage queue. For high-volume support operations, consider batching multiple tickets into a single request with a structured array output to reduce API overhead, but ensure each ticket's labels remain independently traceable.

Observability is critical. Log every prediction—including the raw prompt, model response, validation result, and final assigned labels—to your observability platform. This lets you track label drift over time, identify categories where the model consistently underperforms, and build a golden dataset for future fine-tuning or prompt regression testing. Set up a periodic human audit: sample 5-10% of automated classifications, have a support lead review them, and feed corrections back into your evaluation set. Avoid the temptation to route tickets directly to downstream systems without a confidence gate; a misclassified P1 ticket sent to a low-priority queue is a customer-facing incident. The harness should treat the model's output as a strong suggestion, not a final decision, until it passes all validation and threshold checks.