1 November 2026 · Conversational AI

Intent Taxonomy Design for Conversational AI: A Practical Guide

How to design an intent taxonomy for conversational AI: mine real conversations, set levels, separate overlapping intents, handle out-of-scope requests and test.

An intent taxonomy is the structured list of things your customers are trying to do, organised into levels so an AI agent can recognise each one and route it correctly. Good design comes down to five jobs: build the list from real conversations, give it a shallow and consistent structure, keep neighbouring intents distinguishable, plan for requests that fit nowhere, and measure and revise it on a schedule. This guide walks through each job in order, with an example for an Australian enterprise contact centre.

TL;DR

Start from real conversation logs and business tasks, not a brainstorm in a meeting room. Cluster similar customer requests, then name the clusters.
Keep the structure shallow: a few top-level goals, sub-intents beneath them, and a clear rule for what belongs where.
Overlapping intents are the main cause of misrouting. Rewrite labels until a new reviewer can tell them apart without guessing.
Always design an out-of-scope path and an escalation rule. A taxonomy that forces every message into a box will misroute the ones that matter most.
Test coverage and accuracy before launch, then review the taxonomy on a fixed rhythm as products, policies and customer behaviour change.

What an intent taxonomy is, and how it differs from a classifier
Step 1: Mine real conversations to find your intents
Step 2: Structure the taxonomy into levels
Step 3: Set granularity and separate overlapping intents
Step 4: Design for out-of-scope, unclear and sensitive requests
Step 5: Evaluate whether the taxonomy works
Step 6: Review and update on a schedule
A worked example: a multi-site health clinic group
Perspective: why we build taxonomies around the conversation, not the product
Put your taxonomy to work on an Australian-hosted platform
FAQ
Sources

What an intent taxonomy is, and how it differs from a classifier

The taxonomy and the classifier are two different things, and teams often blur them. The taxonomy is the map: the set of intents, their definitions and how they relate. The classifier is the model or rule set that reads an utterance and picks a spot on that map. You can swap the classifier for a better one without touching the taxonomy. If the map is muddled, though, no classifier will rescue it.

The idea has formal roots. RFC 9316, published by the RFC Editor in October 2022, treats intent classification as a methodology for organising intents. It proposes a taxonomy so that researchers and stakeholders share a common understanding of intent users, intent types and intent solutions. That document is about network intent rather than customer service, but the discipline carries over. Define who is expressing the intent, what kind of intent it is, and what solution answers it.

The same RFC describes the output of classification as a structured set of categories covering solution, user type, intent type, scope, abstraction and lifecycle requirements. For a contact centre, you can translate those dimensions into practical questions:

Who is asking? A new customer, an existing customer, a patient, a tenant, a third party.
What do they want? Information, a transaction, a change, a complaint.
How big is the request? One step, or a multi-step workflow.
How abstract is the label? A broad goal such as “manage appointment” or a specific action such as “reschedule appointment”.
How long will the label stay valid? A permanent need, or a seasonal or campaign-driven one.

If your taxonomy answers those five questions consistently for every intent, it is already ahead of most first drafts.

Step 1: Mine real conversations to find your intents

The most common mistake is to write intents from the inside out. Product managers list what the business offers, and the taxonomy ends up mirroring the org chart. Customers do not speak in org-chart terms. They say “I got charged twice and nobody rang me back”, which touches billing, a complaint and a callback in one breath.

Start with the evidence you already hold:

Call transcripts and voicemail
Live chat and SMS threads
Email subject lines and first paragraphs
Ticket categories agents have chosen (useful, but treat them as a hypothesis, since agents often pick the nearest drop-down option)

Research supports mining logs rather than guessing. Mitra et al. (2022) describe identifying intents and flows from conversation logs, often by clustering similar customer utterances. Another academic pipeline extracts intent-span candidates with an extractive question-answering model, then applies density-based clustering followed by top-level hierarchical clustering to build an intent taxonomy. The 2023 DSTC 11 work on intent induction frames the goal as extracting a set of distinctly meaningful intents and producing a training set for an intent classifier.

You do not need a research team to apply the principle. A workable routine looks like this:

Pull a representative sample across channels, weeks and customer types. Avoid sampling only complaints or only the busiest day.
Strip the opening pleasantries and keep the sentence that states the need.
Group similar requests, by tool or by hand.
Name each group with a verb and an object, such as “cancel booking” or “dispute charge”.
Have two people review the groups independently and note where they disagree.

Those disagreements are your first signal of overlap. We come back to them below. If you want help turning raw dialogue into themes, a conversation analysis approach to identifying intents shows how question phrasing clusters into recognisable needs.

A note on voice channels: spoken requests are longer, less tidy and more likely to contain several intents at once than typed ones. Sample voice and text separately before you merge them, so that you do not design only for the tidy typed version.

Step 2: Structure the taxonomy into levels

Once you have clusters, decide how they nest. The aim is a structure a human can hold in their head and an agent can traverse in one or two decisions.

Keep the hierarchy shallow

