The single view of a customer

Some of the best technology professionals I have worked with over my career have been in banks.

Having a single view of customer data can help banks streamline processes

So, it’s not because of poor architects that all banks have system silos and disparate islands of data. As I’ve written about previously, banks have evolved over time, adding new products, channels, customer segments, delivery channels and brands. As such, no one questioned when a new system was created for mortgages or a separate system was developed for the call centre.

In my previous column piece, I covered how I first started to understand the power of data beyond its primary purpose. The bank I was working at was using data to understand customer behaviour and went on to develop a brand-new customer management system that was separate from any product line. Prior to this, some customer data was being held in each product core, so that if a customer changed address, multiple systems had to be updated. It surprises me that there are still banks today that have this issue.

It was only a few years later, during a process re-engineering project I was involved in around 1994, that I saw a retail bank working across six core processes, and again we were working in silos. At this point, we already had over 30 individual Windows apps for individual processes, products and customer management. It was the same desktop for everybody, whether you were a cashier or loans manager. This meant you had to constantly search for and find the apps needed for any particular task. This challenge would only worsen as the bank had plans for another 30 apps.

It was with this backdrop that I created a prototype of a new desktop for branches. One that used your login to dynamically create a dashboard for you based on your job role and skills. It had an in-tray so that work was prioritised for you and as such work from another branch could be delegated to you by a regional manager. Clicking on work items took you to the appropriate app/screen.

For example, clicking on a ‘change of address’ work item for a salesperson would display a lead screen to follow up on the opportunity to sell a mortgage or insurance. However, if you had an admin role, clicking on the work item would show you the change address screen to complete. Recognising that it was difficult to find certain data about customers, I added a natural language search for data (for example, to find someone’s salary or their national insurance number). Within the dashboard, there were customer indicators like their propensity to buy products or to leave the bank. There was a customer events window for both historic and future events/transactions as well as a summary of product holdings and another for customer documentation (letters or application forms, for example).

What I was really demonstrating was the use of data to navigate branch systems. I wanted to make it easier to find applications to get a task done and simplify our desktop so that staff could focus on the tasks at hand rather than learning what each app did and how to navigate through every app. While this was ground-breaking in 1994, it is certainly not that now, although there are still things in the prototype that I believe core vendors and banks have not yet addressed.

However, the real vision behind this was that although the bank had created siloed systems with its own data, there was no reason why every app had to be a silo too. Apps could indeed aggregate data from multiple systems to make tasks easier and for staff to get a better understanding of the bank’s customers. This vision was driven by the simple perspective that when customers walk into a branch, they do not see a mortgage desk, a loans arrears clerk or a change of address counter. They walk into a place that is the single entity responsible for all the customer’s banking needs.

At the time, the average number of products per customer was less than two. Levels of interaction with the bank were relatively low, so creating such a solution for real may not have been a priority, as almost two decades later only some of the capability I demonstrated was actually developed.

Separating the data from functionality is something I’ll cover next time, as the bank was ahead of its time with APIs.

Although it’s been some time since I worked within a bank, I have been involved in creating solutions for banks all my career, albeit mostly as a vendor. Most systems I see still focus on a specific business requirement. I often liked to ask, “How does this fit into the big picture?”, and rarely would I get a response that captured the bank’s vision.

This week, I’m just saying that although we may be tasked with automating or digitising banks, there has to be a grander vision that gives a greater purpose to what you are building. It must be clear how your project and all the others combine to make the vision a reality.

About the author

Dharmesh Mistry has been in banking for more than 30 years both in senior positions at Tier 1 banks and as a serial entrepreneur. He has been at the forefront of banking technology and innovation, from the very first internet and mobile banking apps to artificial intelligence (AI) and virtual reality (VR).

He has been on both sides of the fence and he’s not afraid to share his opinions.

He founded proptech start-up AskHomey (sold to a private investor in spring 2023) and is an investor and mentor in proptech and fintech. He also co-hosts the Demystify Podcast.

Follow Dharmesh on Twitter @dharmeshmistry and LinkedIn.

Read all his “I’m just saying” musings here.