Insights


How to Use AI for Customer Service (in Arabic and English)

Line-art illustration of a chat bubble splitting into Arabic and English speech lines handed to a person, in green and gold Najdi style
Instant, correct, in their language, and it knows when to fetch a human.

AI customer service either delights your customers or drives them away, and the difference is almost never the model. It is the setup: what the assistant is connected to, when it hands off, and whether it was tested in the Arabic people actually type. This post covers which questions AI should own, what separates great deployments from maddening ones, how to get Arabic right, the PDPL side, the traps, and how to start.

Three kinds of questions, and only one belongs to the bot on day one

Every message that reaches your support inbox is one of three things. Sorting them is the first decision, and most bot frustration comes from a setup that never made it.

  • Routine, and answerable from your data. Where is my order, what are your hours, is the Dammam branch open on Friday. High volume, one right answer, and the answer already lives in a system you own.
  • An action inside a system. Change a delivery address, cancel a booking, issue a refund. The assistant can collect the details, but a rule or a person has to authorize the action.
  • Judgment, complaints, and anything emotional. An angry customer, a dispute, a health or money question. These go to a person immediately, with the conversation attached.
flowchart TD
  A(["Customer sends a message"]) --> B{"Which kind is it?"}
  B -->|Routine, answer is in your data| C(["AI answers instantly, in the customer's language"])
  B -->|An action in a system| D(["AI collects the details, a rule or a person approves"])
  B -->|Judgment, complaint, emotion| E(["A person takes over, full context attached"])
  C --> F{"Did it actually solve it?"}
  F -->|No| E
  F -->|Yes| G(["Done, and logged"])
The three kinds of questions and where each one should go.

Start with the first kind only. The second comes once you trust the assistant and have wired the approvals. The third should never be automated; the assistant’s job is to recognize it in the first message.

What separates great AI customer service from the maddening kind

  • It knows your business, not the internet. A generic bot giving generic answers is the maddening kind. A good assistant is connected to your order system, your policy documents, and the customer’s own history, so the answer is “your order left the Riyadh warehouse this morning,” not “delivery times vary.” We covered the plumbing in using your company’s own data with AI, safely.
  • It hands off gracefully, and early. The fastest way to enrage a customer is to trap them with a bot when they need a human. A good setup escalates when the customer asks, at the first sign of frustration, on any question outside its data, and on the second failed attempt. The handoff carries the whole conversation and a one-line summary, so the person never opens with “how can I help you today?”
  • It gets Arabic right. In our experience most Saudi deployments fail here. The next section is about it.
  • It is honest about what it doesn’t know. “Let me get a person for that” beats a confident invention every time. Configure the assistant to answer only from retrieved data, and to say so when there is none. A bot that invents a refund policy costs more than no bot, because you will end up honoring it.
  • It respects privacy. Customer conversations contain names, phone numbers, ID numbers, and sometimes health or financial details. That is personal data under PDPL, and it has to be designed for, not bolted on.

Getting Arabic right: dialect, mixing, and the test set

Arabic is genuinely harder for language models than English, and we explained why in Arabic LLMs: what works, what to watch for. But most support assistants stumble not because of the model, but because they were tested on the wrong Arabic. Real customers write:

  • Dialect, not Modern Standard Arabic. A Saudi customer types “وين طلبي” not “أين طلبي”. Najdi, Hijazi, Eastern Province, Egyptian, and Levantine speakers all phrase the same question differently.
  • Arabic and English mixed in one message. “ابغى أغير الـ delivery address” is a normal sentence. Product names and technical terms usually stay in English.
  • Arabizi, and no punctuation. Arabic in Latin letters with numerals standing in for letters (“3ndi moshkela fi el order”), the hamza dropped, three questions in one line.