Taxonomy advice from other fields applies here too. Guidance on mobile taxonomies, for example, recommends limiting the number of levels. Two levels carry most conversational use cases: a top-level goal and a specific intent beneath it. Add a third level only when an intent branches into workflows that differ in a way the agent must act on, such as different verification rules.

A sound pattern looks like this:

Level	Purpose	Example
Domain	The area of the business	Appointments
Intent	What the customer wants done	Reschedule appointment
Sub-intent	A variation that changes the workflow	Reschedule within 24 hours
Slots	Details the agent must collect	Date, time, practitioner, location

Note the difference between a sub-intent and a slot. If the same workflow runs and only a detail changes, it is a slot. If the next step, the permission check or the escalation path changes, it is a sub-intent.

Write a definition for every label

Each intent needs a one-line definition, two or three example utterances, and at least one example of what it is not. The “not” example does most of the work in preventing overlap. For instance, “Update contact details” is not “Verify identity”, even though the second often precedes the first.

Record the metadata RFC 9316 hints at

Borrowing from the RFC’s dimensions, store a few fields against each intent: which user types can trigger it, how abstract it is, which system or team resolves it, and whether it is permanent or tied to a campaign. This metadata is what lets you retire or merge labels later without guesswork.

Four metadata fields recorded for each intent

Step 3: Set granularity and separate overlapping intents

How fine should labels be? The honest answer is: as fine as the action differs, and no finer. If two intents lead to the same response and the same back-end action, merge them. If one label hides two different actions, split it.

Overlap is the harder problem. A 2025 ACL paper on dialogue intent classification notes that classifiers face many possible intents and substantial semantic overlap, and presents dynamic label refinement as a way to make labels more distinguishable and interpretable. In plain terms: if a label name is vague, the model and your reviewers will both guess. Clear, specific names help.

Practical tests for overlap:

The two-reviewer test. Give 50 mixed utterances to two people. If they disagree on more than a handful, the labels need rewriting.
The swap test. If you could rename two labels and nobody would notice, they are probably one intent.
The next-action test. If two intents trigger the same next action, merge them.
The multi-intent check. Decide in advance how the agent handles a message with two intents. A common rule is to handle the one that is time-critical or higher risk first, then confirm the second.

Vague and multi-part requests are not unique to chatbots. A QUT-published study of web search intent classified queries hierarchically as informational, navigational and transactional. It found that vague or multifaceted queries require probabilistic classification. The lesson for your design is to expect confidence scores rather than certainties, and to decide what the agent does at low confidence.

Step 4: Design for out-of-scope, unclear and sensitive requests

Every taxonomy is incomplete the day it launches. Requests outside the predefined classes are called out-of-scope (OOS) in the research literature, and few-shot and zero-shot systems aim to predict utterances into that OOS category rather than forcing a wrong match. You should build that category in deliberately.

A practical fallback ladder:

High confidence, in scope: proceed with the workflow.
Medium confidence: ask one clarifying question that distinguishes the two likeliest intents.
Low confidence or out of scope: say what the agent can help with, and offer a human handover.
Sensitive trigger words or situations: escalate regardless of confidence.

That last rung matters in regulated sectors. In healthcare, a caller describing urgent symptoms should never be treated as a routine booking. In collections, a customer who mentions hardship or distress needs a human. Write these as explicit escalation intents with their own priority, not as exceptions buried in a prompt. Your clinical, legal and compliance owners should sign off the trigger list, not the AI team alone.

Log every OOS and every low-confidence conversation. They are the raw material for your next revision.

Step 5: Evaluate whether the taxonomy works

Test the taxonomy before you test the model. A study on using large language models to generate, validate and evaluate taxonomies assesses taxonomies on comprehensiveness, consistency, clarity, accuracy and conciseness. It judges comprehensiveness partly by how often instances fall into “Other”, and accuracy by inter-coder reliability. The authors also use human experts and assessors to verify quality.

You can turn that into a simple scorecard:

Measure	What to check	Warning sign
Comprehensiveness	Share of real conversations landing in “Other” or OOS	The share keeps rising after launch
Consistency	Do similar utterances get the same label?	Reviewers split on the same message
Clarity	Can a new agent apply the definition unaided?	Frequent “what does this mean?” questions
Accuracy	Agreement between two independent labellers	Low agreement on specific pairs of intents
Conciseness	Are there near-duplicate labels?	Two intents with identical workflows

The DSTC 11 work offers a complementary view: the quality of induced intents is judged by the coverage and accuracy of the resulting intent classifier. So once labelled data exists, measure per-intent accuracy and coverage, not just one headline number. A single average can hide a badly confused pair of intents that carry real risk.

Also track business outcomes by intent: containment (resolved without a human), handover rate, repeat contact within a set window and customer satisfaction. If an intent has high accuracy but a high repeat-contact rate, the label is right and the workflow behind it is wrong. If you survey customers after interactions, our overview of automated satisfaction surveys covers how to collect that signal.

Step 6: Review and update on a schedule

A taxonomy is a living document. RFC 9316 notes that classification tables can be updated by adding or removing solutions, intent users or intent types for future scenarios, applications or domains, and that new categories can be identified as domains or applications emerge or concerns arise. That is a good model for governance.

