What Dubai’s RTA Can Teach Support Teams About Serving Arabic and English Users

When Dubai’s Roads and Transport Authority added driving-test appointments to its Mahboub WhatsApp assistant in January 2024, it had a specific task in mind. A customer needed to choose or change a slot, pay and find out whether the booking had gone through. Mira Ahmed Al Sheikh, then RTA’s director of smart services, explained that the registered phone number and user information supported the WhatsApp route. RTA said Mahboub was available in Arabic and English. The appointment is a useful test of what that commitment means. An answer in the right language can get a customer started. The service still has to guide them through eligibility, payment and confirmation. RTA’s appointment launch statement

A support leader can use the same test on an appointment, subscription change or delivery issue. Pick one task with a clear end point, then check whether someone can reach it in either language and recover when a step fails. That means bringing support agents, content owners and the team that runs the transaction into the same review. They each see a different reason a customer might come back for help.

Follow the task across the channel

RTA’s public road-test instructions distinguish the website and app chatbot from WhatsApp. For the website and app, the documented route asks for a traffic file number and year of birth, followed later by a one-time password sent to the registered number. For WhatsApp, the guide says Mahboub checks whether the phone number is linked to a valid learning permit and whether the customer passed the knowledge test. The customer then selects or changes an appointment, pays and receives a transaction reference. That published sequence is a description of the service, with different checks depending on how the customer arrives. RTA road-test appointment instructions

For a support team, the channel difference matters as much as the words. Imagine a Dubai customer who uses English at work and prefers Arabic for instructions about an appointment. The customer opens a chat from a number the service cannot match. The first useful reply identifies what happened and shows what the person can do from that state. If the reply just repeats the instruction to book an appointment, the person may start another conversation or try an unrelated test type. A team testing a similar flow should include an unmatched record in its release check and have a service owner verify the recovery instructions.

RTA also publishes an Arabic service listing for booking and changing a driving-test appointment. The name in a catalogue can give the team an authoritative term to use in formal instructions. People may still ask in everyday wording. In either language a service needs to distinguish the task from neighbouring ones. A request to move a test already on the calendar requires different information from a request to make the first appointment. A brief clarification can preserve that difference before the service offers an action. RTA Arabic service listing

RTA’s January 2024 Instagram carousel announced the WhatsApp booking route. Its bilingual caption describes the launch, and the first frame shows an Arabic chat on a phone. The current road-test instructions supply the operational details.

Keep policy and transaction state consistent

Start with the information that determines what a customer can do. A shared service record can name the allowed actions, the eligibility checks, which channel can carry them out and the exact evidence that the action succeeded. Writers can then explain the same rule in language customers recognise. If a service change alters a deadline, an owner can update the underlying rule and check every place it appears, including a support macro and the message sent after a failed attempt.

Status language deserves special attention. A service may tell a customer that it received a request, that payment succeeded or that an appointment was confirmed. Those messages refer to different events. Consider a fictional booking system where a payment can be recorded before a reservation is final. A message that collapses those states may prompt someone to turn up for an appointment that never made it onto the calendar. The equivalent Arabic and English replies should identify the same state, say what is pending if anything, and tell the person which reference to keep.

Build a small set of approved examples alongside the rules. Use a confirmed appointment, a request that still needs verification and a case that cannot proceed. Include language mixed with an English product name, digits entered in both commonly encountered forms and a copied reference number inside an Arabic sentence. Check the result on the device a customer uses. A screen may display the sentence in the expected direction while the reference, date or time becomes difficult to read. A reviewer can catch the problem by copying the reference and using it to retrieve the test record.

A human review should ask what the customer would do next. Give an Arabic reviewer and an English reviewer the same fictional case and ask each to follow the guidance without seeing the expected answer. If one proceeds to payment while the other opens a new booking, identify the line or button that prompted the difference. This finds defects a sentence-by-sentence translation comparison can miss. Keep the correction with the service record so the next revision does not reintroduce the same problem through a different channel.

Give the next person enough context to help

RTA lists its chatbot alongside other contact and service channels. That makes the case a useful starting point for thinking about how customers move between channels. For a support operation designing its own handoff, the question is what the next agent receives when an automated attempt reaches a limit. An agent who knows only that someone tried to book will have to reconstruct the case. A short summary can state the intended action, language preference, step reached and what the system has confirmed, subject to the organisation’s controls for sharing customer information. RTA contact channels

Take a fictional customer who begins in Arabic, switches to English to paste a confirmation message and then asks for an Arabic explanation of what it means. The transfer should carry the preference the person has expressed and the outstanding question. If there is an appointment reference the agent can lawfully see and use, send it through the approved system. Keep authentication and payment secrets out of the case summary. The agent needs enough to pick up the task without asking the customer to recount every step.

Routing and staffing need to support that promise. A team can review when Arabic and English cases arrive, which tasks require a specialist and what happens when an agent cannot respond immediately. Give staff a way to flag a translated message that repeatedly causes confusion. A reviewer can then trace the wording to its owner and check whether the underlying process also needs a change. Otherwise the same agent may keep fixing the same problem by hand while the published answer stays in place.

Measure whether customers reach the same result

A language dashboard can start with completed tasks, repeated contact and recoveries after a failed step. Group the figures by task, channel and chosen language. Give agents a way to record a change of language without treating the second language as a new case. A support lead can then see whether customers encounter the same problems at the same steps and ask whether a gap comes from the wording, the route or the mix of cases.

Suppose, in an illustrative week, 72 of 100 Arabic rescheduling attempts and 84 of 100 English attempts reach confirmation. That is a 12 percentage point difference. Before changing either script, check whether the groups used the same channels and entered at the same stage. One group may have more cases with a phone number that cannot be matched. Compare similar cases within each channel and read examples of attempts that stopped. If the difference persists around one message or button, test a revised version with speakers of that language before changing the live flow.

A short review of successful cases helps too. A customer might reach confirmation after opening a second chat or calling an agent. From the booking system’s perspective the task completed. From the customer’s perspective the first route failed. When those events can be joined appropriately, distinguish direct completion from completion after another contact. The two counts help the service team decide whether to fix the self-service step or increase capacity for the support route customers are already using.

Apply the same check when the assistant can do more

RTA has since described an enhanced Mahboub version that can coordinate steps such as paying a vehicle fine and then renewing registration. The announcement says the enhancement was being prepared for public rollout and names Arabic and English support. That is a separate development from the documented driving-test booking route. It illustrates a design challenge for any team adding actions to a support assistant. Once several steps run in one conversation, the customer needs to know which action has happened and what remains if the sequence stops midway. RTA’s announcement on the enhanced Mahboub assistant

A service owner can define those checkpoints before the release. For each step, decide what needs confirmation from the customer, which system records the result and which message the customer receives. If an earlier action succeeded and a later one failed, provide a way to resume or seek help without repeating the earlier action. Then test the same interrupted sequence in Arabic and English. That exposes differences in how the service interprets an instruction, describes what it has already done or passes the case to someone who can finish it.

For a Dubai support lead choosing what to improve first, pick a task where a second contact is common and the end state is visible in the operating system. Follow it with reviewers and agents who work in each language, and assign an owner to the step where customers lose their place. The useful release check is whether a customer can understand the current state and reach the next one with the same choices and safeguards in either language.