A chatbot is the easiest AI project to start and one of the easiest to get wrong in public. The technology is no longer the hard part — any competent team can connect a language model to a chat window in an afternoon. The hard part is deciding what it is allowed to reach, what it must refuse, and what it does the moment it does not know. Those three decisions separate an assistant customers use from one they screenshot and share.
I design and build chat assistants for businesses in Kuwait and the GCC, in Arabic and English, for customers and for internal teams. The design work comes before the build, and it is most of the value.
The three questions that decide the outcome
What can it see? An assistant is only as good as the material behind it, and only as safe as the boundary around that material. Point it at your product catalogue and policies and it is useful. Point it at an internal drive nobody has audited and you have built a very fast way to leak something. Scope is a security decision, not a convenience one.
What does it do when it does not know? The default behaviour of a language model is to answer anyway. That is the single biggest source of embarrassing chatbot stories. A well-built assistant says it does not know, and says who does — and it should be tested specifically on the questions it cannot answer, not only on the ones it can.
How does a person take over? Handover is not a failure state, it is a feature. The transition needs to be fast, obvious to the customer, and carry the conversation history with it so nobody is asked to repeat themselves. Most chatbot frustration is not caused by the bot being wrong; it is caused by there being no visible way out of it.
What I build
Customer support assistants
Answering the questions that arrive dozens of times a day — hours, availability, coverage, process, status, policy — grounded in your own published material rather than the model’s general knowledge. The measurable win is usually not staff reduction but response time outside working hours, which in this region is where a large share of enquiries actually arrive.
Internal knowledge assistants
An assistant for staff over policies, procedures, systems and internal documentation. Lower risk than a customer-facing bot, often higher return, and a sensible first project: mistakes are contained, the audience is forgiving, and the team learns what the technology is and is not good at before anything faces a customer.
Transactional assistants
Booking, ordering, status lookups, appointment changes — conversations that end in something happening in a system rather than in an answer. These are considerably more demanding than an informational bot, because a wrong answer becomes a wrong action. They need confirmation steps, strict validation, and a clean audit trail of what was done and on whose instruction.
Grounding and retrieval
The layer that decides which of your documents the model may consult for a given question. This is where accuracy is won or lost. It is also where most in-house attempts stall, because keeping the source material current is an operational commitment, not a one-off import — an assistant grounded in last year’s price list is worse than no assistant at all.
Channel deployment
On your website, inside your app, or on the messaging channels your customers already use. In Kuwait and across the Gulf that usually means WhatsApp carries more real conversation than a widget in the corner of a page ever will, and the design should follow the customer rather than the other way round.
Arabic assistants are not English assistants translated
This is the part most regional chatbot projects underestimate, and it is where a locally built assistant beats an imported one.
Model quality in Arabic has improved enormously and is still uneven. It is strongest in formal written Arabic and weakest exactly where your customers live: Gulf dialect, local place and company names, administrative and legal terminology, and the mixed Arabic-English sentences people actually type. An assistant that tests beautifully in standard Arabic can fall apart on a real message from a real customer.
Then there is register. A reply that is grammatically perfect but written in the wrong register reads as foreign, and customers notice within two exchanges. The assistant should sound like your organisation sounds — which means someone has to decide what that is, and someone who reads Arabic has to review the output before launch.
Practically, this means testing in both languages against genuine historical messages rather than invented ones, and treating the Arabic side as a first-class build rather than a translation pass. The same principle applies to the rest of your presence, which is why I argue for Arabic-first digital products rather than mirrored English ones.
How it should be measured
The industry’s favourite metric is the proportion of conversations handled without a human. Taken alone it is actively misleading: a bot that frustrates people into giving up scores beautifully on it. Measure it alongside the things that catch that failure.
- Conversations resolved without a human — but only counted where the customer’s question was actually answered
- Abandonment: people who leave mid-conversation and never come back through any channel
- Repeat contacts on the same issue within a few days, which is the honest signal that a resolution was not one
- Time to first useful response, in and outside working hours
- Handover rate, and how long the handover takes once requested
- Questions asked that the assistant had no material for — the most valuable output of the whole system
That last one deserves more attention than it gets. A chat assistant is the most direct record you will ever have of what customers actually want to know, in their own words. Most organisations deploy one and never read the transcripts. The log is worth more than the deflection rate.
What I will tell you not to build
An assistant on top of information that is wrong or out of date. This is the most common request I decline. If your product details differ across three systems, a chatbot does not fix that — it publishes the inconsistency to customers faster and more confidently than your website ever could. Fix the source, then build.
An assistant that exists because a competitor has one. If you cannot name the five questions it will spend most of its time answering, it is not ready to be scoped, and the honest first step is to go and read a month of your own enquiries.
And an assistant standing in for a process that should be automated instead. If customers are chatting to ask where their order is, the answer may be a status page and a notification rather than a conversation — that is workflow automation, and it is cheaper to run and impossible to get wrong in an interesting way.
How the work runs
We start with your real conversations — a month of enquiries, support tickets or messages — and group them. That produces the actual scope, which is almost always narrower and more boring than the one people imagine, and far more valuable. It also identifies the questions that must never be answered automatically.
Then the boundaries: what it may access, what it must refuse, how it escalates, what it logs, and what it says when it is unsure. Then the build, then testing against those same real messages in both languages, then a limited launch — one channel, or one customer segment, or staff only — before it goes wide.
After launch it needs an owner. Reviewing what it could not answer, adding the missing material, and keeping the sources current is a small recurring job that decides whether the assistant improves or quietly decays. I set that routine up and hand it over, with training for whoever will run it. Where the decision is bigger than one assistant — build or buy, in-house or vendor, what to do across the whole stack — that sits with my AI consulting and Fractional CTO work.
Frequently asked questions
How long does a chatbot project take?
A focused assistant over material you already have is typically weeks. What extends it is content: discovering that the policies it needs to quote are inconsistent, or exist only in someone’s head. That work has to happen anyway — the chatbot just makes it unavoidable.
Will it handle Arabic properly?
Only if it is built and tested for it. Arabic capability is not a checkbox — it depends on model choice, on how your source material is prepared, and on testing against genuine customer messages including dialect and mixed Arabic-English. I test both languages against your own historical conversations, and someone who reads Arabic reviews the output before launch.
Can it connect to our systems, or only answer questions?
Both, and they are different levels of risk. Reading from a system — order status, availability, account balance — is straightforward. Writing to one is where confirmation steps, validation and audit logging become essential. I would generally launch a read-only version first and add actions once the assistant has earned some trust.
What does it cost to run?
There is a per-conversation cost that does not go away, so it should be modelled at realistic volume rather than pilot volume. It is usually modest against the alternative, but it is a line item that will be questioned at some point, and it is better to have the number ready than to be surprised by it.
What if it gives a customer wrong information?
You reduce the chance by grounding it strictly in approved material and testing it on the questions it should refuse. You manage the remainder by design: keep it away from commitments it cannot make, log every conversation, make handover easy, and be clear to the customer that they are talking to an assistant. Anything with legal or financial consequence should be prepared by the assistant and confirmed by a person.