Simplifying banking self-service at NatWest using Amazon Connect and Amazon Lex

Introduction

As one of the UK’s leading financial institutions, NatWest Group delivers a wide range of banking services across retail, commercial, and private banking sectors. The bank faced a significant challenge in modernising their contact center operations from their existing legacy platform, in managing their Natural Language Call Steering (NLCS) engine, which needed to process and classify over 1,600 distinct customer intents through voice interactions.

This migration to Amazon Connect presented a specific technical challenge around intent management. While Amazon Lex offers powerful natural language understanding capabilities, its optimal performance is achieved with a more focused set of intents. Having too many intents in a single bot can lead to intent overlap, potentially reducing classification accuracy and impacting the quality of customer interactions. Furthermore, service quotas and architectural best practices suggested a need for a different approach to handle such a large intent catalog effectively.

The stakes were particularly high for NatWest, as incorrect intent classification could result in poor customer experience through misrouted calls, unnecessary internal transfers, and increased handling times. The bank needed a solution that would support the granular customer journey processing while ensuring high accuracy in customer intent recognition and routing. This required rethinking the entire approach to intent management and call steering architecture.

This blog outlines how they achieved this using Amazon Lex bot federation, where multiple bots work together seamlessly to deliver a strategic and customer-centric contact centre experience.

The initial challenge

Intent complexity

Managing over 1600 customer intents surpassed the practical and technical boundaries of a single Amazon Lex bot.
Amazon Lex advises a configuration of 20–50 intents per bot for optimal performance, with a maximum limit of 1000 intents.
A scalable, modular strategy was essential to preserve performance and ensure manageability.

Customer experience impact

Inefficient intent recognition results in extended handling times and increased customer frustration.
Maintaining a monolithic intent model was not only resource-intensive but also prone to errors and performance degradation / scalability.

Solution Overview:

To fulfil the NLCS requirement, NatWest implemented a Amazon Lex Federation Architecture—a modular and simplified framework that enables multiple Amazon Lex bots to collaborate efficiently in handling a vast array of customer intents.

A customer initiates contact by calling a toll-free or DID number, which triggers an Amazon Connect contact flow.
The contact flow invokes a primary Lex bot (referred to as the Gateway) to capture the broader-level intent.
The Gateway bot activates a code hook Lambda function.
The code hook Lambda function utilizes boto3 to interact with AWS Systems Manager.
The code hook Lambda function retrieves the child bot’s ARN from SSM parameters.
The code hook Lambda function returns the ARN and the customer transcript to the Gateway bot, which stores them in the contact flow using set attributes.
A Recognize Text API Lambda function is invoked, utilizing the customer transcript and bot ARN to engage the child bot.
The child bot poses further questions to pinpoint the exact customer intent.

Gateway bot strategy

A unified Gateway bot serves as the initial point of contact for all customer calls. This bot is responsible for recognizing high-level intent categories from the customer’s initial statement, such as “balance” or “payment.” Each identified category is then associated with a specific child bot, which is equipped to manage the detailed resolution of the intent.

Example: When a customer inquires, “What’s my account balance?”, the Gateway bot detects the high-level intent as “balance.” Consequently, it activates the designated Child bot, nlcs-balance-child-bot. This child bot is specialized in handling more granular intents related to balance inquiries, such as check-balance and enquiry-balance.

Technical architecture overview

When a customer calls a toll-free number, the contact flow initiates by invoking the Gateway Lex bot to capture the initial intent. This allows you to quickly understand the customer’s needs and direct them to the appropriate resources.

Behind the scenes, the gateway bot code hook Lambda function plays a crucial role. This Lambda function is tailored to extract the customer’s transcript from the Lex session attributes and then retrieve the child bot ARN from AWS Systems Manager (SSM) or DynamoDB, based on the identified intent. These details are stored as session attributes and passed to the next Lambda function for invocation.

It’s important to note that the child bot ARN should not be fetched using Lex Build APIs at runtime, as these APIs are intended for build-time operations and can be throttled under high load. Instead, store the ARNs in SSM Parameter Store or DynamoDB for reliable and scalable access.

The Recognize Text API Lambda function then utilizes the Recognize Text API to invoke the child bot. This function passes the original customer utterance and bot details to trigger the Child bot, ensuring a seamless transition without requiring the customer to repeat themselves.

The Child bot then continues the conversation to identify the granular intent. For example, the “nlcs-balance-child-bot” may ask follow-up questions to distinguish between “check balance” and “balance enquiry”, ensuring a more personalized and efficient customer experience.

By leveraging the power of Amazon Connect and its contact flow capabilities, you can create a seamless and adaptive customer experience that meets the evolving needs of your callers.

Timeout management for a seamless experience

Lex bots inherently introduce a default delay when awaiting customer input. Given that the Child bot is activated internally—without requiring fresh input from the customer—this delay could result in unnecessary wait times. To circumvent this issue:

The session attribute x-amz-lex:audio:start-timeout-ms is configured to 1 millisecond to effectively bypass the delay.
Upon entering the child bot, the timeout setting is reset to its default, allowing for normal interaction to proceed without interruption.

Retry logic in the gateway bot

In the event that the Gateway bot is unable to identify a specific intent, the subsequent invocation of the child bot will also fail. To address this potential issue:

