Building Arabic and English AI Support Chatbots

Why Bilingual Support Is Harder Than It Looks

Plenty of chatbots speak English well. Far fewer handle Arabic with the same fluency, and that gap is exactly where many businesses in the region lose customers. A bilingual support bot is not an English bot with translation bolted on — Arabic brings its own demands, and ignoring them produces a bot that feels foreign to the people it serves.

Done right, a bilingual AI chatbot handles the bulk of routine questions in either language, around the clock, and hands the hard cases to your team with full context. Done wrong, it answers English customers fluently and Arabic customers awkwardly — and because the people building it often test mostly in English, that gap can ship unnoticed and quietly erode trust with the larger half of your audience.

The difference between the two outcomes is rarely the language model itself. Modern models handle Arabic far better than they did a few years ago. The difference is in the engineering and testing decisions around the model: what content you ground it in, which dialects you test against, how you render the text, and where you set the handoff bar. This article walks through each of those decisions.

The Arabic Challenges You Must Plan For

Dialect versus Modern Standard Arabic

Customers do not write in Modern Standard Arabic (MSA). They write in their dialect — Gulf, Egyptian, Levantine, Maghrebi — and these differ enough to trip up a model trained mainly on MSA. Your bot needs to understand dialect input even if it replies in clean MSA. Test with real customer messages, not textbook Arabic.

Right-to-left and mixed-script text

Arabic is right-to-left, and customers routinely mix in English words, product names, and numbers within one sentence. Your interface must render RTL correctly and handle bidirectional text without scrambling the layout. This is a front-end detail that customers notice immediately when it is wrong.

Diacritics, spelling, and informality

Arabic is often typed without diacritics and with inconsistent spelling. A robust bot tolerates this variation rather than failing on it. The same applies to "Arabizi" — Arabic written in Latin letters and numbers, like "kaif el 7al" or "3ayez a3raf" — which is extremely common in chat, especially among younger customers on mobile. A bot that only recognises clean Arabic script will silently misread a large share of real messages.

The practical defence is normalisation and breadth of test data. Normalise common spelling variants (the different forms of alef and ya, for instance) before the model sees the text, and build your test set from genuine customer transcripts that include the misspellings, the missing diacritics, and the Arabizi. If your test cases are all written in careful MSA, your evaluation will look great and your production results will not.

Numbers, dates, and currency

A detail that quietly breaks bots: Arabic content mixes Western digits (1, 2, 3) and Eastern Arabic digits (١، ٢، ٣) freely, sometimes in the same message. A customer might type an order number in one and a phone number in the other. Your normalisation should map both to a single form before the bot tries to match against records, or it will fail to find an order that's sitting right there in the database. Dates and currency carry similar traps — formats and even the calendar in use can vary — so test the bot against the way your customers actually write a date or a price, not the way a developer assumes they do.

Architecture: Keep the Bot Grounded

A support bot that invents answers is worse than no bot at all. The reliable pattern is retrieval-augmented generation: the model answers only from your actual help content.

• Store your FAQs, policies, and product docs in both languages.
• When a customer asks something, retrieve the relevant documents first.
• Have the language model answer using only those documents, in the customer's language.

This keeps answers accurate and current. Update the document, and the bot's answer updates with it — no retraining. See our LLM integration approach for how we wire this up.

A bilingual twist worth planning for: keep your source content in both languages and retrieve in the language the customer is using. If a customer asks in Arabic but your only documentation is in English, the model will translate on the fly — and translation errors on policy details (refund windows, eligibility rules, prices) are exactly the kind of mistake that turns into a complaint. Where accuracy matters most, have native-language source content rather than relying on the model to translate it live. Where you genuinely can't maintain parallel content, at least flag those answers for tighter review.

Detect Language, Then Respect It

The bot should detect whether a customer wrote in Arabic or English and respond in kind — and switch instantly if the customer switches. Forcing a customer to pick a language up front is friction. Let the first message decide, and follow the customer's lead from there.

