AI chatbots grounded in your content, with a real handover

AED 25,000 to AED 150,000 covers most of what we are asked to build. The number moves on how many channels and languages, how much content needs preparing, whether CRM and handover integration is needed, and whether ongoing review is included. Model and platform usage costs are separate and ongoing. Anything quoted before those are known is a guess. We scope first, then price, and the scope document is yours whether or not you proceed. These are market ranges rather than a fixed rate card — the proposal carries the real figure.

Two costs that get conflated. The build is one-off. Then there is ongoing usage cost, which scales with conversation volume, plus the human time to review logs and keep content current. That second line is the one most proposals omit, and on a busy support channel it is not trivial. We model it against your actual volume before you commit.

Sometimes, and we will say so. Several support platforms now include competent grounded chatbots, and if you already pay for one, using it is usually the right answer. Custom work earns its cost when you need specific integrations, unusual channels or behaviour the product does not support.

It says so and routes to a person, with the conversation attached. That behaviour is tested explicitly during the build, because it is the single thing that protects you. A bot that would rather guess than admit ignorance is the failure mode everyone is worried about, and it is a design decision rather than an inevitability.

Yes, answering in the language asked, with the underlying content maintained in both rather than machine-translated at answer time. Translated answers come out in a register that native speakers notice immediately.

Yes, and in this market it is often the channel that matters most. There are rules about messaging outside a customer-initiated window and templates need approval, so it needs planning rather than switching on.

Anything regulated, anything where being wrong is expensive, and anything requiring judgement about an individual's circumstances. Medical advice, legal questions, credit decisions, complaints past a threshold. We define those boundaries before building and block them explicitly.

Enough to answer the questions customers actually ask. Send us your top thirty questions and we can tell you quickly what proportion your existing material covers — the answer is frequently lower than expected, and that content work is the real first project.

Six to twelve weeks for a first deployment, and content preparation is usually what determines it rather than the build. Launching narrow and expanding is faster and safer than trying to cover everything at once.

It depends entirely on how repetitive your questions are and how good your content is, and we would rather not quote a figure that becomes a target. What matters more is the quality of the answers it does give and whether the handover works, because a high containment rate achieved by refusing to escalate is a worse outcome than a low one.

Containment rate, handover rate, accuracy on spot-checked conversations, satisfaction, and the staff time it displaced measured against the baseline. We report the questions it fails on as prominently as the ones it handles.

Often yes. The common problems are that it is not grounded in your content, the handover loses context, or nobody reviews the logs. All three are fixable without starting again, and we will tell you if a rebuild is genuinely warranted.

No, and be wary of any proposal implying it will. What it reliably does is absorb the repetitive questions — opening hours, order status, policy basics — so your team spends their time on the conversations that need judgement. Teams that cut headcount on the strength of a chatbot generally end up rehiring, because the remaining conversations are harder and take longer.

It can, and that is a meaningfully higher-risk build than answering questions. Anything that writes to a system rather than reading from one needs confirmation steps, an audit trail and a way to reverse a mistake. We would launch the answering version first and add transactional capability once the logs show the bot understands the questions.

Worth doing, and it changes what the bot can be. Recognising a returning customer, knowing their order history and passing that context to a human on handover all materially improve the experience. It also raises the data-handling questions, so the governance work has to happen alongside rather than after.

Somebody named, and this is the question that decides whether it is still useful in a year. The content behind it needs an owner and a review rhythm, and the conversation logs need reading. That is a few hours a month, not a full role, and with nobody doing it the bot confidently answers from last year's prices.

Against real historical customer questions rather than a scripted happy path, including the awkward ones: ambiguous phrasing, questions the content does not cover, complaints, and deliberate attempts to make it say something it should not. The refusal behaviour gets tested harder than the answering behaviour.

Staff time on repetitive questions, and response speed outside business hours, which for consumer businesses here is often the larger gain. We measure it against the baseline of how many of those questions your team currently handles and how long each takes, so the saving is a number rather than an impression.