How AI Can Help Categorise Customer Enquiries
AI can read an incoming enquiry — an email, a form submission, a chat message — and assign it to a category so it reaches the right team without a person sorting it first. It works well once categories are clearly defined and tested against real, messy examples, and it needs a route for anything ambiguous or sensitive.
Defining Categories That Are Actually Useful
The instinct is to build a long, detailed category list that mirrors every internal team's structure. In practice, a shorter list of categories that map clearly to who handles them and what happens next works far better — each category needs a named owner and a defined next step, or the classification is just labelling without purpose.
Consider a regional broadband and DTH service provider fielding enquiries across billing, technical faults, new-connection requests and plan changes. "Technical fault" is useful because a specific team picks it up within a defined time. A category like "general query" is not useful, because nothing specific happens to it — if a category doesn't route anywhere different from another, it's worth merging the two.
Building a Set of Labelled Examples First
Before any AI classification is evaluated, gather a genuinely representative sample of past enquiries — several hundred, ideally — and label each one with the category a human would assign. This labelled set does two jobs: it gives you something to test the AI against, and the labelling process itself often reveals that your category definitions are less clear than they seemed on paper.
Skipping this step and going straight to a live pilot is the most common mistake — without a labelled baseline, there's no way to tell whether the AI's categorisation is actually accurate, or just plausible-sounding.
Testing Where Categories Genuinely Blur
Real enquiries don't sort as cleanly as a category list implies. "My WiFi keeps disconnecting and I want to know if I'm being charged for the days it was down" touches both a technical fault and billing. Test specifically for these overlap cases, and for enquiries written in mixed languages or heavy local phrasing, because that's where a system that performs well on clean examples often breaks down.
The goal of this testing phase isn't to eliminate ambiguity — some of it is genuinely unavoidable — but to find out how the system behaves when it hits ambiguity, and whether that behaviour is safe.
Routing Low-Confidence and Sensitive Cases to People
Every classification system should have a confidence threshold below which an enquiry goes to a person rather than being auto-routed on a guess, and a separate rule for categories that are inherently sensitive — a complaint about billing fraud, or anything mentioning a regulatory or legal concern — regardless of how confident the AI is.
For the broadband provider, that might mean any enquiry classified with lower than a set confidence gets a quick human triage step before routing, and anything flagged as a possible complaint about unauthorised charges always goes to a supervisor, never straight to a first-line queue.
Monitoring Misrouting and Updating the Taxonomy
Categorisation accuracy isn't a one-time measurement — enquiry patterns shift as the business changes (a new plan launch generates a wave of enquiries the original categories never anticipated), and a taxonomy that fit six months ago can quietly stop fitting. Track misrouted enquiries — cases where a team receiving something has to reroute it — as the ongoing signal that the categories or the classifier need attention.
Treat the taxonomy as something to revisit periodically, not something you finalise once at launch. A short quarterly review of misrouted cases usually surfaces exactly which categories need splitting, merging, or better examples.
Enquiry classification and routing flow
A flow diagram showing an incoming enquiry, an AI classification step producing a category and confidence score, a fork for low-confidence or sensitive categories into human triage, and a routing table mapping each category to its owning team and expected response time.
Frequently asked questions
Can one enquiry have multiple categories?
Yes, and the classification system should allow it rather than forcing a single label — a message that's both a technical fault and a billing question is common, and forcing it into one category means one of the two concerns gets missed unless multi-label routing is built in from the start.
How do we handle unknown topics?
Include an explicit "unclear" or "other" category that routes to a person rather than forcing every enquiry into an existing bucket. An enquiry misclassified into the wrong category is often worse than one correctly flagged as unclassifiable, because it reaches the wrong team with no signal that something's off.
Have a specific situation to work through?
This article covers the general case. Tell us what you're actually dealing with and we'll respond directly.