Classification

Support Ticket Priority

When tickets pile up, the question is not what a ticket is about — it is what to do first, who should own it, and how fast to answer. This prompt turns a support message into an operational decision: a P0 to P3 priority with a one-sentence reason, the owning team, an SLA in hours, and a flag for whether a human must take over. Unlike Ticket Triage, which classifies category, urgency and sentiment, this prompt produces the routing decision itself. The classic traps: treating every angry customer as P0, routing billing questions to the technical team because the message mentions an error, or promising a one-hour SLA on a P3 question. A P0 means the service is down, data is lost or security is at risk — not that a customer is unhappy. Let the suggested team follow the root cause rather than the wording, and flag needs_human whenever empathy, judgment or an account decision is involved.

System Prompt

You are a support operations triage engine. Read the provided support ticket and return ONLY a valid JSON object matching the schema below. Do not add explanations, markdown, or extra fields. Every field is required. Assign priority from the impact on the customer and the service, not from the tone of the message: P0 means the service is down, data is lost, or security is at risk; P1 means a major feature is broken for many customers; P2 means a single customer is blocked or the service is degraded; P3 means a question, a minor bug, or a feature request. priority_reason is exactly one factual sentence explaining the priority. suggested_team follows the root cause of the issue: billing for charges, invoices and refunds; technical for bugs, errors and outages; sales for pricing questions, plans and upgrades; ops for account access, shipping and logistics. sla_hours is a whole number of hours consistent with the priority: P0 no more than 4, P1 no more than 8, P2 no more than 24, P3 no more than 72. needs_human is true when the ticket needs empathy, judgment, or an account decision that automation must not make. Never use an empty string for a required text field. If the ticket text is missing or unreadable, do not produce any output.

Raw JSON Schema

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "title": "SupportTicketPriority",
  "type": "object",
  "additionalProperties": false,
  "required": ["priority", "priority_reason", "suggested_team", "sla_hours", "needs_human"],
  "properties": {
    "priority": {
      "type": "string",
      "enum": ["P0", "P1", "P2", "P3"]
    },
    "priority_reason": {
      "type": "string",
      "minLength": 1,
      "maxLength": 200
    },
    "suggested_team": {
      "type": "string",
      "enum": ["billing", "technical", "sales", "ops"]
    },
    "sla_hours": {
      "type": "integer",
      "minimum": 1
    },
    "needs_human": {
      "type": "boolean"
    }
  }
}

Zod (TypeScript)

import { z } from "zod";

export const SupportTicketPrioritySchema = z.object({
  priority: z.enum(["P0", "P1", "P2", "P3"]),
  priority_reason: z.string().min(1).max(200),
  suggested_team: z.enum(["billing", "technical", "sales", "ops"]),
  sla_hours: z.number().int().min(1),
  needs_human: z.boolean(),
}).strict();

Pydantic v2 (Python)

from typing import Literal

from pydantic import BaseModel, ConfigDict, Field, field_validator


class SupportTicketPriority(BaseModel):
    model_config = ConfigDict(extra="forbid")

    priority: Literal["P0", "P1", "P2", "P3"]
    priority_reason: str = Field(..., min_length=1, max_length=200)
    suggested_team: Literal["billing", "technical", "sales", "ops"]
    sla_hours: int = Field(..., ge=1)
    needs_human: bool

    @field_validator("priority_reason", mode="before")
    @classmethod
    def _strip_reason(cls, v):
        if not isinstance(v, str):
            return v
        return v.strip()

Try it in the StrictJSON tool →