The problem
Support teams usually organise customer contacts with a taxonomy that someone designed in advance: a list of reasons customers get in touch. Real conversations rarely match it. New issues appear, categories overlap, and a large share of contacts end up filed under “other”, which tells you nothing.
The usual fix would be to train a classifier. But a classifier needs labelled examples, and the labels only exist for the categories you already knew about. The contacts you most need to understand are exactly the ones nobody has labelled.
What we built
A system that reads raw conversation logs and discovers the intents within them, without labelled data. The taxonomy comes from what customers actually say rather than from what anyone expected them to say. It has been deployed for clients in energy, healthcare and travel. The work covered the architecture, the clustering algorithms and visualization.
How it works
Turning conversations into vectors
Transcripts are converted into embeddings, numerical representations of meaning, using GPT-3.5 and LLaMA 2 and 3. Two conversations about the same problem end up close together in this space, even when the customers used completely different words.
Finding the groups
Clustering algorithms then find groups of similar conversations. We use more than one, because they make different assumptions about what a group looks like.
- K-Means divides conversations into a chosen number of groups. It is fast and effective when groups are compact and similar in size.
- DBSCAN finds groups as dense regions and treats isolated points as noise. It does not need the number of groups in advance and handles irregular shapes.
- HDBSCAN extends DBSCAN to groups of varying density, which suits real support data, where some intents are very common and others rare.
Comparing methods helps separate structure that is genuinely in the data from structure that is an artefact of one algorithm’s assumptions.
Building a hierarchy
Intents are organised hierarchically, so broad themes break down into specific, actionable intents. “Billing” is too broad to act on; a hierarchy shows the particular billing problems inside it.
Making it readable
Clusters are only useful if people can understand them. Visualization makes the structure explorable, so a support team can see which intents are largest, how they relate and where new ones are emerging.
What the output is used for
A taxonomy grounded in real demand is the foundation for most support improvements. It shows where volume actually is, which questions are worth automating first, which issues reflect a problem in the product itself, and how customer needs change over time.
Where it can go wrong
- Clusters that are not intents. Conversations can group by surface features, such as greetings or a shared template, rather than by what the customer wanted. Every cluster needs a human sanity check.
- The wrong granularity. Too coarse and the result is useless; too fine and it is noise. The hierarchy exists to let people choose the level they need.
- Drift. Customer needs change. A taxonomy discovered once becomes out of date, so the analysis should be repeated.
Questions to ask before building one
If you are considering a system like this, these are the questions we would want answered first.
- Do you have the transcripts? The analysis needs a reasonable volume of real conversations, handled in line with your privacy obligations.
- Who will validate the clusters? Someone who knows your customers must confirm each discovered intent is real.
- What will you do with the taxonomy? Decide in advance whether it drives routing, automation, reporting or product fixes.
- How often will you refresh it? Customer needs change, so plan to repeat the analysis.