The UAE's first transactional banking chatbot

Context

Mashreq Bank is one of the UAE’s largest private banks. Mashreq Neo, launched in 2017, was its pioneering digital-banking arm, an entirely app-based banking experience built to serve UAE residents who weren’t well-matched to traditional branch banking.

The Mashreq Neo user base was specific in a way that mattered for product design. The majority were low-income workers from South Asia (Pakistani, Indian, Bangladeshi, Sri Lankan, Filipino), sending remittances home, managing accounts in their second or third language, and operating on tight time margins between long shifts. The product question wasn’t “how do we make banking elegant”, it was “how do we make banking fast enough that someone with 20 minutes between shifts can resolve what they need.”

I joined the Direct Banking Channel (DBC) team in February 2019 to design Mashreq Neo Connect, what would become the UAE’s first transactional digital banking chatbot, and the first chatbot in the region that didn’t just answer questions but actually executed banking operations on the user’s behalf.

The work

I spent my first month at Mashreq not designing anything. I took customer calls.

The Direct Banking Channel team trained me through standard agent onboarding, then put me on the phones for ~four weeks handling live customer interactions across Mashreq Neo’s full support volume. The reasoning was specific: any chatbot I designed would inherit the conversational shape of whatever the call centre was already doing, well or badly. Designing a chatbot without understanding what the call centre actually got asked, how customers actually phrased questions, and where calls genuinely got stuck would have produced an elegant chatbot solving the wrong problem.

That month produced the design brief for the chatbot in a way no amount of stakeholder interviews would have. The patterns I heard on the phones became the conversational architecture: a small number of high-volume queries (balance, recent transactions, card status, transfer status) accounting for most call volume, and a much longer tail of harder cases that wouldn’t compress into a chatbot. The high-volume cluster could be automated entirely; the long tail needed to be triaged to human agents quickly without forcing the customer through a dead-end automation loop.

After the call ops, I spent four months designing Mashreq Neo Connect: the conversational architecture, the six-vertical scope, the in-app integration with Mashreq Neo’s transactional layer, and the agent-handoff flow. The chatbot launched in-app, with web access as a secondary channel, powered by Avaya’s NLP/NLU platform, not full AI, but trained intent classification and conversational state management on top of a transactional middleware layer I helped specify.

My role

Senior UX Consultant within the Direct Banking Channel (DBC) team at Mashreq Neo, reporting into the DBC leadership.

I owned conversation design end-to-end for Mashreq Neo Connect across all six banking verticals: accounts, cards, loans, payments and transfers (including QuickRemit, Mashreq’s remittance service), Islamic banking, and customer support. The conversation architecture, the intent taxonomy, the error and fallback flows, the agent-handoff protocol, and the middleware UX (the small widgets that surfaced inside chat to confirm transactions), all of it.

I worked closely with Avaya as the platform partner, sitting through architecture sessions with their senior team to shape what the NLP/NLU layer needed to support. On Mashreq’s side, I worked across product, engineering, compliance, and the DBC call-centre operations team, the last of these especially, because the agent-handoff flow had to integrate cleanly into existing call-centre operations without disrupting how agents already worked.

The conversational flows I built lived in Lucidchart, detailed branching flows covering happy paths, error recovery, ambiguous input, and human escalation. The artifacts at the bottom of this case study show samples.

Approach

The approach was shaped by two constraints that pointed in the same direction.

Constraint one: the user base optimised for speed, not depth. Mashreq Neo’s core customers, South Asian workers managing accounts under time pressure, often in their second or third language, needed fast resolution far more than elegant conversation. A chatbot that engaged users in long sympathetic dialogue would have failed them by design. The right pattern was the opposite: detect intent fast, confirm the transaction, execute, exit.

Constraint two: the technology wasn’t full AI. Avaya’s NLP/NLU platform in 2019 was strong on intent classification within trained domains but couldn’t sustain open-ended conversation. Trying to design around an LLM-style conversational pattern would have produced a chatbot that worked beautifully in demos and badly in production. The right design pattern was bounded, deterministic flows with transactional confirmation steps. It would not demo well, but it would hold up in production.

Both constraints pointed to the same architectural decision: lean into bounded transactional flows over open conversational flows.

The implementation:

1. Intent-led entry. The chatbot’s first action on any session wasn’t “Hi, how can I help you?”, it was a small set of large-tap buttons covering the top intents observed in call-ops (balance, recent transactions, card status, transfer). Text input remained available for users who knew exactly what they wanted to type, but the visual entry shortcut handled the majority of sessions in one tap.

2. Middleware widgets for transactional confirmation. Where a user wanted to execute a transaction (send money, freeze a card, pay a bill), the chatbot surfaced a small widget inline, not a redirect to another part of the Mashreq Neo app, that handled the confirmation step. This kept the user inside the chatbot context and reduced abandonment at the transaction step.