Two edge cases trip up naive implementations. First, code-switching: a customer might write mostly Arabic but drop in an English product name or a whole English sentence mid-conversation. Don't let one English noun flip the entire reply to English. Weight the detection toward the dominant language of the message and stay consistent unless the customer clearly switches for good. Second, the greeting problem: very short opener messages like "hi" or "السلام عليكم" carry little signal. It's fine to mirror the greeting's language for the first reply, then re-detect once the customer states their actual question.

Know When to Hand Off

The goal is not to deflect every conversation — it is to handle the easy ones well and escalate the rest gracefully. Build clear handoff rules:

• When the customer asks for a human, hand off immediately. Do not fight them.
• When confidence is low or the topic is sensitive (billing disputes, complaints), escalate.
• Pass the full conversation and detected language to the agent, so the customer never repeats themselves.

A smooth handoff is what separates a bot customers tolerate from one they trust.

Measure the Right Things

Track metrics that reflect customer experience, not just volume:

• Resolution rate — share of conversations the bot fully resolved.
• Handoff rate — and why each handoff happened, so you can close gaps.
• Customer satisfaction — per language, because Arabic and English experiences can diverge sharply.
• Containment by intent — which question types the bot handles well, and which it does not.

Watching satisfaction split by language is the single best way to catch an Arabic experience that is quietly underperforming.

Privacy and Tone

Support conversations contain personal data — handle it accordingly, and never log more than you need. Mask or redact sensitive fields like card numbers and national IDs before they reach logs or the model, and be clear in your retention policy about how long transcripts are kept and who can see them. In several markets in the region this is a legal requirement, not just good practice.

Tone matters too, and it's where Arabic experiences most often go subtly wrong. A bot that is warm and clear in English but stiff and overly formal in Arabic feels off — like reading a legal contract when you expected a helpful reply. Arabic also carries levels of formality that English doesn't map onto cleanly; the right register for a banking customer differs from the right register for a food-delivery app. Have native speakers define the intended voice up front, review the bot's Arabic replies before launch, and keep reviewing them as you expand coverage. Machine-translated tone is the giveaway that tells customers a bot wasn't really built for them.

Your Best Training Data Is Already in Your Inbox

The single biggest advantage in building a bilingual bot that works is something most businesses already own: their existing support history. Past chat transcripts, email threads, and ticket logs are a goldmine — they show you the real questions customers ask, in the real language and dialect they use, with the real answers your best agents gave. Mine that history to build your knowledge base, your test set, and your sense of which intents actually matter. The questions you think customers ask and the questions they actually ask are rarely the same list.

This is also where a careful provider earns their keep. Cleaning and structuring that history, deciding what to ground the bot in, and shaping it into an evaluation set is unglamorous work that makes the difference between a bot that demos well and one that holds up in production. It's the part of our AI consulting engagements that clients underestimate most and benefit from most.

A Pre-Launch Checklist

Before a bilingual bot goes live, confirm:

• It's been tested with real customer messages in every dialect you serve, including Arabizi and misspellings — not textbook MSA.
• RTL and mixed-script rendering is correct on the actual channels customers use (web, WhatsApp, app), checked on mobile.
• Numbers, dates, and order references are normalised across digit systems so lookups don't silently fail.
• The handoff path works end to end, passing full context and detected language to a human.
• Satisfaction is tracked per language from day one, so an underperforming Arabic experience surfaces in the data, not in churn.
• A native speaker has signed off on tone in both languages.

Skipping any of these tends to produce the exact failure mode this article warns about: a bot that looks fine in an English demo and quietly disappoints the larger half of your customers.

How Techies Builds These

We build bilingual support bots grounded in the client's own content, tuned on real customer messages in the dialects they actually use, with honest handoff rules and per-language quality tracking. The aim is a bot that earns trust in both languages — not one that merely passes a demo. Explore our AI agents and chatbots work to see how we approach it.

---

Want a support bot that handles Arabic and English equally well? Get in touch.