In this guide 6 sections
AI can read an incoming enquiry, such as an email, a form submission or a chat message, and assign it to a category. The enquiry then reaches the right team without a person sorting it first. It works well once categories are clearly defined and tested against real, messy examples. Ambiguous or sensitive enquiries need a route to a person.
Defining useful categories
It is tempting to build a long, detailed category list that mirrors every internal team’s structure. In practice, a shorter list works better, with categories that map clearly to who handles them and what happens next. Each category needs a named owner and a defined next step. Without them, classification is only labelling.
Consider a regional broadband and DTH service provider handling enquiries about 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 two categories do not route anywhere different, merge them.
Building a set of labelled examples first
Before any AI classification is evaluated, gather a representative sample of past enquiries, ideally several hundred. Label each one with the category a human would assign. The labelled set does two jobs. It gives you something to test the AI against. The labelling process itself also often shows 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 is no way to tell whether the AI’s categorisation is accurate or only plausible-sounding.
Testing where categories blur
Real enquiries do not 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. Also test enquiries written in mixed languages or heavy local phrasing. A system that performs well on clean examples often breaks down there.
The goal of this phase is not to remove ambiguity, since some of it is unavoidable. The goal is to find out how the system behaves when it meets ambiguity, and whether that behaviour is safe.
Routing low-confidence and sensitive cases to people
Every classification system should have a confidence threshold. Below it, an enquiry goes to a person instead of being auto-routed on a guess. A separate rule should cover inherently sensitive categories, such as a complaint about billing fraud or anything mentioning a regulatory or legal concern. These go to a person whatever the AI’s confidence.
For the broadband provider, this might mean that any enquiry classified below a set confidence gets a quick human triage step before routing. 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 is not a one-time measurement. Enquiry patterns shift as the business changes. A new plan launch, for example, can generate a wave of enquiries the original categories never anticipated. A taxonomy that fit six months ago can quietly stop fitting. Track misrouted enquiries, meaning cases where the receiving team has to reroute them. They are the ongoing signal that the categories or the classifier need attention.
Treat the taxonomy as something to revisit periodically, not something to finalise once at launch. A short quarterly review of misrouted cases usually shows which categories need splitting, merging or better examples.
Enquiry classification and routing flow
A flow diagram showing an incoming enquiry and an AI classification step that produces a category and confidence score. Low-confidence or sensitive categories fork into human triage. A routing table maps each category to its owning team and expected response time.
Open a blank worksheet to printQuestions owners ask
Can one enquiry have multiple categories?
Yes, and the classification system should allow it instead of forcing a single label. A message that is both a technical fault and a billing question is common. 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, instead of forcing every enquiry into an existing bucket. An enquiry misclassified into the wrong category is often worse than one correctly flagged as unclassifiable. It reaches the wrong team with no signal that something is off.