Skip to content
  • About Us
  • Our Services
  • Case Studies
  • Content Hub
  • Blog
  • Join Us
  • Contact Us
customer journey
Himanshu Swaroop

How to Use AWS Well-Architected Framework to Unlock Outstanding Customer Journeys

In today’s fast-changing market, financial services (FS) organisations are focusing more than ever on building better customer journeys to delight and retain their customers. For example, in insurance, this implies faster claims settlements, and easy to understand and personalised journeys based on their circumstances.

However, these organisations are often faced with legacy, monolithic platforms that are not adaptable to new features customers value most. This makes building modern digital customer journeys a huge challenge.

Re-architecting based on the above customer and business needs requires clear design principles that address specific scenarios e.g. pre-population of customer forms, customer uploading documents and returning customer outcomes based on analytical engines.

To gain a true advantage also requires organisations to tap into the power of the cloud to build modern, scalable, and reliable applications.

In this blog we will:

  • elaborate on the challenge of building architectures for new or improving existing broken customer journeys in the FS industry
  • introduce design principles to facilitate good design in the cloud for customer journey workloads
  • introduce common scenarios that influence the design and architecture of customer journey workloads on AWS
  • ensure that this aligns with best practices identified in the pillars of the AWS well-architected framework - operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability.

What Is a Digital Customer Journey?

We think of a “customer journey” as any interaction the customer has with an organisation—whether that’s a retail bank, wealth manager, or insurer.

In the FS industry, some common interactions include:

  • opening a bank account
  • making a bank transfer or paying utility bill
  • requesting a new card
  • making an insurance claim for car or home damages or personal injury
  • cashing out a personal investment made on an online wealth platform, etc.

Customer Journey Vs Customer Experience

While the “customer journey” refers to a time bound series of customer interactions to accomplish a goal, “customer experience” (CX) can be defined as the holistic nature of a customer’s relationship with a brand or service; it describes the summation of the experience between an organisation and its customer.

Salesforce and Forrester define a good CX as below, although these are key ingredients for an outstanding journey as well:

  • Useful: They deliver value e.g. give customer speed and control in completing a transaction
  • Usable: They make it easy to find and engage with the value e.g simple to understand
  • Enjoyable: They are emotionally engaging so that people want to use them

In addition to above we would add the below to how we would describe a good CX:

  • Consistent across channels for the customer
  • Viable for Business i.e. sustainably generates a business benefit; and responsible (i.e. ethical, inclusive and sustainable)

Why Transform Your Customer Journey?

Soaring customer expectations are placing high value on customer journey transformations, especially for those FS organisations with a high number of customer interactions. Also increased accountability of transformation owners means a greater focus on specific interactions and the value they bring to the customer and company.

According to the State of Connected Customer Report by Salesforce:

  • 76% of customers expect consistent interactions across departments. However, 54% say it generally feels like sales, service, and marketing don’t share information
  • Online interactions grew from 42% of customer engagements in 2019 to 60% in 2020
  • 88% of customers expect companies to accelerate digital initiatives due to recent disruptions

However, FS organisations are still playing catch up. When it comes to pleasing customers, banks trail behind top digital services providers (by at least 10%) across: ease of use of products and services, transparency on terms and fees, more value for same products and services, knowing the customer better, and the “wow me” factor with quality of products and services (source: HBR).

These challenges are being recognised across the industry and investments on customer journey and customer experiences are ramping up. 71% of FS respondents to the HBR survey are building CX / Customer Journey muscle by investing in digital tools, and 50% are offering or upgrading their digital transaction services (according to HBR)

6 Common Architecture Challenges in Transforming Customer Journeys

So what technology capabilities support outstanding customer journeys?

According to HBR “A winning customer journey / CX depends on a technology stack that can “aggregate and process customer data and share it across the organisation when and where it’s needed.

At Contino, we would add to this the ability to integrate with different capabilities e.g. fraud, payment, etc. that provides seamless experiences e.g for on-boarding, claims and payments.

