Making conversational AI operational, not ornamental.

Context

Mashreq Neo was built for customers who did not fit comfortably into traditional branch banking.

Many were managing salaries, cards, remittances, bills, and transfers while working long shifts and operating in English as a second or third language.

Their product need was not conversational elegance.

It was resolution.

A balance check needed to be fast.

A transfer-status question needed a clear answer.

A blocked card needed immediate action.

A remittance issue could not end in a polite dead end.

Mashreq wanted a chatbot that could serve this demand digitally.

At the time, most regional banking bots answered questions.

The more consequential product question was:

Could a conversation become a secure banking channel that actually completed the task?

That required more than natural-language understanding.

It required transaction logic, confirmation, middleware, escalation, compliance, and operational integration.

The chat interface was only the visible edge.

The Real Problem

The obvious product brief was to reduce call volume.

That framing was too narrow.

If the chatbot only answered simple questions, it might deflect a small number of contacts while creating a new failure mode for everything else:

Customer asks
Bot misunderstands
Bot repeats itself
Customer asks for an agent
Customer starts again

That would reduce neither effort nor operational cost.

It would simply insert automation before service.

The product needed to do three things well:

1. Resolve high-frequency requests without human help
2. Complete selected banking transactions inside the conversation
3. Recognize quickly when a human should take over

The third capability was as important as the first two.

A chatbot that did not know when to stop would make the entire channel worse.

My Role

I joined Mashreq Neo’s Direct Banking Channel to lead product discovery and conversation design for Mashreq Neo Connect.

My remit covered six banking domains:

• Accounts
• Cards
• Loans
• Payments and transfers
• Remittances
• Islamic banking and customer support

I owned:

• Product discovery
• Intent architecture
• Conversational flows
• Transaction confirmation patterns
• Error and repair logic
• Agent escalation
• Inline transactional widgets
• Cross-domain consistency
• Coordination with product, engineering, compliance, operations, and Avaya

Avaya provided the underlying NLP/NLU platform.

I did not build the language model or banking middleware myself.

My responsibility was to define how the system should behave as a product: what it should recognize, what it should execute, what it should confirm, and when it should hand control to a human.

Before designing any of that, I spent roughly a month taking customer calls.

That became the most important product decision in the project.

Decision 01 — Take customer calls before designing the conversation

The fastest way to produce a chatbot concept would have been:

• Interview stakeholders
• Review call reasons
• Map intents
• Start designing flows

Instead, I went through agent onboarding and joined live call operations.

For approximately four weeks, I listened to and handled real customer demand.

That changed the brief.

Reports described call categories.

Calls revealed their actual shape.

Customers did not speak in clean intent labels.

They mixed:

• The request
• The history
• Emotion
• Account details
• Assumptions
• Previous failures
• Urgency
• Several languages in the same sentence

A request that looked simple in reporting could be difficult in conversation.

A request that sounded complex could sometimes be resolved through one direct action.

The month exposed a clear distribution.

A relatively small number of intents created much of the volume:

• Balance
• Recent transactions
• Card status
• Transfer status
• Remittance status
• Simple payments

These were strong candidates for automation.

The long tail was different:

• Fraud
• Disputes
• Complaints
• Failed transfers
• Unusual account states
• Requests with incomplete or contradictory information

Those cases needed rapid human intervention.

The product thesis became:

Automate the predictable center. Escalate the consequential edge.

Without the month in operations, the product would likely have optimized the conversation people imagined customers were having.

Instead, it was built around the conversations that were already happening.

Decision 02 — Choose bounded transactions over open conversation

In 2019, the prestige version of conversational AI was a bot that appeared able to discuss anything.

That was the wrong product for Mashreq Neo.

The Avaya platform was strong at trained intent classification and state management inside defined domains.

It was not an open-ended reasoning system.

Designing as though it were would have created an excellent demonstration and a fragile production experience.

The customer context pointed in the same direction.

Users often had:

• Limited time
• A specific task
• Low tolerance for ambiguity
• Varying English fluency
• High consequences if the action was misunderstood

The right architecture was bounded:

Detect intent
Retrieve the right data
Confirm the action
Execute
Show the outcome
Exit or escalate

The bot did not need to sound endlessly human.

It needed to behave reliably.

That meant:

• Short paths
• Explicit confirmation
• Clear state
• Limited ambiguity
• Direct language
• Strong recovery
• No attempt to improvise beyond its capability

The product principle was:

In transactional systems, predictability is more valuable than personality.

This was not a limitation disguised as strategy.

It was the correct product response to the users, the technology, and the risk.

[ + ]

Decision 03 — Keep the transaction inside the conversation

Answering a question inside chat was straightforward.

Executing a banking action was not.

A user might ask to:

• Send money
• Pay a bill
• Freeze a card
• Check a transfer
• Complete a remittance
• Review recent transactions

The easiest implementation would have identified the intent and redirected the user to another part of the app.

That would technically connect chat to banking.

It would also break the journey at the moment of highest intent.

The user would need to:

• Leave the conversation
• Find the relevant screen
• Re-enter information
• Reconstruct the task
• Complete the transaction elsewhere

The chatbot would become a navigation layer rather than a banking channel.

We designed inline transactional widgets inside the conversation.

The chat handled intent and guidance.

The widget handled structured confirmation.

For a transfer or remittance, the experience could surface:

• Recipient
• Amount
• Fees
• Exchange information
• Source account
• Final confirmation

The user remained inside one product context.

This created a clear division of labor:

Conversation for intent. Structured UI for precision.

That was especially important in banking.

