Intent classification

Every support conversation starts with a message in the customer's own words, and the system must map it to one of a defined set of intents before anything useful can happen. Older chatbots did this with keyword rules or small classifiers trained on labelled examples. Modern systems use a language model with the intent taxonomy in the prompt, sometimes combined with a lightweight classifier for speed and cost, and they extract entities (order number, plan name, date) at the same time.

The taxonomy is the real work. It should reflect what the business can act on, not every phrasing customers use: "where is my order", "delivery late" and "tracking not updating" are one intent if they trigger the same lookup. Multi-intent messages ("cancel my order and refund the delivery fee") need to be split. An "unknown" class with a clarifying question is essential; forcing every message into a known bucket produces confident wrong actions.

Intent classification is not sentiment analysis or topic tagging, though both are often run alongside it. Its accuracy is measured per intent on a labelled set drawn from real tickets, and it degrades as products and policies change, so it needs periodic re-evaluation.

• Support manager: misclassified intents are the root of wrong answers and wrong routing; the taxonomy should be designed with the team, not handed to them.
• CTO: classification accuracy is the first eval in a support agent; it is cheap to measure and predicts downstream failure.
• Product manager: intent volumes over time are a direct read on where the product is causing friction.
• Data lead: the labelled intent set becomes a durable asset for evals, reporting and future models.

A support system cannot retrieve the right policy, call the right API or route to the right queue without first deciding what is being asked. Intent classification exists to make that decision explicit, measurable and improvable, rather than buried in a model's free-form reasoning. The failure it prevents is the confident wrong action: issuing a refund when the customer asked about a refund policy. The trade-off is maintenance: taxonomies drift as products change, and every new intent needs examples and evaluation. Eazyware builds the taxonomy from real ticket data in the first weeks and re-evaluates it in each Care Plan cycle.

• SaaS helpdesk: separating billing, bug report, feature question and account-access intents for routing and auto-resolution.
• Banking chat: distinguishing balance enquiry from transaction dispute from card block, each with different verification requirements.
• E-commerce WhatsApp support: classifying order, return, exchange and product-availability queries in Hinglish.
• Hospital voice line: recognising booking, rescheduling, report collection and billing intents from spoken requests.
• Logistics: detecting delivery reschedule, address change and damage claim from short customer messages.

Technique / practiceAn NLP technique combining taxonomy design, prompting or classifier training, and per-intent evaluation. It is the first component Eazyware builds and evaluates in every Customer Service Agents project.

Eazyware service that covers it: AI Customer Service Agents. Starting prices are on the pricing page.