However, FS organisations are faced with some common challenges that get in the way of delivering on the above capabilities.

  1. Customer data is not seamless from data source to front end journey, due to lack of standard API interfaces, and data being stored in different systems e.g account and transaction data
  2. Monolithic architecture with lower availability % for customer journeys; also leading to higher dependencies on various systems to change code
  3. Legacy processes - Infrequent releases, manual deployments, lack of zero downtime deployments, and security standards not considered while deploying code - all lead to slow pace of change and ability to react to new customer demand
  4. Traditional ways of thinking: cloud platform and application development is constantly evolving and decisions made in the past may no longer be sound
  5. Slow and clunky third party integrations: some customer journeys are reliant on various ecosystem partners e.g. to provide payment, fraud management services, insurance repair / replacement, which may lack a standardised API, or documentation, or otherwise not provide easy integration.
  6. Voice of the customer lives outside of technology organisations driving transformation programme
boat

How to Safely Navigate the Observability River: Your Complete Guide to Monitoring & Observability

Everyone is looking for new ways to improve their platforms and applications, but where do you start?

We’ve got to look at the picture as a whole…

It’s time to take a trip down the Observability River.

GET THE EBOOK

How to Leverage Cloud Technologies to Unlock Outstanding Customer Journeys

To resolve these common architectural challenges, organisations can look to cloud technologies. Cloud services provide the automation, re-usability, flexibility, security and scalability in the technology stack that enables FS organisations to deliver the key capabilities and focus on customer value.

General Design Principles

From our extensive experience working with some of the biggest organisations in the FS industry, Contino has identified five design principles that can be applied to design to build great customer journeys.

1. Automated infrastructure and application deployment

  • CI/CD pipelines should be standardised and as such follow a similar pattern,
  • These should be designed/built with reuse in mind—for example by taking specific attributes / configuration as input parameters, rather than hard-coding them.

2. Security by design

Standards, such as security testing, should be codified and run as part of the CI/CD process to enable their reuse and create a baseline that can be verified, across the organisation. Authentication and authorisation is provided by a central ability to determine customer identity and access.

3. Re-usability across customer journeys

Adhere to good re-usability practices e.g. CloudFormation modules, applications and services packaged into a library and stored in a central repository.

4. Scale platform services that could be offered to customer journey solution teams

Explore which part of the customer value delivery could be delivered to product teams as an automated service by a platform team across different architectures for customer journeys.

5. Align on customer value proposition

Align on the customer value proposition and needs with the product owner before designing a technology stack for a feature.

Sample Features of Outstanding Customer Journeys

Customer journeys have some typical features that deliver the capabilities we talked about earlier. These features and their supporting architecture patterns are explained below:

  • how experience is delivered to the customer using a AWS front end service that delivers content to users and AWS integration services that scales based on user traffic and triggers other features
  • how data is delivered to simplify customer experience as a two-way exchange - by fetching relevant customer data with the help of AWS integration services and database endpoints
  • how the journey enables uploading documents, payments - with the help of AWS integration services that connect with third party APIs and database endpoints
  • how the journey is personalised based on customer situation - with the help of AWS data provisioning, data preparation and data science ML Ops services

Designing Customer Journey Features on AWS

For each of the above features we elaborate on the architecture characteristics and a reference architecture based on our experience of AWS services that would also meet AWS well-architected pillars (we elaborate on this alignment in the next section).

Front End and Integration Services Application Architecture

Front end and integration architectures supporting customer journey workloads share the following characteristics:

  • They are long-running processes and need high availability
  • They require minimal overhead and simpler management
  • They are high load services during the busy periods in the week e.g. Fridays and Mondays
Reference architecture
Reference architecture

Reference Architecture notes:

  • S3 for the front-end component of the application
  • ECS-Fargate for hosting and managing the backend-for-frontend component
  • CloudFront as a managed CDN
  • Application Load Balancer to support high availability
  • WAF to conform to security best practices
  • ECS-Fargate for hosting and managing the containerised services
  • Application Load Balancer to support high availability.

