Intent Detection
Working out what somebody wants, as opposed to what words they used. The same request arrives phrased a hundred ways, in two languages, frequently mixed and often misspelt.
Working out what somebody wants, as opposed to what words they used. The same request arrives phrased a hundred ways, in two languages, frequently mixed and often misspelt.
What it does
Intent detection is the step that maps an utterance to a purpose. "Where is my order", "has it shipped yet", "I ordered on Tuesday and nothing has come" and the Arabic equivalents of all three are one intent expressed four ways, and the system has to recognise that.
It is also what decides routing. An assistant that identifies intent correctly reaches the right agent, the right material and the right escalation rule. One that does not produces the experience of being transferred repeatedly, which is precisely what customers were promised they would avoid.
Where it shows up in a conversation
Routing
Getting a question to the agent and material that can answer it.
Escalation
Recognising "I want a person" or "this is a complaint" as instructions rather than questions to be answered.
Button and menu flows
Deciding when a guided path serves better than free conversation.
Analytics
Counting what people actually contact about, which is usually different from what an organisation assumes.
Disambiguation
Asking one clarifying question when a request could mean two things.
Urgency recognition
Identifying language that should escalate immediately rather than be answered.
Why it is harder in two languages
The bilingual challenge here is not translation, it is coverage. Intent recognition works by matching how people actually phrase things, and the phrasings differ completely between languages and between varieties of Arabic. A system whose intent coverage was built in English and translated will recognise the translated phrasings and miss the ones people actually use.
Dialect widens the gap. The Arabic a Saudi customer types is not Modern Standard Arabic, and a formal rendering of an intent will not match an informal request. Coverage has to be built on the Arabic side directly rather than derived from English.
Mixed-language input is the third factor. A request containing an English product name inside an Arabic sentence is extremely common here, and a system that commits to one language before matching intent will mishandle a large share of genuine requests.
What to look for when you evaluate it
| Coverage in Arabic | Whether intent phrasings were built in Arabic or translated from English. Translated coverage misses how people actually write. |
|---|---|
| Dialect handling | Whether informal Saudi phrasing matches, not just formal Arabic. |
| Mixed-language input | Whether a sentence containing both languages is handled or forced into one. |
| Disambiguation behaviour | Whether it asks one clarifying question or guesses between two plausible intents. |
| Unknown handling | What happens when a request matches nothing. Falling back gracefully matters more than coverage breadth. |
| Escalation recognition | Whether requests for a person and complaints are recognised as instructions rather than answered as queries. |
Where it should not be trusted alone
Intent should not be trusted where confidence is low and the consequence is high. A request that could plausibly be two things — a cancellation or a change, a complaint or a query — should produce one clarifying question rather than a confident guess.
It should also not be the only escalation mechanism. Asking for a person must work regardless of whether intent detection recognised the phrasing, because the customers most in need of a person are often the ones phrasing it least conventionally.
And it should not be used to suppress unhandled requests. A system that maps everything to its nearest known intent will confidently answer the wrong question rather than admitting the request is outside its coverage.
How this fits the whole
No single capability answers a question on its own. A conversation passes through several in sequence — understanding what was asked, finding the relevant material, composing a reply, checking it before it is sent — and the quality of the result is set by the weakest link rather than the strongest.
That has a practical consequence for evaluation. Vendors tend to demonstrate their strongest component, and a system with excellent retrieval and weak language handling will demo beautifully and disappoint in production, because the demo was conducted in the language and phrasing the system handles best.
It also explains why grounding matters more than raw capability. A more capable model that answers from its own training rather than from your material produces confident, fluent, unsupported answers — which is a worse outcome than a less capable one that retrieves correctly and declines when it cannot. Capability without grounding increases the cost of being wrong rather than reducing it.
The pieces are described separately here because that is how they are evaluated and configured. They are not experienced separately: a customer asking a question encounters one system, and judges it as one.
Where this sits in a conversation
- Something arrivesA typed message, a spoken sentence, an uploaded document. The first job is establishing what was actually received — which language, which script, whether it is legible, whether it is one question or several.
- It is interpretedWorking out what is being asked rather than what words were used. The same question arrives phrased twenty different ways, in two languages, often mixed, frequently misspelt, sometimes as a fragment.
- Material is retrievedThe relevant part of your own approved content is found. This is where answer quality is largely decided: a correct answer assembled from the wrong source is still wrong.
- A reply is composedIn the language of the question, in the configured tone, from the retrieved material and nothing else. Where the material is silent, the reply says so rather than filling the gap.
- It is checkedBefore sending, the reply is examined for claims the retrieved material does not support and for personal data that should not be repeated back. This runs on every reply.
- It is deliveredAs streamed text, as speech, or as a structured response — and the conversation is recorded so that what happened can be reviewed later.
Why this is built rather than bought in
Every capability described here could, in principle, be obtained by calling somebody else's service. That is how most assistants in this market are assembled, and it is why so many of them cannot answer the question that decides regulated procurements: where does the data go.
When a component is a call to an external provider, every question that passes through it leaves the organisation. That may be perfectly acceptable for a retailer answering questions about opening hours. It is usually not acceptable for a bank explaining a transaction, a hospital confirming an appointment, or a public body handling a citizen case — and the constraint is architectural, so it cannot be configured away later.
The second consequence is control over behaviour. A capability obtained as a service behaves the way the provider decides, changes when the provider changes it, and cannot be tuned for the specific way your customers speak or write. A capability that runs inside your own estate can be adjusted for dialect, for your terminology, and for the particular failure modes your material produces.
The third is continuity. External services are deprecated, repriced and withdrawn. A deployment whose core capability depends on somebody else's roadmap inherits that roadmap, including the parts nobody announced in advance.
Measuring this component honestly
| Measured in which language? | Nearly every published benchmark in this field was developed against English. An overall figure that averages across languages hides exactly the gap that matters in this market. |
|---|---|
| Measured on what input? | Clean or realistic. Read speech or spontaneous speech. Typed text or phone-typed text with autocorrect. The difference between these is usually larger than the difference between vendors. |
| Measured by whom? | Self-reported figures with an undescribed method are marketing. Ask for the test set and the procedure. |
| What counts as correct? | A surprising number of published figures count a partially correct answer as correct. Ask what the scoring rule was. |
| How does it fail? | A component that degrades gracefully is worth more than one with a higher headline figure that fails silently and confidently. |
| Does it report uncertainty? | A component that surfaces low confidence lets the system confirm rather than guess. One that hides it produces confident errors downstream. |
What to ask about this specifically
Ask for the Arabic figure
Not the overall figure. Nearly every published benchmark in this field was developed against English, and the gap between the two languages is where deployments disappoint.
Ask how it was measured
Against what test set, by whom, on what kind of input. A number without a described method is marketing rather than measurement.
Ask what it does when uncertain
Whether uncertainty is surfaced or hidden. A component that hides low confidence produces confident errors downstream.
Ask about real conditions
Noisy audio, poor scans, dialect, informal phrasing, mixed languages. Laboratory conditions are not predictive of contact-centre reality.
Ask where processing happens
For any component touching personal data, this is a procurement question rather than a technical curiosity in regulated sectors.
Ask what is retained
What data this component keeps, for how long, and whether it is used to improve anything.
Common questions
The practical limit is maintenance rather than capacity. Every intent needs material behind it and an owner, and coverage that is not maintained drifts out of date.
It must. Customers type informally, and coverage built from formal Arabic will miss the phrasings people actually use.
It says so and offers a person. Mapping an unrecognised request to the nearest known intent is how an assistant confidently answers the wrong question.
Yes, and people frequently send them. Handling the first and acknowledging the second is better than answering one and silently ignoring the other.
By reading real transcripts. Every deployment finds customers asking things nobody anticipated, phrased in ways nobody predicted.
It should. Your product names, your internal shorthand and the informal names customers use for them are all part of coverage.