Classify Support Tickets with AI
Billing, Technical, Account, How-To, Feature Request — ticket triage with definitions that decide the borderline cases for the model.
Sales, Support, Partnership, Press, Spam — route inbound email by intent, with a Strict "Other" so the weird ones reach a human.
Intent routing is where wrong labels hurt: a press inquiry routed to sales support dies quietly. This setup classifies inbound email into five intents under Strict ambiguity — if nothing clearly fits, the model returns "Other" instead of forcing the nearest label, because in routing, a forced wrong label is silent and an "Other" is visible. Definitions carry the borders (Support Request is "an existing customer asking for help" — prospects asking questions are Sales Inquiry), and high/medium/low confidence enables auto-routing the clear cases.
Classify before any human reads
The prompt runs on the raw email; quoted history and signatures don't derail a label decision the way they derail extraction.
Let Other be the safety lane
Everything the model can't confidently place lands in one reviewable bucket instead of five wrong ones.
Tune the Support/Sales border
"Existing customer" is the deciding phrase — if your prospects also ask product questions, the definitions are where you encode that.
Customer status decides it, not the topic. The label definitions fence 'Support Request' as 'an existing customer asking for help with the product,' while 'Sales Inquiry' is 'interest in purchasing, upgrading, or pricing details' — so a prospect asking a product question lands in Sales. If your prospects also raise support-style questions, rewrite those two definitions in the generated prompt to move that border before you run it.
It returns exactly 'Other' whenever no label clearly fits, under the Ambiguity Policy that 'a forced wrong label is not' a valid answer. That rule is deliberately routing-flavored: one 'Other' surfaces in a single reviewable bucket a human can catch, so treat it as your fallback lane rather than a classification failure. It never invents a label outside the six defined.
Hold the 'low' bucket for a person. The CONFIDENCE section attaches high, medium, or low to every label, where 'low' explicitly means 'the best available choice among the labels' rather than a real fit, and 'high' means the text 'unambiguously fits the definition.' Auto-route high and usually medium; review low. That level is self-reported by the model, not a computed score.
Read the 'label' and 'confidence' keys from one JSON object per email, exactly like {"label": "Sales Inquiry", "confidence": "high"}. The OUTPUT RULES forbid any text around it and ban markdown code fences, so a strict parser works directly. Labels come back verbatim from the defined values with no paraphrasing or abbreviation, so you can key a routing table on those exact strings.
Billing, Technical, Account, How-To, Feature Request — ticket triage with definitions that decide the borderline cases for the model.
The blocks a reliable classification prompt needs: defined labels, classification rules, edge-case rules, an ambiguity policy, and a confidence contract.
Praise, Complaint, Feature Request, Bug Report, Question — multi-label feedback categorization where one message can carry three signals.
Free text in, named fields out. The extraction prompt pattern that turns any unstructured text into consistent, parseable records.
Stop getting 'Sure, here is the JSON…' — the output-contract pattern that forces models to return only parseable JSON: schema, example, and a strict rule block.
The JSON won't parse and you can't see why. Deterministic cause-sniffing — trailing commas, single quotes, unclosed brackets — and the repair prompt that fixes it.
Build classification prompts that assign labels from a closed set — with label definitions and edge-case rules.
The full path to pages that rank at scale, not penalty bait — map the intents, build the data set, structure it, template the page, then QA before publishing hundreds.
Generate many intent-matched SEO pages from a template without the thin-content spam — map the search intents, define the page variables, build the template, and QA before publishing at scale.