Fetching Relevant Customer Data

Architectures supporting customer journeys in these scenarios share the following characteristics:

  • Require that they are simple for customer to understand and provide information
  • They can fetch relevant customer data from existing data sources
  • They can run simple checks based on customer status and incident before moving forward
  • They automate logging of events e.g. failure to trigger Fargate service, no response from data store and end point, failure to load static form from S3 bucket to ensure high availability and performance
Reference architecture

Uploading Documents & Third Party Communications

Architectures supporting customer journeys in these scenarios share the following characteristics:

  • Require that they are simple for customer to upload documents e.g. pictures
  • Create metadata based on documents to run fraud checks
  • Provide high availability and interact with 3rd party APIs as well as update data for the original record
  • They automate event logging to ensure high availability and performance
Reference architecture

Journey Personalisation

Architectures supporting customer journeys in these scenarios share the following characteristics:

  • Scalable processes and tools supporting an event driven architecture
  • Data Governance is routine and an enabler to personalise journeys
  • Processes outcomes, including data quality, are more predictable

Reference architecture

For more information on data driven use cases refer to our e-book The Data Driven Transformation of Insurance​.

What Is the AWS Well-Architected Framework and How Can It Help?

The AWS Well-Architected Framework helps cloud architects build secure, high-performing, resilient, and efficient infrastructure for a variety of applications and workloads. In the following section we will show you how to apply this framework to the customer journey workload for FS interactions.

The Well-Architected Framework is built around six pillars—operational excellence, security, reliability, performance efficiency, cost optimisation, and sustainability—and provides a consistent approach for customers and partners to evaluate architectures and implement scalable designs.

Aligning Customer Journey Architecture Patterns with the 6 Pillars of the Well-Architected Framework

1. Operational Excellence

The operational excellence pillar covers the ability to perform automated operations (application, infrastructure, change and approvals) on the customer journey workloads. It also covers the ability to continuously improve the operations of customer journeys e.g. small / reversible changes to features and learn from customer experience failures.

Operational Excellence in FS customer journeys can be achieved using the following guidelines and principles:

Automated and short-lived test infrastructure with automated deployments:

  • Feature Environments: a set of infrastructure and deployments for each feature in progress. New features in customer journeys should be able to be tested quickly and easily, and in an automated fashion. This allows features to be released quickly, and so value can be delivered to customers faster. These automated environments can also be re-used by products and services for a customer within allowed regulations e.g. loans, bank accounts, retail insurance
  • Artefact Management: Artefact store to deploy consistent artefacts. Once an artefact, such as a deployment package has been tested, that same artefact should be deployed into production.  This helps reduce defects and provides a better experience to customers using the journey.

Automation in infrastructure change approval process:

Changes to infrastructure should be made using automation. Automate the approval process to make changes and embed it within the customer journey product team to allow for autonomy and remove barriers.

Everything-as-code:

Infrastructure, security, compliance all defined as code. Automation and codification allows for automated quality checks. This helps to ensure that new features can be delivered quickly, and in an automated fashion, all whilst adhering to an organisation’s quality, security, and compliance standards.

This is also an opportunity to provide consistency in quality, security, and compliance standards across different product squads e.g. loans, bank accounts, retail insurance and will improve developer experience as well as time to market

Architecture that enables frequent, small, reversible changes:

Standalone services that decouple frontend applications, integration services and data and transaction backends will allow components to be updated regularly and increase the flow of beneficial changes into different customer journey workloads. 

When problems do arise it is important that they can be rolled back quickly to minimise the impact on the customer experience.

Learn from all operational failures:

Customer journey workloads can have a number of potential failure points, for example:

  • any time there is unavailability of online forms
  • failure to auto-save forms during different stages of customer journey
  • failure to retrieve customer data
  • failure to upload documents after multiple attempts
  • failure to notify customer on key events and change in status
  • failure to pay customer within agreed timelines

