Intent taxonomy: the label set a support router can act on
In short
An intent names what the requester wants, and it belongs in the taxonomy only if exactly one routing action follows from it: a queue, an owner, a target, or an automation. A label nothing downstream consumes is a reporting category wearing an intent's clothes, and it will be applied inconsistently within a fortnight because nothing corrects it.
Key takeaways
- An intent is defined by the routing action it triggers, not by how well it describes the ticket.
- Intent, product area, tag and reason code are 4 fields, written at different times by different actors.
- Labels must be mutually exclusive and cover the queue, which requires an explicit unclear class the router may choose.
- The right label count is whatever the routing table needs. Splitting a label that routes to the same place buys nothing.
- Write the routing table first: any label with a blank action column is a reporting category, not an intent.
An intent is the controlled value a router sets on an inbound ticket to say what the person wants. Its test is mechanical: read the label alone, with no ticket in front of you, and name the queue it goes to, the owner it lands on and the target it inherits. If you cannot, it is not an intent.
Most taxonomies fail not because a model classifies badly but because half the labels were invented to make a report look complete, and nothing downstream consumes them. Unused values get applied by intuition, 2 agents disagree, and the field stops being data.
Intent, product area, tag and reason code are 4 different fields
They get merged into one dropdown constantly, and the merge is what makes taxonomies rot. Each answers a different question, at a different moment, for different machinery.
| Field | Question it answers | Written when | Cardinality |
|---|---|---|---|
| Intent | What does this person want done? | On arrival, by the router | Exactly 1 |
| Product area | Which part of the system is involved? | On arrival or on first read | 1, occasionally 2 |
| Tag | What was observed about this ticket? | Any time, by anyone | Many |
| Reason code | Why did it end the way it did? | At close, by the agent | Exactly 1 |
The last row is the one people fight about. A reason code is written at the end, by someone who now knows the answer, which makes it a different instrument — the constraints are in what a cancellation reason-code set has to do. Where triage output belongs, fields or tags, is settled in custom fields against tags.
The routing table is the definition
Write the table before the label set, not after. Any row you cannot complete is a label that should not exist. An illustrative set for a B2B product, kept deliberately small:
| Intent | Queue and owner | First-reply target | Automation it triggers |
|---|---|---|---|
| billing.invoice_query | Billing, shared rota | Next business day | Attach the last 3 invoices to the ticket |
| billing.payment_failed | Billing, shared rota | 4 business hours | Pull the gateway decline reason onto the record |
| access.cannot_log_in | Tier 1, front of queue | 1 business hour | Post identity-provider status as an internal note |
| bug.suspected_defect | Tier 2, duty engineer | 4 business hours | Open a linked issue with the environment block |
| howto.product_question | Tier 1, round robin | 4 business hours | Suggest the 3 best-matching articles |
| account.cancel_or_downgrade | Retention, named owner | 1 business hour | Notify the account owner before any reply is sent |
| unclear | Triage, human | 1 business hour | None. This label exists to prevent a guess |
Two columns are load-bearing. The owner must resolve to a person or a staffed rota, because a label routing to an empty role stalls silently. And the target means nothing unless everyone agrees what starts and stops the clock — see when the first-reply clock starts and pauses.
Mutual exclusivity, and the unclear label that protects it
Two properties matter more than granularity. Labels must be mutually exclusive, so no ticket has 2 correct answers, and they must cover the queue, so none has zero. Overlapping labels produce disagreement between annotators, which becomes disagreement between the model and its reviewers, and reads as an accuracy problem it is not.
- A ticket with 2 intents has 1 primary. Route on it, record the rest as tags, and pick the primary by which unanswered request would make the customer write again.
- A sub-intent is worth creating only when the child changes the action. Splitting one label into 6 topics that all route to Tier 1 with the same target buys reporting detail and costs annotation consistency.
- Every label needs a written boundary sentence. "Payment failed covers a declined charge on an existing subscription; a first purchase that will not complete is access, not billing." Without it, 2 reasonable people label the same ticket differently.
Where the taxonomy stops
An intent set governs tickets that reached the queue, which is not the same as tickets that arrived. Suspension and spam rules run first, and real customers land there routinely — the population in the suspended queue nobody reads. A stable-looking taxonomy can simply be blind to what never got through.
There is no correct label count, only the count your routing table needs — for most teams smaller than the list they maintain today. Arriving at one from evidence rather than a workshop is a separate method: deriving a label set from 90 days of tickets.
If you cannot write the routing rule for a label in one sentence, that label is not ready to exist.
A support ticket intent taxonomy is the smallest piece of schema deciding whether anything else in ticket and inbox triage can be automated at all. Building one is ordinary AI agents and automation work inside our SaaS and customer support practice; what changes once it is live is in agents in production.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is the difference between a ticket category and an intent?
A category describes the ticket; an intent instructs the system. Categories are organised around how the business thinks — product lines, teams, report headings — while intents are organised around what happens next. The difference shows up when you write the automation: a category rarely maps to exactly 1 action, and an intent must.
How many intents should a support taxonomy have?
As many as your routing table has distinct actions, commonly between 8 and 20 for a single product. The count is an output, not a target. If 2 labels route to the same queue with the same owner, target and automation, they are 1 label with a reporting distinction that belongs in a tag.
Can one ticket have more than one intent?
It can carry several requests, but it gets exactly 1 routing intent. Pick the one whose non-answer would make the customer write again, route on that, and record the rest as tags. Allowing 2 intents to be equally authoritative is how a ticket ends up owned by 2 teams and worked by neither.
- intent classification
- triage
- taxonomy
- routing
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- First-reply SLA timer: start, pause and breach are three different eventsA first-reply SLA is three settings, not one, and most breach reports that look like a staffing problem are one of the three configured differently from how the team believes.definition
- The AI add-on billed for more resolutions than your team saw tickets closedTwo very different problems produce the same gap: a counting definition you never read, and real traffic you were not measuring. The join tells you which one you have.diagnostic
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation