Consumer Duty: getting to the Root of Root Cause

?

In this article I am focusing on the Financial Conduct Authority’s Consumer Duty requirement for businesses to examine Root Cause for issues driving poor outcomes for consumers. This is part of the legal requirement now to monitor outcomes to ensure that consumers are being treated fairly and are experiencing good outcomes.

If you work for a financial services business, your employer will be required to report on customer outcomes at board level for the first time from 31 July 2024.

In the finalised guidance of the FCA’s requirements they specify that you need to identify root cause for customer issues and address them, ?for example at 10.12:

This assessment should include: the results of the monitoring that the firm has undertaken to assess whether products and services are delivering expected outcomes in line with the Duty, any evidence of poor outcomes, including whether any group of customers is receiving worse outcomes compared to another group, and an evaluation of the impact and the root cause

And at 11.33 one of the 15 data points to be included in the new annual report on customer outcomes:

Complaints root cause analysis: investigating complaints fully to understand the cause of customer complaints, not just dealing with the symptoms

Across a number of companies I have experience in setting up systems to identify root cause for customer issues and complaints (eg responsible for reviewing all complaints on HSBC’s international banking platform, HSBCnet, between 2018 and Jan 2023). Here are some lessons I have learned… and which I think you’ll find helpful if you are new to this area (and hey even if you are an old hand like me there could be something for you here!). Here are 8 points to ponder:

1)???? Define success and set targets for your root cause analysis activity

2)???? Don’t just look at complaints

3)???? Build a diverse, cross-functional team to investigate root cause

4)???? Understand that, like product development, investigating root cause is iterative

5)???? Don’t horde what you find. Share it and explain it.

6)???? Validate, validate, validate

7)???? Review continuously and frequently

8)???? Demise!

?

1: Define success and set targets for your root cause analysis activity

You should define success for any activity and this is no exception. Consider this: if you are successful in identifying root cause for system issues your activity could make a huge difference to the business. Bear in mind that a single tricky experience can completely dominate a person’s view of a brand. I would advise that success definition and target setting here is itself a learning, iterative process.? Measure the impact of the fix you came up with for an issue… and then plug that back into your success definitions and measurements. Oh and please don’t just limit it to NPS scores, CES scores. Impacts from this can be big. Dream big!

?

2: Don’t just look at complaints

Complaints are typically the tip of the iceberg of an issue – the point where someone cracks and says “enough”. But if you look at all the factors that lead to a complaint you’ll likely see that it’s a combination of issues that lead to it… Identify ALL of the contributory factors.

I will do a separate article looking at the broader picture of capturing and processing the whole array of data and feedback, but for example, consider the following: You can look at data such as: ?-? Web analytics data… eg where users drop out of a form, flow or process ?-? Data looking at users completing/not completing processes ?- ?Data looking at issues mapped onto users: who is experiencing the problems the demographic data will be critical in terms of understanding the relationship between the product and the user… particularly vulnerable users

And of course you will be reviewing feedback such as when customers:

• call helpdesk
• interact with a member of staff
• interact with a virtual assistant
• respond to a survey
• share/comment on social media
• go to the press/media with a story
• take legal action against the company

You will be looking at trends and identifying where a new issue is happening, or getting worse, or just malingering being an issue and not going away (especially where there have been many efforts to resolve)… ?Don’t be blinkered in just looking at complaints, look at the whole picture of what is driving poor outcomes for consumers.

3: Build a diverse, cross-functional team to investigate root cause

Overall, while high-level data analysis from customer calls/emails can provide useful trend insights about activities/functions driving calls, I would always recommend you set up cross-functional teams to review samples of calls ?- the actual detail on the calls on regular (weekly) basis. You need expert knowledge and experience in each of the following:

-??????? Helpdesk specialist(s) who understand the acronyms on the call logs and the realities of answering calls

-??????? Someone who trains customers (increasingly rare these days but so useful if you have them) because they will know well the areas that customers find difficult to understand /confusing

-??????? Someone technical: who understands how the product is built and where it may have limitations/bugs

-??????? Product owners: they will know the history of issues, will know the product roadmap and may need to start making the case for an uplift if an issue illustrates it. Set up themed sessions if you can’t get all the product owners on all the calls.

-??????? UX/UI specialist who can see the feedback/issues of the delivered solution… and start thinking about the solution…

-??????? Data analyst: the more you look into data the more data analysis you need. I would always have a data analyst on the team

- Someone from the compliance team

Be inclusive with your approach to building your feedback analysis team. Look to build as diverse a team as possible. Diversity in a team is a huge strength when it comes to problem solving and will help you avoid groupthink which can undermine rigorous analysis.

4: Understand that, like product development, investigating root cause is iterative