Improvements should be driven through lessons learned from all operational events and failures. Lessons should be shared  across teams and through the entire organisation.

Design and build for observability:

Logs, metrics, tracing, alerts, and notifications are all important tools in the arsenal of architects looking to build for operational excellence. They are vital when building customer journeys in order to deliver and maintain a great user experience

All of these tools help to identify defects, or pain points, as well as how customers interact with various components along the journey, and therefore give valuable insights into how the journey could be improved from their point of view.

2. Security

The security pillar focuses on protecting customer information and access to systems. Key topics include integrity of data, managing user permissions for infrastructure and applications. Security pillar alignment in FS customer journeys can be achieved using the following guidelines and principles:

Cloud Landing Zone, Security and Compliance Rigour:

Provides a set of standard building blocks (services, processes etc.) that allows you to automate  account, infrastructure and environment creation and ensure that they are created in line with security policies, compliance guidelines and cloud-native best practices.

AWS Web Application Firewall:

This can be easily configured to mitigate common security threats and vulnerabilities and should be used to protect the entry points of customer journey services, such as APIs and CDNs

Protect Customer Data:

Given that most customer journeys involve capturing and using personal, and, potentially, sensitive data, a good customer journey in this context involves making sure the confidentiality and integrity of that data is not breached.

This means having good data classification policies, and applying a defence in depth approach to security controls, as well as making sure that the data is encrypted using a strong encryption algorithm at the point of storage, and also when being transferred. This can be applied separately to each business unit in FS depending on regulatory requirements

3. Reliability

The reliability pillar focuses on ensuring that customer journeys are highly available and are performing their intended functions. It also covers how to recover quickly from failure to meet demand, and adapt to increasing customer demand so that resource capacity isn’t exhausted. Reliability in FS customer journeys can be improved using the following guidelines and principles:

Continuous Evaluation of Failure Scenarios using continuous integration:

This improves reliability with an up-to-date and real time view of quality. Start evaluation early in the development process. This helps in technical debt reduction with quality issues detected before they are built upon.

Share ownership of testing and quality to improve efficiency by removing silos, testing is implemented at the point of development.

Automatically recover from failure:

Keeping track of reliability and quality metrics over time; mean time to recovery (MTTR), and change failure rate (CFR) to improve visibility of level of quality observable by the entire team, if these KPIs exceed an acceptable level, it should automatically trigger a rollback to the last known ‘good’ state.

Scale horizontally to increase aggregate workload availability:

With the use of ECS-fargate for containerisation services horizontal scaling principles are used to distribute requests across multiple, smaller resources to ensure that they don’t share a common point of failure. This also helps to cater for almost any level of demand, and so customers will experience faster loading times, and less errors.

4. Performance efficiency

The performance efficiency pillar focuses on structured and streamlined allocation of IT and computing resources for customer journey workloads e.g. cloud vendor manages complex tasks e.g. servers and compute resources while the financial services organisation focuses on product development for the customer.

Some examples of ensuring efficiency are listed below. Performance efficiency in FS customer journeys can be improved using the following guidelines and principles:

Architecture Re-usability:

This is the generic architecture suggested for all domain / integration services, meaning that infrastructure code can be reused across customer journey products services provided by the financial services organisation e.g. for insurance claims, banking payments, etc. To achieve this architectures can be defined as code, and made available for consumption in the form of modules.

CloudFront:

This delivers content closer to users with low latency and high data speed improving user experience without the IT function worrying about scaling services during the high traffic customer volume periods. Customer journey users will experience this in the form of faster loading times, and a smooth journey.

Use of serverless architectures:

Serverless architectures remove the need for you to run and maintain physical servers for traditional compute activities.

For customer journeys, serverless storage services can act as static websites (removing the need for web servers) and event services can host code, compute can be provided in a serverless manner using Fargate or Lambda, and data stores, such as DynamoDB and Aurora Serverless, can also be used to provide database services for customer journey applications

