Most Kuwaiti businesses do not have a chatbot problem. They have a queue problem. Messages arrive on WhatsApp at ten at night, on Instagram during a campaign, and on the website form that nobody checks until Sunday, and the same four questions get answered by hand, badly, at different speeds, by whoever is free. A conversational assistant is worth buying when it shortens that queue without lying to anyone. It is worth refusing when it just moves the queue somewhere the customer cannot see.
I work as a conversational AI consultant in Kuwait: deciding what should answer, what must reach a person, what the assistant is allowed to promise, and what it costs to keep running after the launch photograph. Some of that work ends in a build. A reasonable amount of it ends in a decision not to build.
The conversation has already started somewhere else
The first design decision is not which model to use. It is which thread the customer is already in. In Kuwait that is usually WhatsApp, sometimes an Instagram direct message during or after a campaign, and only occasionally the contact form on the website. A company that builds a chat window on its homepage and nothing else has built an assistant for the channel its customers use least.
That matters commercially, not just architecturally. WhatsApp is not an open pipe: business messaging runs on a customer service window that opens when the customer writes to you and closes again, and outside that window you are sending a pre-approved template, not a free-form reply. Meta’s template documentation sets out what a template may contain and the approval it needs, and its pricing documentation sets out what messaging costs once volume is real. Those two rules shape the assistant more than the model choice does. An assistant designed as though it can talk whenever it likes will be redesigned the first month the invoice arrives.
So the first question I ask is not “what should it say” but “where is this conversation, who owns that account, and what is allowed to happen inside it”.
What it has to know before it can answer anything
An assistant that cannot see your systems is a search box with better manners. The questions Kuwaiti customers actually send are not general knowledge questions. Is this in stock. How much with delivery to Jahra. Where is my order. Can I change the address. Every one of those needs a live answer from a system, and the honest version of this project is mostly integration work.
Modern models are built for this: they call your systems rather than guess, and the discipline is set out in Anthropic’s tool use overview and in OpenAI’s retrieval and tools guides. The engineering question is which of your systems can answer in under a second, which need a cached copy, and which should never be exposed to a conversation at all.
Where that connection does not exist yet, I will say so before the assistant is scoped rather than after. An assistant bolted onto a business whose stock lives in one person’s head will produce confident, wrong answers at scale, which is worse than the queue you started with.
Kuwaiti Arabic goes in, and something else has to come out
Customers here do not write to businesses in formal Arabic. They write in Kuwaiti dialect, they switch to English mid-sentence for product names and sizes, and they use spellings no dictionary contains. The assistant has to understand that. What it sends back is a different decision: most Kuwaiti companies want replies in clear, plain Arabic rather than dialect, because a brand writing in dialect reads as a person, and a person who is not there at eleven at night creates a problem the moment the customer expects one.
That asymmetry — dialect in, plain Arabic out — has to be decided at the start, because it drives the test set. I have written elsewhere about what actually works and fails in Arabic customer service; on an engagement it becomes a list of real messages, pulled from your own inbox, that the assistant must handle before anyone signs anything off.
The three sentences it must never say
Every assistant needs a written list of things it is not allowed to state, and in Kuwait the list is short and specific.
- A price it has not read from your system. A quoted price is treated as a promise, and an assistant that infers one from an old campaign will be held to it.
- A delivery date it cannot verify. “Tomorrow” is a commitment. “Usually one to two working days, and you will get a message when it ships” is information.
- Anything about a refund. Card refunds move on the bank’s timetable, not yours. What KNET and your bank actually require sits in the KNET requirements a store has to meet, and an assistant that promises a timeline there creates a complaint rather than closing one.
The list is written down, it is tested, and it is the first thing I check when someone tells me their assistant “went wrong”.
The handover is a contract, not a fallback
Most disappointment with assistants is not a language failure. It is a handover failure: the customer asks for a person, the assistant keeps answering, and the thread ends. A handover that works names a person or a team, states an hour, and actually creates the task on the other side. A handover that does not work says “our team will contact you soon” into a void.
Some messages should never meet an assistant first at all — a complaint, a message about a person, anything where the customer has already lost something. That sorting is a design decision taken before launch, and I have set out the reasoning in which enquiries should never reach a machine first.
What I actually do on this engagement
- Read a month of your real messages and sort them by what they need: an answer from a system, a judgement, or a person.
- Decide the channel, the account ownership and what the platform rules allow inside it.
- Write the refusal list, the handover contract and the escalation path, in language your team can audit without me.
- Build the test set from your own messages, in the Arabic your customers actually write.
- Specify the integrations, and say plainly which ones do not exist yet.
- Price the year, not the launch — the messaging bill, the model bill, and the person who maintains the answers.
Where the build follows, it is delivered by my company, Tothiq, which builds custom AI assistants. Where a form and a working rota would serve you better, I will tell you that instead, and it costs you one conversation rather than a project.
What it costs, in shape rather than in a number
Three lines, and they behave differently. The build is one-off and is mostly integration, not prompting. The messaging bill scales with conversations and is governed by the platform rules above, not by you. The model bill scales with length and with how much of your own data you send each time. The fourth cost is the one nobody quotes: somebody has to own the answers, because a price list changes and an assistant repeating last season’s is a liability with good grammar.
What you are renting and what you keep when the contract ends is worth settling in writing at the start; I have written about what you own when an AI service ends for exactly this reason.
The three numbers that tell you it worked
Not “conversations handled”. That number rises when the assistant is useless, because people repeat themselves. Measure instead: the share of conversations that ended without a person and without the customer writing again within two days; the time from a customer asking for a person to a person actually replying; and the number of messages the assistant refused correctly. Governance frameworks such as the NIST AI Risk Management Framework make the same point in more formal language: a system is measured by its behaviour in the cases it gets wrong, not by its volume.
If you want the wider picture first, the AI consulting page covers how an engagement starts, and chatbot development in Kuwait covers the build itself once the decisions on this page are made.
Frequently asked questions
Our customers message us on Instagram, not WhatsApp. Does that change anything?
It changes the rules, the costs and who owns the account, so yes. Instagram direct messages behave differently from WhatsApp business messaging, and the account usually sits with whoever runs the marketing rather than with operations. The design work is the same — what answers, what escalates, what it may never promise — but the platform constraints and the billing are not interchangeable. If your volume is genuinely split across both, we decide which one gets the assistant first rather than launching on two at once and maintaining two sets of answers.
We already have a chatbot from a vendor. Is this a rebuild?
Often it is not. A large share of disappointing assistants are correctly built and badly bounded: no refusal list, no working handover, and answers nobody has updated since launch. Those are fixable without replacing the platform. I would rather spend two days reading your transcripts and telling you the thing works but is pointed at the wrong questions than sell you a rebuild you did not need. Where the platform genuinely cannot reach your systems, that is a real limit and I will say so.
Who writes the answers — your team or ours?
Yours, with structure from me. The content is your prices, your policies and your delivery reality, and an outsider writing those creates a document that is accurate for one month. What I provide is the shape: which answers must come live from a system, which can be written once, and which must never be written at all. Somebody in your company has to own that document afterwards. If nobody will, the project should not start, because an assistant repeating an old price is worse than no assistant.
What happens when volume triples during a campaign or in Ramadan?
The assistant absorbs it and two other things break. Messaging costs scale with conversations, so a campaign that works produces a bill that surprises whoever approved the budget — that belongs in the year’s numbers before launch, not in an invoice afterwards. And the handover path floods: three times the conversations means three times the escalations, into a team that has not tripled. What gets held in a queue, and what the customer is told while they wait, is decided in the design rather than improvised on the night.
Can it take an order and payment, or only answer questions?
It can carry a customer to the point of payment and should almost never try to complete one inside the conversation. Sending a checkout link into the thread keeps the payment on your existing, approved rail with its own receipt and refund path, which is what your bank and KNET expect. Building a parallel payment flow inside a chat window means a second thing to secure, reconcile and support, for a convenience most customers do not ask for. Where an assistant genuinely should act rather than answer — booking, rescheduling, checking an order — that is a decision taken deliberately, with a written limit on what it may do without a person.