Connecting AI to WhatsApp: an agent that answers your customers in Arabic, day and night

"We want an AI bot on WhatsApp to answer customers." But between that sentence and a bot that gives a real customer the right answer at 11 pm, there are several decisions. Most bots that go wrong went wrong because someone skipped one of them.

This post is about the connection itself: how an AI model becomes an "agent" on your business's WhatsApp number, one that knows your information, reads from your systems, and knows when to stop talking. For the broader picture of Arabic customer service bots, read what an AI chatbot can actually do first.

First decision: a button bot or an AI agent?

There are two kinds, and both have a place.

The button bot (a menu): "Press 1 to book, 2 for prices." Predictable, cheap, and it cannot make things up. It fits when requests are few and well defined: booking a slot, tracking an order, picking a branch.

The AI agent: the customer writes in their own words ("send me last month's invoice", "how much is a cleaning and are you open tomorrow?") and the agent understands and replies. It fits when questions are many and varied and do not fit in a menu.

Often the right answer is both. The AI handles free text, and for the sensitive steps (confirming a booking, picking which invoice) it offers clear buttons instead of relying on its reading of a sentence.

Where does the agent's knowledge come from?

This is the most important decision. A language model knows nothing about your business. Without your information, it answers with what sounds reasonable, and that is wrong.

The working setup separates two things:

1. Instructions: how it speaks, what it may and may not do, when it hands over. Written once and tuned.
2. Knowledge: services, prices, hours, the return policy, branches, frequent questions. This changes, so you edit it yourself, without a developer.

The real risk is the "nearby" answer

We have seen this first hand. The model rarely invents something out of nothing. It invents something next to the truth: the price of a similar service, another branch's hours, last year's policy. The worst moment is when the customer pushes back ("are you sure? your website says otherwise") and the model defends itself by producing a new number that is closer, and still wrong.

The fix is not a smarter model. The fix is rules:

• Prices and dates come from one place only: the knowledge base or a lookup in your system. If the number is not there, the agent does not say it.
• "I don't know" is an allowed answer, paired with a handover: "let me check that with the team."
• No defending, no bargaining: if a customer disputes a price, the agent passes the chat to a person rather than recalculating.

Reading live data: Odoo as the example

An agent answering from a static document covers "when are you open" and "how much is it". But a large share of customer questions are about their own things: where is my order, what do I owe, send me my invoice.

That is where the system connection comes in. Once the agent is connected to Odoo (or whatever you run), it has tools it can call:

• The customer writes "I need my invoices". The agent identifies them by their phone number, asks Odoo for their invoices, shows the list, the customer picks one, and the agent sends the actual invoice PDF into the chat.
• "What happened with my order?" It reads the order's current status, not whatever it remembers.
• "What is my balance?" It returns the figure straight from the system.

The rule: describing an action is not performing it

The agent sometimes writes "I've sent you the invoice" when it has sent nothing. A fluent sentence about an action is not the action. The instructions must be explicit that the agent only says "done" after it has called the tool and received a successful result, and this exact case needs testing before launch.

If your Odoo needs a small module to expose that data cleanly, that is what custom Odoo add-ons are for.

When does the agent hand over to a person?

A bot that cannot hand over is worse than no bot. The handover should happen, no debate, when:

• The customer asks for a person.
• There is a complaint or visible frustration.
• Money is in dispute: a discount, a refund, a double charge.
• The agent is not sure of the answer.

After the handover, the agent goes quiet

Once a team member takes the chat, the agent must stop replying to that customer completely.

The part people forget is when the agent comes back. If it returns hours later with no idea what happened, it greets the customer as if nothing is open, and an annoyed customer gets more annoyed. Either the agent returns knowing there was a case with the team, or it stays out of that conversation until a person closes the case.

Dialect: test with real messages

Current models read Saudi dialect well: "ابي", "وش", "بكرا", missing hamzas and dots included. But understanding dialect in a demo is not the same as understanding your customers.

The useful test is to take real messages from last month's chats and feed them to the agent unchanged. An hour of that shows you exactly what is missing from the knowledge.

Voice notes and images

Customers will send voice notes and photos. The question is what happens when they do.

The common failure is the bot ignoring them silently while the customer waits for a reply that never comes. Decide up front:

• the agent understands them (speech to text, reading the image) and replies,
• or it replies clearly: "got your voice note, I'm passing you to someone on the team",
• or it hands over immediately.

What matters is that no message goes unanswered.

Cost: what actually drives it?

People expect cost to grow with how much the agent knows. In what we have measured, the bigger driver is reply length. An agent that writes a full paragraph in answer to "when are you open" costs more, and the customer does not read it anyway.

Short, direct replies save money and read better. That is a setting in the instructions.

How to launch without surprises

1. Start with the repeated questions. Pull the most frequent questions from your chats and write their answers into the knowledge.
2. Let the team try to break it for a week before any customer sees it.
3. Launch and watch. For the first weeks, read the conversations daily. Every wrong reply is a missing fact or a missing rule.
4. Fix and keep going. A good agent is built by weekly review.

Before any of this you need a working WhatsApp API number, and that has its own steps, covered in setting up WhatsApp API from zero and connecting it to Odoo.

Quick questions

Can the agent run on my current number?

Yes, once the number is on the WhatsApp API. The number stays the same, and the agent works on it alongside your team in one shared inbox.

What if it gets something wrong with a customer?

You open the conversation, see what was missing (a fact or a rule), and fix it.

Does it work for clinics?

Yes, with hard limits: no diagnosis and no medical advice. We cover that in WhatsApp chatbots for clinics.

Do I need Odoo?

No. The agent works from the knowledge base alone. Connecting Odoo or your own system adds the questions about the customer's own things: invoices, orders, balance.

How we do it

We activate your official WhatsApp number, write the agent's knowledge from your real information rather than a template, connect it to Odoo or your system so it actually reads invoices and orders, and set up the handover to your team. The agent runs on K-Message, our platform built on the official WhatsApp Cloud API; Kerneltics is a Meta-approved Tech Provider. After launch we watch the conversations and fix the replies that miss.

More on the WhatsApp API page, or book a consultation and we will look at which of your messages an agent can take on.