Short answer
Multi-intent detection is recognizing that one customer message contains more than one request, and identifying each of them. Without it, an AI answers the first request and leaves the rest unresolved.- Also called
- Multi-intent classification, multiple intent detection, multi-intent handling
- Builds on
- Intent detection, which labels what a message is about
- Key difference
- Several labels per message, each with its own confidence
- Hard part
- Deciding what to answer, do or hand off for each request
Customers rarely write one tidy request per message. "My order is late, and can you change the address for my next one?" is two requests. A system that detects only one answers half the message, and the customer writes back for the other half.
Intent detection vs multi-intent detection
Intent detection labels what a message is about. Multi-intent detection allows more than one label per message.
A single-label system has to pick one winner, so it either picks the wrong request or blurs two into one vague answer. A multi-label system scores each intent on its own, keeps every intent that clears the bar, and can keep none when nothing fits. Customer intent detection in support usually needs the second kind, because real messages bundle requests.
In Aide, a procedure can check its topic as any detected topic or only as the highest topic, so the team decides whether it runs wherever that request appears in a message or only when it is the main request.
How multi-intent detection works
The method changes one assumption: that a message has exactly one answer.
- Score every intent on its own, instead of choosing one winner.
- Keep the ones above a confidence threshold, best first, often up to a small cap such as three.
- Allow none. A message that fits no intent should not be forced into one.
- Plan the response: for each request, answer, act or hand off, and in what order.
The approach this page rejects is one label per ticket for the sake of tidy routing. It makes dashboards neat and leaves customers writing back.
A multi-intent example
A Shopify shopper writes: "Order 5120 still says processing. I ordered the wrong size, can I swap the medium for a large? Also, do you ship to Canada?"
That is three requests:
- Order status, answered from the order and fulfillment status.
- A change to the order, which depends on whether it has been fulfilled and whether a large is in stock.
- A shipping policy question, answered from the shipping page.
A good reply covers all three, and says plainly if one of them needs the team. A weak reply answers the first and stops.
With Aide, for a shopper who has proved the order is theirs, the reply can give order 5120's status from Shopify and answer the Canada question from the store's shipping page. A size swap is not an order change Aide makes, so the same reply says that part needs the team and offers to hand it over, rather than skipping it.
Multi-intent vs sub-intent
The two terms are often confused. A sub-intent is a narrower intent inside a broader one, such as a wrong-size return inside returns. Multi-intent means several separate requests in one message. A message can have both: a wrong-size return and a tracking question in the same email.
Where Aide fits
Aide scores every customer message against the team's own topics and selects up to three, best first, or none when nothing fits well. Each message shows its topics as chips, so the team can see when one message carries more than one request, and the topics are written back to Zendesk, Gorgias or Front as tags or a ticket field. See what your topics tell you.