Incorporate retry logic within the Gateway bot. This mechanism allows the bot to re-prompt the customer or pose clarifying questions.
The objective is to ensure that a valid high-level intent is accurately captured before transitioning to the Child bot, thereby maintaining the integrity and continuity of the customer interaction.

Confirmation prompts strategy

Avoid employing confirmation prompts within the Gateway bot. Instead, utilize confirmation slots within the child bot to validate the granular intent. This approach ensures that:

The intent is accurately confirmed only after the detailed context has been fully established.
This method enhances the precision of intent validation, ensuring that the customer’s request is understood and addressed correctly within the specific domain of the Child bot.

Reporting and analytics considerations

Given that the Gateway and child bots operate as distinct entities, it is imperative that reporting mechanisms integrate data from both bots. To achieve this:

Utilize session IDs and shared attributes to correlate interactions across the Gateway and Child bots.
This approach facilitates a holistic view of the customer journey, enabling robust analytics, quality assurance, and continuous improvement initiatives. By synthesizing data from both bots, organizations can gain deeper insights into customer interactions, identify areas for enhancement, and ensure a seamless and optimized customer experience.

Onboarding new child bots

To integrate a new Child bot into the federated architecture, follow these steps:

Step 1: Create a new Intent in the gateway Bot:

Establish a new intent within the Gateway bot that represents the high-level category for the child bot.

Step 2: Create the child bot:

Develop the Child bot using a strategic naming convention: nlcs-<gatewaybotintent>-child-bot

Example: For an intent related to “balance,” the bot name would be nlcs-balance-child-bot.

Step 3: Map utterances:

Add relevant utterances to the Gateway bot intent that corresponds to the domain of the child bot.

Step 4: Store the child bot’s ARN:

Create SSM parameters (or DynamoDB entries) to store the Child bot’s ARN, adhering to a consistent naming pattern: /customer/lex/nlcs-balance-child-bot/bot-alias-arn

This structured approach ensures that new child bots are seamlessly integrated into the existing architecture, maintaining consistency and scalability across the system.

Key benefits

Enhanced customer experience

Customers benefit from guided and intuitive interactions without the need to repeat themselves.
Faster and more accurate intent recognition leads to improved resolution rates.
Overall satisfaction is heightened, with customers experiencing reduced effort and frustration.

Operational efficiency

Bot management becomes more modular and easier to maintain.
The architecture is inherently scalable, accommodating future growth and the addition of new intents.
The decoupled bot design reduces maintenance complexity, making updates and enhancements more straightforward.

Results and impact

Modular interaction journeys can be seamlessly reused across various services and channels.
Continuous application of analytics-driven improvements allows for ongoing refinement of bot performance, ensuring that the system remains effective and responsive to customer needs.
With this modular and simplified architecture, we have performed rapid tuning cycles—enabling continuous improvements through focused testing on individual child bots. This approach has allowed us to deliver over 100+ changes without the overhead of monolithic, big-bang testing, thereby reducing delivery timelines and time-to-market without much disruption. Additionally, the business have also picked up Lex optimizations as federated changes, further enhancing agility and scalability across the bot ecosystem.

Conclusion

The successful implementation of Amazon Lex at NatWest demonstrates a powerful approach to building sophisticated conversational AI solutions. By architecting a system that combines gateway and child bots with strategic naming conventions, robust retry mechanisms, and scalable storage solutions, NatWest has created a natural language conversation that effectively manages thousands of intents while maintaining optimal performance. The modular design not only simplifies maintenance but also ensures seamless customer interactions through precise intent capture and validation. With comprehensive reporting capabilities and customer-centric features, this federated architecture serves as a blueprint for organizations looking to deploy large-scale conversational AI solutions that are both resilient and user-friendly. The integration of AWS services like SSM Parameter Store and DynamoDB further reinforces the reliability and scalability, making it a sustainable solution for future growth and adaptation.

Get practical experience with Amazon Connect through hands-on workshops designed to build self-service journeys. Learn essential skills and earn official badges as you progress through communications specialist and developer learning plans.

Authors bio

	Kousik Suresh is a Principal Engineer at NatWest, specialised in Amazon Connect solutions. He designs secure, scalable platforms focused on enhancing customer experience, driving innovation, and delivering automation through cutting-edge AI-powered services.
	Alex Buckhurst is a Senior Amazon Connect consultant at Amazon Web Services with a focus on innovation and building customer-centric designs. In his downtime, Alex enjoys playing squash, perfecting his BBQ skills, and cherishing moments with his family.
	Prabhakar Rajasekar is a Specialist Customer Experience (CXE) Solution Architect at Amazon Web Services for WWSO in Aachen, Germany. Besides helping customers in their digital transformation, you will see him spending time with his kids in the garden or in the woods.
	Krishanu Bhar is a Director and Lead Enterprise Architect for the Remote Contact Platform at NatWest Group. He drives the modernization of bank’s contact center ecosystem through cloud-first and AI-powered transformation, leveraging AWS to build resilient, scalable, and future ready platforms.
	Anurag Wasnik is a Data Engineer at Natwest, working within the Data and MI team. He specializes in designing and building scalable data pipelines and developing insightful dashboards using AWS Cloud.
	Aditya Verma is a Senior Software Engineer at Natwest. He specializes in designing transformative contact center solutions using Amazon Connect and AWS, while leading initiatives in generative AI and agentic AI to modernize banking services.
	Anand Jumnani is a DevOps Consultant at Amazon Web Services based in United Kingdom.

AWS Contact Center