Verified against ChatGPT · 2026-08-12
Classify a batch of tickets against your actual taxonomy, not a plausible-sounding invented one
Sorts a batch of raw support tickets into your existing category taxonomy, flagging anything that doesn't fit cleanly instead of forcing every ticket into the nearest label.
The prompt
Ready to copy — highlighted parts are example details you can swap.
You are classifying a batch of support tickets against a taxonomy that already exists — do not invent new categories that sound reasonable; use only what's provided, and flag what doesn't fit. TICKET BATCH 35 tickets from this week's queue, subject lines and first message only. EXISTING TAXONOMY Billing, Shipping & Delivery, Technical Issue, Account Access, Product Question, Feature Request, Complaint/Escalation. CLASSIFICATION RULES Single primary category only; if a ticket genuinely spans two, pick the one representing the customer's main ask, not the first topic mentioned. CONFIDENCE THRESHOLD Only assign a firm category if you're reasonably sure a human agent reading the same ticket would agree without hesitation; otherwise mark as low-confidence. HOW TO CLASSIFY For each ticket, assign exactly one primary category from Billing, Shipping & Delivery, Technical Issue, Account Access, Product Question, Feature Request, Complaint/Escalation. unless Single primary category only; if a ticket genuinely spans two, pick the one representing the customer's main ask, not the first topic mentioned. explicitly allows multi-labeling. Base the classification on what the customer is actually asking for or reporting, not on keywords that happen to appear — a ticket that mentions "refund" in passing while the actual ask is a shipping question should be classified as shipping, not refund. If a ticket doesn't cleanly fit any existing category with confidence at or above Only assign a firm category if you're reasonably sure a human agent reading the same ticket would agree without hesitation; otherwise mark as low-confidence., do not force it into the nearest-sounding one — mark it explicitly as low-confidence or uncategorized and state which two categories it was torn between and why. If you notice more than two or three tickets in the batch pointing at a real gap in the taxonomy (a genuine recurring issue type that has no matching category), name that gap explicitly as a suggestion, separate from the classification of individual tickets. WHAT NOT TO DO Do not invent a new category on the fly and assign tickets to it as if it already existed in the taxonomy — a suggested new category is a recommendation for a human to add, not something to classify against yet. Do not silently default ambiguous tickets to a catch-all "general" or "other" category without flagging that they were genuinely ambiguous rather than actually general. OUTPUT FORMAT A table: ticket ID/excerpt, assigned category, confidence (high/medium/low), and for anything below Only assign a firm category if you're reasonably sure a human agent reading the same ticket would agree without hesitation; otherwise mark as low-confidence. or genuinely ambiguous, a one-line note on what it was torn between. End with a short list of any suggested taxonomy gaps observed.
Customize
Optional — swap in your own details for the highlighted parts above.
Why this works
GPT-5.1 is fluent enough at surface pattern-matching that it will confidently assign a category based on a keyword match — "refund" appearing anywhere in a ticket pulling it toward a billing category — even when the actual customer intent, read in full context, points somewhere else entirely; explicitly instructing it to classify based on intent rather than keyword presence is what forces the deeper read instead of the shallow one. The instruction never to invent a plausible-sounding new category matters because the model has no inherent signal distinguishing "a category that already exists in this business's system" from "a category that sounds like it should exist," and without a hard constraint to use only the provided list, it will smoothly generate new labels that look legitimate but don't correspond to anything your ticketing system, reporting, or routing rules actually recognize — silently breaking downstream automation built on the real taxonomy. Requiring an explicit low-confidence flag rather than forced classification addresses a structural bias in how these models handle ambiguity: asked to pick one category, GPT-5.1 will pick one, confidently, even for a ticket that's genuinely 50/50 between two categories, because refusing to choose isn't the default behavior for a classification task — the confidence threshold and explicit permission to flag ambiguity is what unlocks the more honest "I'm not sure" response instead of a falsely decisive one. Separating individual ticket classification from taxonomy-gap suggestions keeps the model from quietly polluting the classification output with categories that don't exist yet, while still surfacing the genuinely useful signal that a real gap in the taxonomy exists — a distinction that matters operationally since one is immediately actionable data and the other is a proposal that needs human approval first.
What you get back
| Ticket | Category | Confidence | Note | |---|---|---|---| | #1182 'refund for wrong item shipped' | Shipping & Delivery | High | Mentions refund but core ask is wrong item shipped | | #1190 'can I get store credit instead of a refund' | Billing | Medium | Torn between Billing and Product Question — leaning Billing since ask is about payment handling | Suggested taxonomy gap: 4 tickets this batch ask specifically about data export/migration to a competitor tool — no existing category covers this; consider adding 'Account Migration'.
Verified against
ChatGPT GPT-5.1 · 2026-08-12
Changelog
- 2026-08-12 — Initial publish, verified against ChatGPT GPT-5.1.
Need this built into your business?
If a prompt isn't enough — what Scult builds, built and maintained for you — that's Scult's day job.
EXPLORE WHAT SCULT BUILDS