A lightweight process that works for most enterprises:

Monthly: review the top OOS and low-confidence conversations and the intents with the highest handover rates.
Quarterly: run the overlap tests again, merge or split labels, and retire intents with near-zero volume.
On every change: when a product, fee, policy or regulation changes, update affected intents, definitions and escalation rules before the change goes live.
Version everything: keep a change log, so you can tell whether a shift in accuracy came from the model or the taxonomy.

Assign one named owner. Taxonomies owned by everyone drift, because each team adds its own labels.

When you add a new channel, such as email or SMS beside voice, revisit the taxonomy before you copy it across. The same intent is phrased differently in each channel, and some intents only appear in one. Our guides to how email AI automation works and AI voice agent integration steps cover how those channels differ in practice. For outbound email, check your obligations under the Spam Act first.

A worked example: a multi-site health clinic group

This is an illustrative example, not a client result. Imagine a clinic group whose phones fill up during flu season. Mining a month of call transcripts might produce clusters like these:

Domain	Intent	Sub-intent	Handled by
Appointments	Book appointment	New patient / existing patient	AI agent
Appointments	Reschedule or cancel	Within 24 hours / longer notice	AI agent
Information	Opening hours and location	n/a	AI agent
Information	Fees and billing questions	n/a	AI agent with human handover option
Results and prescriptions	Request callback about results	n/a	Human, AI collects details
Urgent	Reports urgent symptoms	n/a	Immediate escalation
Fallback	Out of scope or unclear	n/a	Clarify once, then handover

Three design decisions show the principles at work. “Reports urgent symptoms” is a top-priority intent that overrides everything else. “Request callback about results” is deliberately not automated: the AI collects the details, and a clinician decides what happens. And “Reschedule or cancel” has a sub-intent split only because late cancellations follow a different policy, which is the next-action test in action.

The same method applies to a collections team. Intents might include “promise to pay”, “dispute the debt”, “request a payment plan” and “report hardship”, with the last one routed to a human. Where your sector has regulatory requirements, have your compliance team review the taxonomy as well as the scripts.

Perspective: why we build taxonomies around the conversation, not the product

In our experience, the taxonomy decides more about an AI agent’s behaviour than the model does. When a deployment disappoints, the cause is usually a label set that mirrors internal departments rather than the way customers talk, or an escalation rule that lives in someone’s head instead of in the design.

That is why our platform is built around multichannel agents that share context. Voice, SMS, email and live chat run on one platform with CRM integration and contextual memory, so an intent recognised on a call can carry through to the follow-up message instead of starting again. A taxonomy designed once can serve every channel, with channel-specific phrasing handled underneath.

We also think intent design is inseparable from where the data lives. The conversations you mine to build a taxonomy are some of your most sensitive records, especially in healthcare, finance and professional services. Our platform is hosted in Australia as a private cloud, we hold SOC 2 certification, and our design is built to keep your data under your control. You can improve your taxonomy from real conversations without sending them offshore.

Our advice to enterprise teams: start narrow, with the five to ten intents that account for most of your volume, define escalation first, and widen the taxonomy once the numbers justify it.

Sowrabh

Put your taxonomy to work on an Australian-hosted platform

Once your intents are defined, you need an agent that can act on them across the channels your customers already use. Our Voice, Live Chat, SMS and Email AI Agents are designed to work with your CRM, keep context between interactions and run on Australian-hosted private cloud infrastructure.

Conversational AI

If your sector has specific requirements, see how we approach healthcare, banking and finance and debt collection. Where data must stay inside your own environment, ask about our on-premises deployment. Taking a taxonomy into production is also a pipeline question, which our AI deployment pipeline guide covers.

FAQ

What is the difference between an intent taxonomy and an intent classifier?

The taxonomy is the structured set of intents, their definitions and their relationships. The classifier is the model that assigns each incoming message to one of those intents. You can replace or retrain the classifier many times while keeping the taxonomy stable, but a poorly defined taxonomy limits how well any classifier can perform.

How many intents should a conversational AI start with?

There is no standard number, so let your data decide. Begin with the handful of intents that cover most of your conversation volume, plus an out-of-scope fallback and an urgent escalation intent. Add more only when logs show a recurring request that the current labels handle badly.

How do I handle a customer message that contains two intents?

Decide the rule before launch. A common approach is to address the higher-risk or time-critical intent first, then confirm the second one with the customer. Research on search queries has found that multifaceted queries need probabilistic classification, so build your agent to work with confidence scores rather than a single hard label.

How often should we update our intent taxonomy?

Review out-of-scope and low-confidence conversations monthly, and run a fuller structural review each quarter. Update immediately when a product, policy or regulation changes. RFC 9316 describes classification tables as something you can extend or trim as new scenarios and domains emerge.

Can we build a taxonomy without labelled data?

Yes. Academic work on intent induction shows that unsupervised clustering of conversation logs can propose a first set of intents and a training set for a classifier. Have people review the clusters before you rely on them, particularly for sensitive or regulated intents.