![Why sharing data can ease a customer’s mental state when going through vulnerability identification checks Tim Farmer Comentis](https://barcadiapublications.fra1.cdn.digitaloceanspaces.com/financial-reporter/img/article/tim_farmer_comentis-18735.jpg?v=45fd7fc6363d282af22272d9cf641d17)
"This not only needs joined up thinking, but smart ways of working from a technology point of view to ensure all providers have access to the same platform"
And it’s that customer experience element that I really want to elaborate on today in this follow up article. Because it’s more than just providing a good customer experience. Rather, when it comes to vulnerability data, it’s about ensuring that a customer feels safe and doesn’t have to experience the emotional turmoil of constantly going over their experiences again and again to multiple different providers. As such, it’s my belief that safely sharing customer data around vulnerability can actually ease a customer’s anxiety, reduce their stress, and help to engender trust between customer and adviser longer term.
In his article, which was the first in this series, Richard gave an example of how a lack of data sharing can disrupt customer experience. He explained: “Let’s assume all firms in the distribution chain are using a fit for purpose vulnerability identification and reporting solution, rather than attempting to do it manually through training. The first part of the chain, who may well be a mortgage adviser, asks the customer in their factfinding process to take a “profile survey” on an app that takes approximately 10 minutes. The adviser then sources a lender and submits their application. Under the Consumer Duty the lender is also obliged to identify and report on any vulnerabilities found to ensure that a good outcome is achieved. This could well be performed on a different platform or using the same tool, but whatever the case, the customer would have to go through the whole process again. If the customer doesn’t meet lending criteria and the application is turned down by underwriting, the adviser will then need to ‘rebroke’ the case to a new lender, who will also have a vulnerable circumstance identification tool that the customer must complete. This lender may also use a servicing company for origination, which will also require a vulnerability assessment. Should the application be accepted, the customer may decide to take out some protection insurance. This will then lead to another vulnerability assessment and so forth. The list can go on and on. And all the while the customer can get very frustrated and upset at having to do the same assessments time and time again. Ultimately even if all the assessments come out with the same result, it can be a very inconvenient and repetitive process for the end customer and can often add to their already vulnerable state. This doesn’t help anyone.”
And of course, he is right. This absolutely doesn’t help anyone, least of all the vulnerable customer. I would even go so far as to say that this lack of joined up thinking can, very unfortunately, allow some incredibly vulnerable people to slip through the net. Ultimately, not sharing data that is this important is only increasing the potential for detriment for the individual.
When we look at a customer / adviser relationship, we will of course note that the customer may well feel very differently depending on who they are speaking to and where that conversation takes place. For instance, an individual may well open up during a vulnerability assessment because they feel like they are in a safe space, but then may not again in further vulnerability assessments because they simply don’t feel safe or trust one of the other providers they are engaging with. Alternatively, it could play out that the customer believes that because they have already laid their vulnerabilities out to one provider, then they don’t need to do so again to someone else. After all, a customer may well (and very understandably) assume that all salient information would be passed over. The other option, of course, is that when a person tells a difficult and raw story again and again, they can often forget who they have told which detail to and may well miss elements off the next time they tell the story, merely because that information has already been said at some stage. You can see how all of these instances could mean that important information can get dropped without a fully joined up approach.
So, what can be done then? And upon who’s shoulders should responsibility fall to ensure that key details are not missed?
What we need is an industry standard of information sharing that works across all product providers. This not only needs joined up thinking, but smart ways of working from a technology point of view to ensure all providers have access to the same platform to both input key information and indeed, comprehend and intelligently digest the vulnerability data that comes out.
It’s here that I believe a triage system would really benefit the financial services industry. Creating a triage system, much like you would experience when a patient physically attends an Accident and Emergency room at hospital, would allow all the right information to be gathered upfront and then shared safely and correctly down the distribution chain. This would ensure that the customer avoids needless repetition, continues to feel safe sharing their story in a different setting and won’t have to worry about missing out a key detail. This will ultimately take the emphasis off the customer who is going to be feeling very raw and exposed anyway and puts it back onto the providers. After all, this is their responsibility first and foremost.
The key here is transparency, detailed disclosure and indeed ensuring all providers adhere to the same technology and ways of working. A practical and pragmatic guide or industry standard recognised by all would of course be very beneficial too. Until then however a collaborative solution by all providers must be agreed and it must prioritise the customer primarily.
This is the second piece in the series on customer vulnerability. To read the first piece click here.