AI that handles how people here actually write
The hard part of AI in the UAE is not the model. It is that customers write in Gulf dialect, in English, in Arabic script, in Latin-script Arabic, and frequently in two of those within one sentence. Systems evaluated only on formal Arabic or English perform noticeably worse on real messages, and the difference is not visible until you test against your own inbox.
An AI assistant that demonstrates beautifully and disappoints in production almost always failed on input it was never shown. In this market the input is unusually varied. A single customer may open in English, switch to Arabic mid-sentence, write Arabic words in Latin characters, use Gulf dialect rather than the formal Arabic that dominates training data, and send it all through WhatsApp with voice notes attached. None of that is unusual here. All of it is outside what a demo built on clean English prompts has been tested against.
Language model performance in Arabic is materially behind English, and the gap widens on dialect. Most Arabic in training data is Modern Standard Arabic, the language of news and formal writing, while customers write in Gulf dialect, which differs in vocabulary and structure. Add Latin-script Arabic and mid-sentence code-switching and a system that scored well in testing starts misreading intent in ways that are hard to spot from a dashboard: it does not fail loudly, it answers a slightly different question. The second problem is deployment. Assistants get built as website widgets in a market where the conversation is already happening on WhatsApp.
When this work makes sense
Questions worth asking any supplier
Was the system evaluated against your own messages, or against clean test prompts? Ask for the evaluation set. If it does not contain dialect and code-switched examples, it does not reflect your inbox.
How does it behave when it is unsure? Silent confident guessing is worse than an honest handover to a person, and the difference is a design decision rather than a model capability.
Where is data processed and what is retained? For regulated sectors this determines whether the project is viable at all, so it belongs at the start.
Is it deployed where your customers already are? An excellent assistant on a website nobody messages is a worse outcome than a simple one on WhatsApp.
What happens to a voice note? A meaningful share of messages in this market are voice, and a system that ignores them is handling a partial inbox.
Deliverables
An evaluation set built from your real conversations, including dialect, code-switching and Latin-script Arabic, used before and after build
Assistants deployed on WhatsApp Business Platform where that is where your customers already write
Explicit handover rules. What the system will not attempt, and how a person picks it up with context intact
Bilingual handling that follows the customer's language rather than forcing a choice at the start
Voice note transcription where message volume justifies it
Data processing location and retention documented before build, not discovered during review
Reporting on what the system got wrong, not only what it handled
Built with
Process
We start by taking a sample of your actual conversations, typically several hundred real messages, and building the evaluation set from them before designing anything. That sample decides the project. It shows what share is dialect, what share is code-switched, what people are actually asking, and how much of it is genuinely repetitive. Often it shows that three enquiry types account for most of the volume, which makes the sensible build far narrower and far more reliable than the general assistant that was originally requested.
The standard nine stages, discovery, strategy, UX/UI, development, content and SEO, testing, launch, measurement and continuous improvement, apply to every project. The paragraph above is what differs for this one.
What moves the number
Pricing depends on scope, functionality, integrations and content requirements. These are the factors that change it most:
Three scopes for a UAE assistant
Narrow and reliable
Fits: Most businesses, the handful of enquiry types that make up the bulk of the volume
Limits: Will not answer everything, and needs a clean handover path for the rest
Broad assistant
Fits: Organisations with a large, well-documented knowledge base and the capacity to maintain it
Limits: Harder to evaluate, degrades quietly, and needs continuous correction to stay trustworthy
Human with AI assistance
Fits: Complex or high-value sales conversations where a wrong answer costs more than a slow one
Limits: Does not reduce headcount; it makes the existing team faster and more consistent
Case studies
No published UAE AI case study yet. Our Dubai office is in Standard Chartered Tower, Downtown Dubai. Client work will be published when we have permission to name the business and outcomes that can be evidenced rather than described.
MBGDesk operates from 4 offices in India, United States, United Kingdom, United Arab Emirates. We hold no industry certifications and do not imply otherwise.
Frequently asked questions
Will it understand Gulf dialect?
Better than it will understand it untested, which is the honest answer. Performance on dialect is measurably behind performance on formal Arabic or English, so we build an evaluation set from your own messages and measure it rather than assuming. If accuracy is not good enough for a particular enquiry type, that type routes to a person.
Our customers mix Arabic and English in one message. Is that a problem?
It is normal here and it is handled, but it has to be tested for. Code-switched messages are common in the evaluation sets we build and they are where systems tuned on single-language data quietly lose accuracy, not by failing, but by answering a slightly different question.
Should this be on our website or WhatsApp?
Wherever your customers already message you, which in this market is usually WhatsApp. A capable assistant on a channel nobody uses produces less value than a modest one where the conversation is already happening. We look at where your enquiries currently arrive before deciding.
What happens when it does not know something?
It says so and hands over to a person with the conversation intact. That behaviour is designed rather than inherited, the default failure mode of these systems is a confident plausible answer, which is more damaging than an admission of uncertainty, particularly on price and availability.
Where is our data processed?
That depends on which services the build uses, and for regulated sectors it may determine what can be used at all. We document processing location and retention before building rather than after, because finding out at review stage that a component is unusable means starting again.
Can it handle voice notes?
Yes, with transcription, and it is worth doing where voice is a real share of your messages, which here it often is. Accuracy on dialect voice is lower than on text and gets measured the same way, with your own recordings rather than a benchmark.
Will this replace our support team?
Not in our experience, and we would be cautious of anyone promising it. What it reliably does is absorb the repetitive share of enquiries so the team spends its time on the rest. If the business case only works on headcount reduction, it is worth testing that assumption on real volumes first.
Services that connect to this
Talk to us about this
Tell us what you are trying to build and we will come back with scope, approach and an estimate.