Armed with your diverse cross-functional team and data on trends, let’s say together you read through the transcripts from a support ticket. They typically go something like: ?

- Customer calls very distressed ?

- Helpdesk agent tries to understand the issue ?

- Helpdesk agent suggests solution ?

- Helpdesk log ends. Customer never calls back.

In all likelihood, you will not be 100% clear on what happened or what the cause of the issue was. But if you have a truly cross-functional team then someone will understand at least some of it.

Be prepared to:

- find out more about the customer and their situation

- dig to find other similar cases

- talk to the helpdesk agent involved or their manager

- ask the “5 whys” ie why it happened.

eg Customer calls in because they cannot log in

Why? : because their hard token device has stopped working

Why? : because its battery has stopped working

Why?: ?because it is 6 years old

Why? : because the user did not see the communications about switching to soft token

Why? : because the user has changed their contact details but not updated them on the system

(I’m personally not that sold on just 5 whys but the approach of using “why” to dig deeper certainly works.) In this case, in a sense the investigation leads to a problem with users not updating details as opposed to a problem with the hard token. Clearly both are involved, but if you did not dig down you likely would have missed part of the solution to the problem.

Note: there are a number of root cause analysis methodologies. I like the "5 whys"... but overall I find most of them rather linear. My advice overall is to keep chipping away at a problem, keep getting more data, doing more analysis and using the diverse brain power of your team.

5: Don’t horde what you find. Share it and explain it

With the FCA requirement of a board-level report I can immediately envisage an issue where lots of time and energy is put into producing a great report for the board… but not necessarily into getting it into the hands of product owners, marketing, support etc.? Everyone involved in the product/service needs to be aware of the issues and how they are being addressed. Essential that product owners can build aspects of their roadmap from this information – including of course using the root cause investigation as very solid ground for the business case and budget for the fix.

And explain it. Sometimes issues can be complicated. If X happens on a Friday and Y is true then… Try to keep the explanation as simple as possible, but keep key details in there if they help senior stakeholders understand what is going wrong/ is not optimal.

?

6: Validate, validate, validate

You have hypothesized the root cause looking at data and feedback. Next, validate with people who know the product AND people who use the product.? Then define what success looks like for this issue and decide on a measurement that would indicate it is fixed. Then, after deploying the fix, measure and hence validate the fix. ?

In my experience, it is really rare that things are cleanly solved. You think the solution will completely fix it. But lo and behold it did not. Why? Because there’s a really edge-case scenario that had not happened… but now it has. Annoying, but actually it’s good news. You’ve now captured that because you measured. Give yourself a pat on the back and go back to the product owner. Don’t look so sheepish: discovering the issue is the first step to fixing it.

7: Review continuously and frequently

Issues don’t fit in nicely with product and budget cycles. Issues are often flagged after a project is delivered/ finished. It can be years later. Someone using a device/operating system that didn’t even exist at the time the product was launched. Intermittent reviews can mean a really long delay between the issue and the analysis and resolution. Continuous review of issues is an essential part of continuous improvement. Obvious really, but see next point.

8: Demise!

Having been round the block a few times… a constant is the lack of a formal product demise strategy. People love creating new things. Great NEW products for new opportunities, growth etc. It’s what we all get excited about. But I would guess that a disproportionate number of issues are related to old products that, well, have really reached end of life.? Often, customers love them and don’t want them demised, but the business needs to decide whether to invest in them properly or manage their demise in a fully customer ?focused way (eg migrating to new, better products etc…. very problem-strewn area, but essential!).

Your reporting on root cause analysis may find a lot of smoking-gun evidence about a product creating more and more problems. Providing that clarity will help the business focus on the value of the product and it’s roadmap.

?

And finally a note on the Post Office scandal

Imagine, for a moment, if the above had been applied to the Post Office/Fujitsu Horizon system and specifically to its internal Riposte messaging system/dbase back in 1999. There are many Computer Weekly articles on this (they were covering it when no one else was) and I think this one sums up the failure to deal with root cause. https://www.computerweekly.com/news/252496560/Fujitsu-bosses-knew-about-Post-Office-Horizon-IT-flaws-says-insider

As I said at the top of the article: really understanding root cause of customer issues is immensely powerful to a business and hugely important to consumers, which is why FCA’s Consumer Duty is 100% right to focus on root cause of poor outcomes.

?

Need support with Consumer Duty compliance?

If you are reading this you may have seen that I recently joined esynergy as Lead Associate. If you feel you may need support on ensuring that:

a)?????Your designed experiences provide good consumer outcomes

b)???? You have the data in place to prove it - especially in the annual report due on 31st July 2024

?

... then feel free to contact me or esynergy to see how we can help with a combination of deep experience in CX transformation, technology and data.

Maya Schulz John Sills David Mendes da Costa