Skip to Main Content

Generative AI: Using artificial intelligence to make human impact.Learn how

How to Meet Customer Expectations With Engagement Platforms: Microservices Succeed Where Journeys Fail

Abhishek Bhattacharya
Abhishek Bhattacharya
Matt Hopgood
Matt Hopgood

Traditionally, we have thought of an engagement platform as the mechanism that powers a website or mobile app experience – through which customers can engage with the bank and its services. This definition is too narrow.

Not only does this conception of an engagement platform exclude physical channels, such as call centers and bank branches, it fails to empower banks with everything they need to meet the increasing customer-experience expectations of millennial consumers and the generations that follow.

Banks can succeed at delivering first-rate, personalized customer experiences with engagement platforms that leverage microservices and composable architectures – enabling the discrete modification of capabilities while freely sharing data. But first they need to understand that engagement platforms involve far more aspects of the bank than just the customer journey.

 

The problem with traditional customer journeys

Legacy banks have built engagement platforms based on the idea of customer journeys. This involves identifying a few broad customer archetypes that are expected to behave in certain ways, depending on their needs and goals, and building a digital platform to facilitate pre-determined journeys. But digital-savvy customers will not accept being corralled into a limited number of use cases. They expect personalized experiences, products and services.

And banks face internal issues that complicate responding to these evolving expectations: huge technical debt, legacy systems, crippling data infrastructure, a weak culture of innovation and ingrained ways of working that prevent them from adopting agile methods.

 

What about the people on the other side of the desk?

The conventional vision of an engagement platform also excludes an essential group of users: the bank’s staff.

Banks typically treat their customers and employees as two distinct groups that require separate technology platforms. But employees sit opposite customers in the engagement process: the employee must provide a solution to meet the customer’s need. If that need is communicated via an engagement platform, the reality is that the employee is also a user of that platform. Yet it was built with scant consideration of the employee’s needs. It is not unusual for an employee to log into five to ten systems to answer customer requests. Everyday challenges – such as viewing all the customer’s data in one place or easily retracing a customer’s steps – are extremely difficult to solve for legacy banks.

These conventional barriers to engagement have become even more obvious given the restrictions and behavior changes caused by Covid. Many customers, particularly in older age groups, have been avoiding bank branches, which has overloaded contact centers. If employees must access multiple back- and front-office software applications to address a single customer request, productivity is likely to suffer and the developing workload and stress1 can affect their mental well-being.2

Modern engagement platforms consider both employees and customers as users. This helps to provide an end-to-end view of each customer’s relationship with the bank and allows employees in branches and contact centers to operate as a single, seamless entity. A system that achieves this is also a system that will support the productivity and well-being of employees.

Systems architecture as a barrier to engagement

To address their engagement challenges, banks must put in place key technical and data capabilities. But they often fall into the trap of building a single digital platform that will enable all customers to engage with the bank. Rarely unified or smooth, these platforms usually require support for a set of discrete products and services, each of which involves a tightly confined customer journey towards a fixed goal.

The resulting architecture has at least two serious weaknesses:

  • Customer journeys often cannot be modified – making it even more difficult to personalize journeys.
  • The platform adapted to incorporate innovations in areas such as payments, ID verification and KYC (know your customer) as they appear. For example, entrants including Monzo, Starling and Revolut have enabled account opening from mobiles using documentary proof of identity, a short user video and a photograph. The entire process takes less than a minute versus several days if not more to open an account with a traditional bank, which is hampered by inflexible technology architecture.

These problems highlight the impact of Conway’s Law, which observes that organizations will tend to replicate their current structures in the systems they build. Banks that are organized around static products and services will naturally implement systems that adhere to the shape of those products and its current processes.

Systems architecture as an enabler of engagement

Now consider the emerging future of financial services. As we have already noted, younger, digital-native customers expect personalized digital experiences. As technology evolves, it will become possible to deliver “hyper-personalized” experiences, in which every customer has their own journey, and ultimately hyper-personalized products that are different for each customer. The era of static banking products will be over. The current model of building a platform with a particular set of needs in mind will become obsolete.

Instead, the architecture for engagement platforms must assume that everyone’s needs will be different and will change. A single digital platform is therefore much less relevant than thinking in terms of a set of connected capabilities that the bank will use to meet its customers’ differing needs – product manufacturing and understanding customers using data being two key examples. A modern architecture allows the bank to expose and combine those capabilities to create coherent experiences for both customers and employees.

This, naturally, brings us back to Conway’s Law. An approach based on capabilities works in theory, but unless the organization first identifies and organizes itself around its key capabilities, rather than its existing products or processes, it will not be able to build systems based on those capabilities. Building the kind of engagement platform that will meet the evolving needs of the bank’s customers necessarily involves a willingness to rethink the way the bank is organized and structured.

 

Organizing capabilities