3. Aggressive agent-handoff for ambiguous cases. Rather than letting the chatbot try (and fail) to handle hard cases, I designed an agent-handoff flow that triggered on three signals: explicit user request (“speak to an agent”), repeated intent-classification failure within a session, or detection of high-stakes vocabulary (fraud, dispute, complaint). Handoffs surfaced the full chat transcript to the agent so customers didn’t have to re-explain.

4. Verticalisation by domain, not by feature. The six banking verticals weren’t six feature areas, they were six conversational domains, each with its own intent taxonomy and confirmation patterns. Islamic banking, for instance, used different transaction language, different confirmation phrasing, and different verticals had different escalation criteria. Treating them as separate conversational domains rather than one unified chatbot let each vertical optimise for its actual user needs.

Key decisions

01 — A month of call-centre ops before any design work

Before designing the chatbot, I took customer support calls for approximately four weeks. The decision was non-obvious in 2019, most UX leads coming into a project would have started with stakeholder interviews and design workshops. The reasoning: a chatbot that handles low-volume queries elegantly but misses the actual patterns of customer demand would have shipped as a launch-day success and a six-month failure. The call-ops month produced the intent taxonomy directly from production data, what customers actually asked, in the actual phrasings they used, at the actual frequencies they appeared.

02 — Bounded transactional flows over open conversational design

In 2019, the prestige-conversational-AI pattern was “the chatbot that can chat about anything.” For Mashreq Neo’s user base, workers needing fast resolution under time pressure, that pattern was wrong on every dimension. I argued for the opposite: tight intent classification, bounded flows, deterministic confirmation patterns, in-line transactional widgets. It wouldn’t impress in a video demo, but it would resolve a balance check or a transfer in seconds, which is what a customer between shifts actually needs.

03 — Agent fallback as a product feature, not an admission of failure

Most chatbot projects in this era treated human handoff as a sign of system weakness. I argued for the opposite: aggressive, transparent handoff was a competitive advantage. The chatbot was strongest when it knew exactly which cases it shouldn’t try to handle. The agent-handoff flow surfaced the full chat transcript to receiving agents, eliminated the “explain it again” friction, and turned the chatbot from a deflection tool into an operational integration layer, chat-handling capacity that agents could pick up alongside calls. This decision became the basis for the most important outcome (covered below).

Outcome

The launch metric was a 30% reduction in direct call durations across the six banking verticals. That number landed and was reported internally as the project’s success metric.

The real outcome was bigger and slower.

Over the months following launch, the Direct Banking Channel didn’t just deflect calls to the chatbot, it restructured around the chatbot. Mashreq’s DBC reduced its agent headcount as fewer calls came in, but more importantly, agents took on chat case handling alongside phone calls. Each agent’s effective case capacity expanded because chat sessions could be handled in parallel in ways calls couldn’t. The chatbot became the operational backbone of Mashreq’s direct banking channel rather than a side-channel deflection tool.

That operational shift is what counts. The 30% was a chatbot metric; the integration into the call centre was a product result. The chatbot stopped being a feature inside Mashreq Neo and became infrastructure inside Mashreq’s customer operations. The agent-handoff design is what made that possible: it let chat and calls share one queue.

The chatbot launched as Mashreq Neo Connect; the product name was simplified to “the bot” in later iterations. Mashreq Neo Connect was, at launch, the UAE’s first transactional digital banking chatbot, meaning it didn’t just answer questions but actually executed banking operations (transfers, card actions, bill payments, QuickRemit transactions) on the user’s behalf. That “transactional” distinction was the entire technical and design difference between Mashreq Neo Connect and the informational chatbots most regional banks deployed in 2019 and 2020.

What I’d do differently

Two things I’d change.

I’d have leaned harder on quick-resolution flows over conversational sophistication. The chatbot worked, but in retrospect we spent more design energy on conversational quality (graceful error recovery, natural-language interpretation, polite escalation phrasing) than the user base actually needed. Mashreq Neo’s core customers wanted speed. The optimisation that mattered was time-to-resolution, seconds from intent to executed transaction, not the elegance of the conversation between them. The next version of this product, if I were rebuilding it, would strip another layer of conversational scaffolding and add another layer of one-tap shortcut flows.

I’d have shipped Malayalam. A meaningful share of the Mashreq Neo user base were South Indian workers, Keralite, Tamil-speaking, for whom English-first banking conversation was already a friction layer. Malayalam in particular would have served a community that’s underserved in UAE digital banking generally. The argument against it at the time was scope and resourcing; the argument for it was that it would have removed a real layer of friction for a meaningful chunk of the user base. I should have pushed harder. The technical infrastructure (Avaya’s NLP/NLU layer) could have supported it; the limiting factor was institutional appetite, and I didn’t argue strongly enough.

Both regrets come from the same place: in 2019 the prestige version of conversational AI was English-first and elegant, when what Mashreq Neo’s users needed was multilingual and fast. I got the architecture right but didn’t push it far enough in either direction.

Artifacts