5. Cost optimisation

The cost optimisation pillar focuses on avoiding unnecessary costs by measuring efficiency of delivering change for customer journeys, paying for resources that are consumed during high traffic periods and by analysing each customer journey workload behaviour. Cost optimisation in FS customer journeys can be achieved using the following guidelines and principles:

Measure overall efficiency:

Dashboard view of cost optimisation metrics over time across deployment frequency (DF), lead time for change (LT) will help to identify the gains that can be made from increasing output

Adopt a consumption model:

Based on ECS-Fargate and containerisation services, the customer journey workloads are set up to pay only for the computing resources you consume. This is especially important as the customer traffic can vary daily depending on time of the week

Analyse the workload:

Given each customer journey is unique and traffic can vary over time the team should monitor the requirements of the workload. The organisational requirements should indicate the workload response times for requests. The response time can be used to determine if the demand is managed, or if the supply of resources will change to meet the demand

Establish a common cost optimisation function for customer journey products:

It requires a multi-disciplined approach, with capabilities in project management, data science, financial analysis, and software/infrastructure development. This function also requires a secure executive sponsor, who is regarded as a champion for cost efficient cloud consumption.

For customer journey workloads the cost optimisation priorities set by organisation and sponsor should depend on customer value and organisation’s role in creating that value. Together, the sponsor and function ensure that your organisation consumes the cloud efficiently and continues to deliver business value.

6. Sustainability

The sustainability pillar focuses on minimising the environmental impacts of running customer journey workloads especially due to their cyclical and unpredictable usage. This will help in maximising utilisation to minimise required resources and reduce downstream impacts.

Sustainability alignment in FS customer journeys can be achieved using the following guidelines and principles:

Understand the impact:

Measure the impact of customer journey cloud workload and model the future impact of your workload on resources e.g. S3, ECS-Fargate. Due to the cyclical nature of customer demand and increasing product types included in the overall customer journey this will be expected to increase.

Compare the productive output with the total impact of all cloud workloads by reviewing the resources and emissions required per unit of work.

Establish sustainability goals:

For each cloud workload, establish long-term sustainability goals such as reducing the compute and storage resources required per customer transaction. Model the return on investment of sustainability improvements for existing workloads, and give owners the resources they need to invest in sustainability goals.

Maximise utilisation:

The patterns in the scenarios are designed to ensure high utilisation and maximise the energy efficiency of the underlying hardware - S3, ECS-Fargate, WAF. The aim is to also eliminate or minimise idle resources, processing, and storage to reduce the total energy required to power the workload.

Minimise Usage:

Define and implement a data lifecycle that will remove data that is no longer needed. This will reduce the usage of data store services, such as S3, and also help to reduce the impact of any data breach.

In Summary

In this blog we highlighted how financial services customer journey architectures are not optimal e.g. due to lack of seamless customer data flow across the journey architecture, monolithic architectures and inefficient integrations with all parties in the ecosystem.

To start addressing these challenges some simple starting points that can be actioned immediately are:

  • Explore automation of infrastructure and application deployment for your customer journey
  • Explore with your engineers how security is included by design in deployment processes
  • Provide the central ability to determine customer identity and access for all customer journeys
  • Identify sample features that are urgently needed for outstanding customer journeys and design the AWS pattern based on above
  • Prove that these patterns are valuable based on customer feedback
  • Finally, validate which services can be scaled as platform services for all customer journey solution teams to consume in an automated way

More Articles

AWS Summit London 2022

AWS Summit London 2022: 10 Sessions We Are Hyped For

13 April 2022 by Rosh Plaha
API Testing

Testing Strategy for APIs: The Ultimate Guide For A Higher Quality API

7 April 2022 by Mohamed Fahmy
Security

Zero Trust: What It Is and Why It Matters

30 March 2022 by Contino
  • Londonlondon@contino.io