AI chatbot development in Dubai
AI chatbots for websites, products and internal teams that answer from a client's own documents and systems rather than from whatever a model half-remembers. They work in Arabic and English, they show where an answer came from, and they hand the conversation to a person when they should. This page also says plainly where a chatbot is the wrong tool.
How is this different from the decision-tree bot you were sold?
A decision-tree bot can only recognise the paths somebody wrote in advance. Ask it something slightly off-script and you get "I did not understand that" and a menu, which is how they became an expensive route to the contact form.
A modern AI chatbot reads the question as it was actually written, finds the relevant passage in your own material, and composes an answer from it. The work changes shape too. Instead of scripting hundreds of conversation branches, the build is about curating what the bot is allowed to read, defining what it is allowed to do, and deciding what it must refuse. That is a smaller and more durable thing to maintain: when your refund policy changes you edit the policy document, not forty dialogue nodes.
The honest caveat is that this shifts the failure mode rather than removing it. A tree bot fails visibly by saying nothing useful. A language model fails invisibly by saying something plausible and wrong. The next two sections are about that.
How do you stop it making things up?
By never asking the model to answer from memory. Every answer is retrieved from your sources first and composed second, and the passage it came from is kept alongside it so a wrong answer can be traced rather than argued about.
Retrieval before generation
The question goes to a search over your material first: the help centre, the policy PDFs, the price list, the product catalogue in Shopify, the tickets in Zendesk or Intercom, the records in HubSpot or Salesforce. The model answers from what came back, not from its training data.
Citations, not assurances
Answers carry the source they came from. Anthropic's Citations feature, for example, is documented as returning the exact passages that support each claim so you can verify answers and surface sources to your users, and it is supported across its active models.
Live data stays live
Order status, stock, invoice balances and appointment slots are read at question time from the system of record, not copied into a knowledge base that goes stale by Tuesday.
A defined refusal
Where nothing relevant is retrieved, the correct output is that it does not know and a route to someone who does. That path is tested deliberately, because a bot that never says no is a bot that invents.
None of this makes a chatbot infallible, and any vendor telling you otherwise is selling. It makes wrong answers rare, visible, and fixable at the source.
What happens when it cannot answer?
It stops and gets a person, with the conversation attached. Escalation is a designed part of the build, not an afterthought bolted on when complaints start.
Explicit triggers: low retrieval confidence, a second failed attempt at the same question, anything mentioning a refund, a complaint, a legal matter or a cancellation, and an explicit request for a human, which is always honoured immediately. When a trigger fires, the transcript goes into Slack or into your helpdesk as a ticket with the customer's context, and the customer is told a colleague is taking over rather than being left talking to a wall.
The number worth watching afterwards is not "questions answered". It is what share of escalations were avoidable, because that is the list that tells you which document to write next.
Arabic AI chatbot development: what good Arabic support actually requires
More than switching a language setting. Three things decide whether Arabic support is real.
Modern Standard Arabic is not what customers write. Arabic-first models are explicit about this. The Jais family from Inception and Cerebras is described as optimised to excel in Arabic while keeping strong English capability, and its own model card states the models should not be presumed to have equal proficiency in other languages or dialects, with training centred on Modern Standard Arabic. TII in Abu Dhabi positions Falcon Arabic as built for Modern Standard Arabic and dialects. Read those two statements together and you have the actual state of play: MSA is well covered, Gulf and other dialects are a claim to test rather than assume.
Real messages are mixed. UAE customers switch between Arabic and English inside one sentence and write Arabic in Latin letters. A chatbot that only handles clean Arabic input will fail on ordinary traffic, so testing runs against real transcripts from the client's own inbox before launch rather than against tidy sample phrases.
Arabic is not only a model problem. The interface has to be right to left, the source material has to exist in Arabic, and the escalation path has to reach someone who reads Arabic. A bot answering fluently from an English-only knowledge base is producing translations of the wrong content, and a fluent Arabic handover into an English-only support queue simply moves the failure.
Which model does the work is decided against the client's own material rather than picked in advance. Candidates are evaluated on real questions, and the point at which each one breaks is shown.
Where the chatbot goes: web, in-app, and other channels
One knowledge base, several front doors. The retrieval layer, the escalation rules and the connections to your systems are built once; each channel is a different way in.
Your website
A widget on the pages where questions actually arise, with access to pricing, policies and stock. Anonymous visitors get answers; signed-in ones get answers about their own account.
Inside your product
In-app support that knows which plan the user is on and what they were doing when they asked, so the answer is about their situation rather than the generic case.
For your own team
An internal chatbot in Slack that answers from your handbooks, contracts, and the records in Google Drive or SharePoint. Often the lowest-risk place to start, because the audience is forgiving and the material is already written.
A different channel with its own rules: Meta approval, message templates, and per-message fees that have nothing to do with your model costs. That has its own page: WhatsApp chatbot development.
When a chatbot should become an agent
A chatbot answers. An agent acts. That is the whole distinction, and it is worth being honest about which one you are buying.
A chatbot reads your material and tells the customer what the answer is. It is the right first project because the risk is contained: the worst realistic outcome is a bad answer that a person then corrects. An agent takes the next step itself. It writes the refund into Stripe, moves the deal stage in HubSpot, raises the credit note in Xero, reschedules the appointment. The risk profile is different because the mistakes are no longer only words, which is why an agent build carries permissions, limits, an audit trail and a defined path for a human to intervene.
The sequence that works is chatbot first, then agent, using what the chatbot logs. After a few weeks you know exactly which requests arrive most often and which of them the bot had to hand over. That list is the specification for the first agent, written by your customers rather than guessed at in a workshop. When you are ready for it, that is AI agent development.
What this looks like in practice
"Support answers the same twenty questions all day, in two languages, and the answers live in a PDF nobody can find."
Example of a build of this shape. It would start by turning the PDF and the help centre into the chatbot's source material, in Arabic and English, then connect the order and invoice lookups so account questions are answered from live records rather than from a document. Anything about a refund, a complaint or a cancellation would be routed straight to the support queue with the transcript attached. Each week the escalation log would show which questions the bot could not answer, and those become the next things written down.
The output to judge it on is the escalation log, not the answer count.
What does an AI chatbot cost in Dubai?
A chatbot is priced on the same AED bands as any agent build. A single channel over one knowledge base with one or two system lookups is the lowest band by definition, because a single channel over a knowledge base with one or two system lookups is exactly what that band describes.
AED 10,000 to 20,000
One channel, one knowledge base, one or two system lookups, a human escalation path. Indicatively 2 to 3 weeks.
AED 20,000 to 35,000
Three or more systems, branching logic, error handling. Bilingual content and a second channel usually put a build here. Indicatively 3 to 5 weeks.
AED 35,000 to 50,000
Custom logic, compliance constraints, a self-hosted model, or a heavy integration surface. Indicatively 5 to 8 weeks.
Two costs sit outside that fee and are billed directly to the client. Model API usage is billed by the provider on what you actually send and receive, so it scales with conversation volume and with how much source material each answer pulls in. Hosting is the second. Ongoing changes and monitoring run on a monthly retainer. How we work sets out the sequence and what we need from you to start.
When not to build one
Cases where a chatbot is not the answer.
- The answers do not exist yet. If the knowledge lives in three people's heads and nothing is written down, a chatbot has nothing to retrieve. Writing the material is the project, and it is worth doing whether or not a bot ever reads it.
- Your questions are few and repetitive. If five questions cover almost everything, a better help page and a good search box will beat a chatbot and cost a fraction of it.
- Being wrong is expensive. Medical advice, legal positions, regulated financial guidance: where a plausible wrong answer causes real harm, the bot should retrieve and route to a person rather than decide. That narrower build is what gets proposed, with the reason stated.
- The real job is doing, not telling. If what you want is the refund processed rather than the refund policy explained, you want an agent. Buying a chatbot to satisfy that need produces a bot that describes the thing your customer wanted done.
- Nobody owns it after launch. Source material drifts, systems change, and an unattended chatbot degrades quietly. If no one on your side will own the content, the honest answer is not yet.
Under the hood: Ruby on Rails, with a retrieval layer over the client's own content and direct connections to Salesforce, HubSpot, Xero, QuickBooks, Stripe, Shopify, Zendesk, Slack, monday.com and Asana. Conversations, retrieved sources and escalations are logged so an answer can be reconstructed after the fact. Model choice is set per build and can be changed without rebuilding the retrieval layer, including a self-hosted model where data residency requires it.
The questions your team answers most
Twenty real questions from the inbox say more than a requirements document. We will tell you which a chatbot can answer from existing material, which need something written first, and which are agent work rather than chatbot work.
hello@telora.dev