Natural language is flexible.

A transaction must be exact.

The hybrid pattern preserved the speed of conversation without asking free text to carry the full burden of financial confirmation.

[ + ]

Decision 04 — Design human handoff as a core product capability

Most chatbot programs treated escalation as failure.

The ambition was containment: keep as many customers inside automation as possible.

That creates a dangerous incentive.

The bot continues trying long after the customer would be better served by a person.

I treated handoff as part of the product architecture.

Escalation could be triggered by:

• An explicit request for an agent
• Repeated intent-classification failure
• High-stakes vocabulary
• Fraud or dispute signals
• Complaint language
• Unsupported transaction states
• Rules defined by operations or compliance

The handoff carried the conversation context with it.

The receiving agent could see:

• What the customer asked
• What the bot understood
• Which steps were completed
• Where the failure occurred
• Relevant transaction or account context available to the system

The customer did not need to begin again.

This changed the role of the chatbot.

It was no longer only a deflection tool.

It became an intake, resolution, and routing layer for the direct-banking channel.

The product principle was:

A good automated system is not the one that avoids humans. It is the one that uses them at the right moment without discarding context.

That decision became central to the operational outcome.

Designing Across Six Banking Domains

The chatbot was not one conversation stretched across multiple topics.

Each banking domain had different:

• Intent taxonomies
• Data requirements
• Confirmation language
• Risk levels
• Error states
• Escalation conditions
• Compliance requirements

A balance request and a remittance request could not share the same interaction logic.

Islamic-banking terminology could not simply inherit conventional product language.

Card actions required different confirmation and security patterns from account information.

We treated each domain as its own conversational product inside one shared system.

The common architecture covered:

• Entry
• Intent detection
• Authentication
• Confirmation
• Recovery
• Escalation
• Closure

The domain layer defined the banking behavior.

This created consistency without pretending every transaction was equivalent.

[ + ]

Designing for Speed, Not Theater

A conventional chatbot greeting might begin:

Hello. I’m Neo Connect. How are you today, and how may I assist you?

For this product, that was wasted time.

The entry experience emphasized the highest-volume tasks with large, clear options while preserving text input for users who knew exactly what they wanted.

The goal was to shorten the distance between intent and resolution.

Not every interaction needed to feel conversational.

Some needed to feel immediate.

That distinction shaped:

• Shorter prompts
• Clearer choices
• Fewer unnecessary acknowledgements
• Direct confirmations
• Compact error recovery
• Visible escape to human support

The interface respected the customer’s time by refusing to perform intelligence for its own sake.

[ + ]

Outcome

Mashreq Neo Connect launched as the UAE’s first transactional digital-banking chatbot.

The distinction was important.

The product could do more than answer questions.

It could support real banking actions across six domains.

The initial outcomes included:

• 20% engagement across the customer base at first launch
• 30% shorter direct-call durations
• Automation of high-frequency banking intents
• Faster routing of complex cases
• Transaction completion inside chat
• Shared context between automated and human service

The larger outcome emerged over time.

The Direct Banking Channel began operating differently around chat.

Agents could handle chat cases alongside calls.

The system could resolve simple requests, structure complex ones, and pass context into human service.

That increased effective handling capacity in ways a phone-only operation could not.

The chatbot became less of a feature inside Mashreq Neo and more of an operating layer inside customer service.

The visible product was the conversation.

The deeper product was the connection between intent, transaction, and operations.

What I Would Do Differently

I would make time-to-resolution the primary product metric from the beginning.

We measured call reduction and engagement.

Both were useful.

Neither fully captured the user’s actual objective.

The stronger north-star measure would have been:

How many seconds or minutes passed between the customer expressing an intent and the task being completed?

That measure could have been segmented by:

• Intent
• Language
• Automated versus human-assisted resolution
• First-attempt success
• Transaction type
• Escalation reason
• Repeat contact
• Customer segment

I would also have reduced conversational decoration more aggressively.

We invested in:

• Natural recovery language
• Polite phrasing
• Conversational continuity
• More human-feeling responses

Some of that improved trust.

Some of it added time without improving resolution.

The next version would use even more one-tap and structured flows for predictable tasks.

Finally, I would have pushed harder for additional language support, particularly Malayalam.

A meaningful part of the Neo customer base came from South India.

For customers managing money in a second or third language, language support is not cosmetic localization.

It affects:

• Comprehension
• Confidence
• Error risk
• Support dependence
• Trust

The technical platform could support expansion.

The limiting factor was scope and institutional appetite.

I should have made the product and operational case more forcefully.

The lesson is:

A banking conversation is only fast if the customer understands it the first time.

Product Lessons

01  Do not design a customer-service product before experiencing the service operation it must change.

02  The highest-volume intent is not always the highest-risk intent. Automation and escalation need different logic.

03  In transactional systems, bounded flows often outperform open conversation.

04  Conversation is effective for intent. Structured UI is safer for financial precision.

05  A chatbot becomes a channel when it can complete the task, not merely describe where the task lives.

06  Human handoff is a product capability, not an admission of AI failure.

07  Context must survive escalation, or automation simply adds another layer of customer effort.

08  Each banking domain needs its own conversational and risk architecture.

09  Engagement is weaker than resolution as a measure of product value.

10  The most important AI product decision is often defining what the system should refuse to handle.

Closing Note

/* the channel behind the chat */

> The bot handled the predictable.
> The widget handled the precise.
> The agent handled the consequential.

> The product worked because each layer knew its job.

// automation creates value when the customer reaches resolution, not when the machine keeps talking