JSON Schema for support ticket triage structured output
A strict JSON Schema (draft 2020-12) for classifying an inbound support ticket: category, priority, sentiment, language, summary, extracted IDs, human-handoff flag and routing queue. Every field is required and described.
File in Product by AISkillHub Library
What it does
Ticket triage is one of the most common first LLM features, and the most common bug in it is free-form output that downstream code has to guess at. This schema gives you a fixed contract: the model must return exactly these fields with these allowed values, and your routing code can trust the shape.
**Fields**
- `category`: billing, account_access, bug_report, how_to, feature_request, cancellation, security, other - `priority`: urgent, high, normal, low, each defined in the field description so the model applies them consistently - `sentiment`: angry, frustrated, neutral, positive (tone as written, separate from severity) - `language`: ISO 639-1 code - `summary` and `customer_ask`: one-sentence problem statement and the explicit request - `entities`: order IDs, invoice IDs, product names and verbatim error messages, copied exactly, empty arrays when absent - `needs_human` plus `needs_human_reason` (string or null) - `suggested_queue`: billing, technical, accounts, success, security
**Why it is shaped this way**
- Every property is listed in `required` and every object sets `additionalProperties: false`. That is what OpenAI's strict structured outputs mode requires, and it keeps output predictable for any provider. - Optional values are expressed as `["string", "null"]` instead of omitted keys. - Descriptions carry the definitions. Models read field descriptions, so the rules live next to the field instead of in a separate prompt. - It sticks to basic keywords (`type`, `enum`, `properties`, `required`, `items`, `additionalProperties`) that structured output features widely support.
**Using it**
Pass it as the schema for OpenAI structured outputs, or as the `input_schema` of a single tool when calling Claude with tool use and forcing that tool. Validate the result with any draft 2020-12 validator before acting on it. `ticket-triage.example.json` is a valid instance you can use in tests.
**What it will not do**
It does not include your own product names, queues or SLAs. Edit the enums to match your help desk before use. The top-level `$schema`, `title` and `description` keys are metadata; if an API rejects one of them, remove it.
How to use it
1. Copy `schemas/ticket-triage.schema.json` and `schemas/ticket-triage.example.json` into your project. 2. Edit the `category`, `priority` and `suggested_queue` enums to match your help desk. Keep the field descriptions in sync with your own definitions. 3. Use it with your provider: - OpenAI: pass the schema as a strict JSON schema response format (name it, for example, `ticket_triage`). - Claude: define one tool, for example `record_triage`, with this schema as its `input_schema`, and force that tool with `tool_choice`. 4. Put the ticket text in the user message, wrapped in a tag such as `<ticket>...</ticket>`, and tell the model to fill the schema from it. 5. Validate every response against the schema in code before routing, and route to a human when validation fails. 6. Add `ticket-triage.example.json` to your unit tests so schema edits that break consumers are caught.
Files
Save each file at the path shown, relative to your project root.