AI chatbot development in Dubai
We build AI chatbots for websites, products and internal teams that answer from your 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. (Verified July 2026, against Anthropic's Citations documentation.)
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. We test that path 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.
We set 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. (Verified July 2026, against the Jais model card and TII's Falcon page.)
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 we test against real transcripts from your 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 a decision we make against your material, not a badge we pick in advance. We evaluate candidates on your own questions and show you where each one breaks.
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."
Representative of the work we do, not a specific client account. The build 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 bands as any agent build we quote, in AED. 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 yours, not ours. 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 we will tell you 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, not decide. We will build that narrower thing and say why.
- 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: we build on Ruby on Rails with a retrieval layer over your 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.
Send us the questions your team answers most
Twenty real questions from your inbox tell us more than a requirements document. We will tell you which a chatbot can answer from your existing material, which need something written first, and which are agent work rather than chatbot work.
hello@telora.dev