What to do about it:

  • Build the test set from your own transcripts. Export a few hundred real conversations from WhatsApp or your chat tool and strip the personal data. That, not a vendor’s demo script, is what the assistant has to pass before launch.
  • Test the reply, not just the understanding. Dialect gets a warm, natural reply; formal Arabic gets formal Arabic; English gets English. A Najdi question answered in stiff textbook Arabic reads as a machine, even when the content is right.
  • Have a native speaker grade the pilot. Score a sample of replies weekly for correctness, tone, and whether the handoff call was right. Check the rendering too: right-to-left layout, numerals, English product names inside Arabic sentences.

A worked example, with made-up numbers

Say a retailer receives 6,000 support messages a month. Before building anything, the team tags one week of real messages by hand: roughly 60% routine, 25% actions, 15% judgment. The assistant launches on the routine kind only, resolves about three quarters of those in the pilot, and hands off the rest. That is around 2,700 conversations a month closed without a person, and the team handles about 3,300 instead of 6,000, each with a summary attached.

Four numbers get tracked from day one: resolution rate on routine questions, handoff rate, customer rating after an AI conversation versus a human one, and repeat contacts within a couple of days. That last one is the tell. A bot that “closes” conversations it did not solve shows up as the same customer coming back angrier.

The numbers are made up to show the shape. The lesson is that you can know the routine share before you build anything, and that share is what the project is worth.

Privacy and PDPL: what a support assistant has to get right

The Personal Data Protection Law took effect on 14 Sept 2023, full compliance was required by 14 Sept 2024, SDAIA is the regulator, and cross-border transfer is governed by Article 29 and SDAIA’s Transfer Regulations (Morgan Lewis, 2024). A chat transcript is personal data by definition, so all of it applies to a support assistant.

  • Where the model runs. Sending a transcript with a national ID number to a model hosted abroad is a cross-border transfer. Either choose an in-Kingdom deployment, the data residency route, or make sure the transfer is covered and documented before launch.
  • What you send. Mask ID numbers, card numbers, and phone numbers before the text reaches the model; the assistant almost never needs them.
  • Tell the customer. A short notice at the start of the chat: this is an assistant, and a person is available.
  • Retention and access. Decide how long transcripts live and who can read them. “Everything, forever, visible to everyone” is the default in most chat tools.

IBM’s 2024 study put the average cost of a data breach in the Middle East (a Saudi + UAE sample) at $8.75M, the second-highest region after the US (IBM via The National, 2024). A pile of unmasked chat logs is exactly how one starts.

Where AI customer service goes wrong

  • Launching on everything on day one. It falls apart at the edges, and first impressions with customers are hard to undo.
  • No exit. A bot with no “talk to a person” path. Customers type “agent” three times, or just leave.
  • Testing in English, or in formal Arabic. The demo looks great, the launch stumbles, and nobody knows why until they read the transcripts.
  • Measuring deflection only. Deflection counts the conversations the bot ended, not the problems it solved. Track repeat contacts and ratings, or you will celebrate a number your customers hate.
  • Nobody owns it after launch. Policies, products, and prices change. Someone has to read transcripts weekly and update what the assistant knows.

How to start without burning your customers’ patience

The pattern that works is boring and reliable. Pick one channel and one category, usually order status on WhatsApp. Tag a week of real messages so you know the routine share. Build the test set from your own transcripts, in the dialects your customers actually use. Pilot with an easy human exit, a native speaker grading replies, and the four numbers above on a wall. Expand one category at a time, only when the last one is genuinely excellent.

To make sure the pilot leads somewhere rather than stalling after the demo, run it as a proof of concept designed to reach production, with integration and privacy in scope from the start. That is how we run AI consulting engagements, and why the ones that go live stay live.

Want AI customer service that delights customers instead of frustrating them? SDCG builds bilingual AI support that knows your business, handles real Saudi Arabic and English, and hands off to humans gracefully. We’re independent, so the setup is built around your customers, not a vendor’s product. Book a free 30-minute review.

Sources

A decision you can’t afford to get wrong

A technology decision you can’t afford to get wrong?

Talk to the engineers who’ll actually build it. Independent, vendor-neutral, and aligned to Vision 2030. A free 30-minute review, no slides, no obligation.

Book a free 30-minute review