How can the organization’s capabilities be translated into an architecture? The solution will almost always come in the form of discrete but loosely linked microservices. Domain-driven design, which relates the structure and language of the software to the specifics of the domain, and the notion of bounded context are key to thinking about capability-based microservices. But there are still several difficult issues to resolve, such as how broad or specialized a microservice should be, how it should be deployed, how access to it should be controlled, how it should be monitored and how its resilience should be guaranteed. Taking an engineering view of microservices is critical in developing a successful engagement architecture.

Over the last few years, almost all traditional banks have tried to improve the quality of experience they deliver to customers, usually by applying the approach outlined above based on pre-defined customer journeys. But they have spent little or no time considering the capabilities that their employees require, such as the ability to co-browse or chat seamlessly over multiple channels. Being able to engage with the same customer smoothly between WhatsApp, SMS and email while keeping all relevant information in view brings big benefits, not just to the customer but to colleagues as well. Imagine using AI to gather and distil the collective knowledge and experience of all colleagues, and so help each of them deliver better solutions to the next customer or allow them to make a quick decision on a discount. Capabilities such as these can be extremely empowering for colleagues and so help to improve their wellbeing and effectiveness.

 

Solving the data problem

Microservices and capability-based architecture are a huge step forward, but like all architectural choices they introduce complexity in the context of data, leading especially to its fragmentation and compartmentalization. Banks must strike a balance between keeping the organization's capabilities separate and therefore able to evolve independently, while also allowing data to flow freely between them.

Data is fundamental and must sit at the center of the architecture because it allows the organization to understand the customer and create personalized products and journeys. Data must be able to come together and connect with the separate capabilities, but without requiring them to reconfigure – that must be able to happen independently of the data.

Linking data across silos and adding structure – a layer of semantics and ontology – makes the data far more useful for banks. Consider a bank that wants to offer habitual gamblers the option to lock card payments when a specified spending threshold is reached. To achieve this, the bank needs the ability to analyze data in real time and link several data sources such as the category of vendor where the card is being used, the customer’s transaction history and the rules the customer has set for their card use.

Over the years, we have successfully used domain-driven design to decompose business logic, but the same principles have not been applied at the level of data. Concerns about fragmenting the data has caused us to build monoliths, initially data warehouses and more recently data lakes. These are a substantial improvement over data warehouses because they allow multiple schema and ways to interact with the data. But real gains will be realized only with Data Mesh architecture, in which data is federated but also linked by a system of semantics and ontology.3

Traditionally, data models have proved one of the most difficult aspects of the enterprise to change. As a result, APIs built on top of static data models have tended to be static as well. However, if we build a semantic layer between the data store and the microservices, this frees the APIs and allows them to evolve irrespective of the data model. They can now move independently at their own rate.

 

"We believe hexagonal architecture offers a way to accommodate both the independence of the capabilities and the interconnectedness of the data."
Abhishek Bhattacharya
Abhishek Bhattacharya, VP Technology

Will this take forever to build?

The key architectural paradigms that we have set out may well appear daunting. One could be forgiven for asking, “Will this take forever to build?” The answer is that it does not have to: modern engineering techniques, cloud computing and composable architecture are important elements of the solution.

Cloud enables greater development speeds. Engineering techniques like DevSecOps, infrastructure as code and container-based development can significantly accelerate the delivery of large systems as well as ensuring easier maintenance and evolution of platforms.

Finally, established banks should not consider building everything from scratch. New fintechs and start-ups provide many of the capabilities they require. Leverage them. Write less code. Assemble discrete capabilities using an event-driven composable architecture. Focus on the capabilities that differentiate your proposition. Rent or buy the others. Own the customer experience.

 

Conclusion

Banks need to rethink the way they conceive of engagement platforms and therefore the way they are designed and built. They should create modern engagement platforms with these guiding principles:

 

  • START from the bank and the way it is organized, rather than starting from your idea of the platform you want to build and the tightly defined customer journeys it is intended to enable.
  • CONSIDER both customers and employees as users of the same engagement platform.
  • ORGANIZE around the bank’s capabilities. In terms of systems architecture, these are represented by separate microservices that can connect with each other.
  • CREATE an architecture that can accommodate separate, independent capabilities and enable data to flow freely between them, using a layer of semantics and ontology on top of the data.
  • DESIGN AND BUILD with hyper-personalization of customer experiences and products in mind.

1. https://www.forbes.com/sites/adigaskell/2020/10/27/the-impact-of-covid-related-stress-on-employee-engagement/?sh=36132790711b

2. https://www.euromoney.com/article/b1l3dgsskdx1w7/employee-mental-health-on-bank-agenda

3. https://martinfowler.com/articles/data-monolith-to-mesh.html

Abhishek Bhattacharya
Abhishek Bhattacharya
GVP Technology
Matt Hopgood
Matt Hopgood
Global Vice President, Strategy and Consulting

Related Articles

See all Financial Services Articles
Back to top