Hugh, it’s a real pleasure to have you with us. You’ve led major transformation programmes at some of the UK’s largest insurers, shaping how these organisations approach both technology and customer experience. To start us off, what principles have guided your approach to designing customer journeys that truly work for both the business and the end user?

So there’s a lot to unpack there, but if I keep it simple: always design around the customer and always design around customer outcomes.

It’s about understanding the purpose of all your major processes through the eyes of the customer and making sure everyone is aligned around that. Vision alignment is really key. By that I mean having a clear vision. Sometimes finance officers will focus on cost savings or on driving revenues, but you need a vision that creates a strong service proposition for customers, one that everyone can get behind. That means listening to the people who actually talk to customers the most.

You also have to pay attention to digital traffic, to what customers are saying, and to what the people servicing customers are saying. They are usually the best ones to help define the purpose. Once you set that vision, technology then helps to enhance it. It becomes about creating an end-to-end flow that everyone can support, whether you are a tech architect or a call centre operator.

It is really important because you need to simplify the messages that keep everyone on track. Transformations usually take two or three years; they are not something you can fix with a quick switch. So you need to paint a clear and exciting vision of how this will benefit customers and the business. The rest looks after itself, and then it comes down to execution.

‍Thank you so much for breaking that down. To your point, it’s super important that the direction is well articulated, because not everyone always knows where things are headed. Let’s go to the next question. When you worked at Aviva, how did you navigate the tension between operational complexity and creating a simple, effective customer experience? Can you share a moment where that balance paid off?

It’s an old example, but around 2011 we were dealing with significant operational complexity, particularly in financial services where regulation plays such a big role. Unfortunately, a lot of processes were being designed around the 1 percent of cases that might go wrong, rather than the 99 percent that go right. That created a lot of unnecessary complexity in the name of compliance.

We listened to our staff and identified a major issue with paying protection life claims. We trialled new ways of working, setting the purpose very clearly: pay the right money to the right people at the right time. With that shift, we reduced the average payment time from around 30 days to just 45 minutes.

We did that by reimagining the customer experience, rather than approaching it with a tick-box compliance mindset. For example, one old rule required us to see the original policy document. We challenged that by asking: why? The customer had passed away, they could not sign to prove it was their policy, and yet we had been taking their premiums from their bank account for 20 years.

By challenging those norms and focusing on what the customer would want, we introduced same-day settlements for a proportion of cases. It was about listening, setting the right purpose, and taking a systems-thinking approach. You need to understand why complexity exists in the first place, otherwise you just end up redesigning processes without actually changing how you serve customers.

That example was some years ago, but since then technology has accelerated the possibilities even further, particularly with data-led approaches.

‍Absolutely. And while it sounds simple when you explain it, we know it isn’t. So coming on to the next one: where do you think financial services firms most often fall short when trying to digitise onboarding and servicing journeys? What do you think is driving that gap?

I think banks have really nailed a lot of retailing now because they talk to customers every day. It is like a constant R&D process, always improving and finding better ways to serve people. The problem for insurance companies is that we only talk to customers once a year, or sometimes just once every 10 years.

We take money, we put it away, and if you get ill or have an accident we are there to serve you. The insurance industry does amazing things. But when we onboard customers, our focus is on things like where did you get the money from, are you compliant, is all the data correct. These are important, but it often means we just digitise a complex set of processes rather than rethink them.

In general insurance, like motor or home, we have been much more focused on curating data so the customer only needs to provide a few details and we can already validate hundreds of things behind the scenes. In life and pensions, we have largely just transferred complex processes into a digital format. There is more work to do there, because simply putting complexity online does not make it simpler for customers.

That is why I think property and casualty insurance is a bit further ahead. They have used data in smarter ways to simplify the customer journey.

‍That is very interesting. So maybe we can touch on how to make it simpler for the life side of things. With all your experience leading major change programmes, when you are evaluating new technology or automation tools, how do you determine if they are actually making a difference?

I will give you a principle that might sound provocative. No technology has ever delivered any value by itself. What technology does is create capacity. It is then up to leaders to decide what to do with that capacity.

For example, AI creates capacity. You can either use it to save costs by not recruiting more agents, or you can use it to talk to more customers straight away. So when I evaluate technology, there are three things I focus on today.

The first is flexibility. We live in an ever-changing world with ever-changing needs. So I ask: how flexible is the solution, and what is the cost of change once I have deployed it. There are some great technologies out there, but once you buy them the cost of change can be enormous because they operate like a black box. That kills flexibility and agility, which are critical in a fast-moving and competitive market.

Second, it has to meet security and architectural principles. It needs an architecture that allows us to see results quickly.

And third, if it is a major platform decision such as a core policy administration system, then it requires a much more rigorous process. These are hundred-million-pound decisions that you make once every seven years or so. You need to take six months to make the decision, visit at least two reference sites, and talk directly to the people using it, not just the vendor.

For most other technologies, the real test is whether I can add it easily into my architecture, and whether it is built on a code base that gives me the flexibility to adapt it as customer needs change.

‍That is really interesting, and it ties into how the industry is moving more toward APIs to bring flexibility into existing systems. It also highlights how some decisions need a lot of upfront time because once a big system is implemented, it becomes very sticky. So moving on, when we spoke about the challenge of unstructured data, what makes it such a sticking point, and how can firms tackle it more effectively?

Unstructured data has two problems. First, sometimes it just is not there in a usable way. Second, there are lots of people who rely on their big fat salaries because they are good at reading through unstructured data and being the experts. They are not going to advocate for their own demise.

When I look at industries like construction or commercial property, I know there are technologies that can take PDFs, extract the data you want, and process it in seconds. Legal contracts, for example. Someone might say, “That will take me six hours to read.” No, it will not. It will take you six seconds. That is the clue. The barrier is not the technology, it is management mindset. It is transfer AI.

Some of the data reading capabilities are transformative, delivering speed and immediacy. The key is making sure you have the right use cases and that you are building the right data models to support them.

If you look at commercial insurance, legal claims, health insurance, or life insurance, you see the same challenge. There is a huge amount of unstructured data in medical reports, surveys, and adjuster files. The real question is how we let machines do more of the heavy lifting. I am not saying remove humans from the loop. They are critical. But you can absolutely get more immediate decision making and greater efficiency by using unstructured data better.

Absolutely. That is very much what we are doing at Sikoia with document processing. It is not about replacing humans, but freeing up their time to focus on higher-value work. If we bring this back to customer verification, document handling, and affordability checks, where do you see the biggest opportunities for smarter, more streamlined processes across insurance and lending?

As I said, underwriters who can assimilate unstructured data quickly into their rating and risk models will be able to make faster, more accurate decisions. They can say: I have the right price, you are on risk, you are not on risk, or you are on risk with exclusions.

The key inefficiency today is the speed of decision making. Document handling and back-and-forth processes can be eliminated if you can capture more data up front and distribute it to the right people and models. You can set criteria so that routine cases flow through automated decisioning, while exceptions are escalated to skilled technical people.

That means your scarce experts focus only on the cases that really need them, rather than wading through a 40-page loss adjuster or surveyor report. Customers benefit from faster answers, while technical staff concentrate on complex exceptions.

So the opportunity is faster decisioning, smarter exception management, and oversight to make sure the models you are building are working well. We have made strides in this area, but there is still much further to go.

‍That ties back to what you said earlier about simplifying processes and giving everyone a clear direction for change. Without that, you do not know where to plug in new technologies like document automation. So, what advice would you give to leadership teams considering AI adoption, particularly when dealing with a mix of structured and unstructured data?

I would start with the baby steps that the industry is already taking, like using AI chatbots to answer customer queries. That is an efficiency play, but it also gives customers immediacy and comfort.

The next step is using AI to analyse all the queries and complaints we have had from customers over the years, and then asking: why am I designing the product in this way? At the moment, product design is the domain of highly paid experts. But in the future, I see machines generating product design options.

They could present choices based on your criteria: do you want to improve profitability, or do you want to grow by targeting a bigger share of the market? That links back to agile architecture, because you need flexible systems to respond to what AI generates.

Then we can start asking more grown-up questions in insurance. How do I better target certain parts of the population? How do I improve customer outcomes and revenue at the same time? We have years of data, claims experience, credit scores, broker insights, and risk models. Why not use AI to design strategies from that?

We are not there yet in insurance. Other industries are ahead. But eventually AI will start driving those strategies.

‍And that connects to your earlier point about the industry being more risk-averse overall, even though some markets and teams are more agile. Now, bringing it back to your more recent experience, you work closely with fintechs and insurtechs. What are the biggest barriers they face when trying to modernise legacy systems, especially when working with traditional institutions?

Every business has its own challenges. And to be honest, the phrase “modernising legacy systems” is a bit of an oxymoron. Legacy systems are low cost, they are stable, they work. The real question is: what do you want from the customer records and the data that sit there?

If you want to reuse that data in new ways, you need to think about how to build something in parallel. Some organisations can take a greenfield approach and build something entirely new alongside. Others attempt big migrations. That is the cleanest approach, but it is bloody complex, it is expensive, and it usually takes four or five years.

These are big decisions, which is why you need bold business cases. Personally, I prefer organisations to run proof of concepts, try things, and then scale once they see the value. That way, the business case builds itself. You can decide whether to bolt something on, run in parallel, or invest in deeper modernisation.

The reality is that paybacks on legacy modernisation are often five to seven years. But most CFOs and CEOs want paybacks in one or two years, or even six months. If it was that easy, everyone would do it. If you are starting a new company, you have more options. But if you are managing millions of customers on old legacy platforms, you are dealing with a portfolio of long payback projects.

So the real answer is balance. You need a portfolio approach, and you go after the initiatives that show the strongest potential impact.

That is interesting, and it touches on the next question. When you said it can help to do more piloting and stay on your toes about where to go next, financial services are now under growing pressure to plug in external solutions.

Yeah.

‍Rather than building everything in-house, how should they approach platform thinking and partnerships in a way that actually works? Is that simply by running POCs, or is there anything else to look out for?

Well, first and foremost you need an architectural vision, and the executive team all need to be educated to a level of technology competency. That is number one.

We are going to become technology companies that do insurance. Insurance will always be the skill, that is core. But technology is fundamental, and data is fundamental. How you store data, how you get to it, and how you make it available to the right people at the right time is key.

So you have to bring everyone up to a certain level of technology competency. You also need to get people to understand the choices they are making. If you do not have a vision, an architecture that the executive team is behind, two things happen. First, you end up in constant fights every year over what goes into the portfolio. You make incremental progress, but nothing bold. Second, you avoid three or four-year plans and only deliver small steps forward.

Look at esure as an example of success. When they needed to digitise, they picked one provider and one digital solution. They digitised everything from underwriting to data architecture. It took longer, and COVID got in the way, but everyone got behind the digital vision. There were no competing forces inside the organisation. In other firms, where people are not clear on the architectural vision or not all aligned, progress feels like pulling an anchor.

‍That makes sense and ties back to what you emphasised earlier about clarity and teamwork. If a company is really behind the digital direction, what separates a vendor from a true strategic partner in delivering long-term operational and compliance gains?

It is probably not a perfect answer, but let me put it this way. Everyone talks about win-win contracts. As a COO, I never wanted that with every supplier. What I wanted was for the top ten providers, which accounted for around 50 to 60 percent of supplier spend, to be true world-class partnerships.

That meant we had clear measurement that showed if they won, we won. We grew together, and contracts were aligned on outcomes. The worst model was business process outsourcing in the 90s and early 2000s. We paid for bums on seats. Their incentive was to keep people in those seats, ours was to reduce costs. There was no shared incentive to improve processes. Once technology came in, we redesigned those contracts to reward efficiency that benefited both sides.

Procurement leaders need to treat 95 percent of suppliers as suppliers, but 5 to 10 percent as strategic partners. And for those partners, commerciality has to move away from cost-per-unit and toward outcomes.

Already about 40 percent of business process outsourcing contracts are being written as outcome-based. For example, I have a cost base of 10 million, I give it to you for 6, and in five years you give it back to me for 3. Everyone is tied into the outcome. That creates a much better conversation, whether it is around digitisation, data, architecture, or cyber. Outcome-related contracts set a different tone from day one.

From a startup or scaleup point of view, this is a risk because you do not know what your client will do with their processes. You are taking a leap of faith. But it also creates a very different relationship with sponsors and procurement, because they see you are putting skin in the game.

‍That is a really interesting perspective. Let me ask you this: which areas of financial services remain underserved by technology and are most ripe for reinvention in the years ahead?

It is happening, but it is slow. I was part of a consultancy with the right idea at the wrong time, so we had to shut it down. Large commercial insurance is one area. These are risks paying premiums of 50 to 250 thousand dollars a year. Cargo ships, petrochemical factories, multi-commercial properties.

We know risk management systems in these industries run minute by minute and hour by hour. Real-time data exists. Insurers like Chubb, for example, invested in monitoring for hospitals. They track airflow, temperature, water issues in real time. They can send messages back and forth with risk managers to prevent losses. That investment has paid them back handsomely in lower loss ratios. But the industry overall has been glacial in adopting this. The innovators are doing well, but progress is too slow.

Healthcare is another. Devices like watches and phones can predict health outcomes to incredible accuracy. The technology is there, but adoption is limited because of human behaviour. People collect the data, but then do nothing with it. There is a mindset shift needed to really use it.

And finally, I think more and more claims decisioning will become commoditised. That is not a bad thing. We will still need people to fix cars, repair homes, and treat broken bones. But the decision-making about those claims should be much faster and more automated.

‍Absolutely. And that is really interesting. With all of these things, adoption often takes time. If you look at healthcare, for example, there are so many technologies that at first people thought they would never use, and now we are all relying on them heavily. The final question, Hugh, is this: what advice would you offer to leadership teams trying to modernise their operating model without disrupting the core business too heavily?

So I think, look at Aviva. They took a big bet. They spent a lot of money and threw themselves into digital. They ended up a year or two ahead of peers, but it caused a lot of internal consternation. It disrupted some of the business models, but they went for it.

If you do not want to disrupt your core business too heavily, then you are not really interested in transformation. Continuous improvement is good, yes, but transformation requires more. If you only add technologies here and there, looking for hotspots, you end up with an architecture that just builds and builds.

That can work, but it can turn into something that looks like Frankenstein. It is still a strategy if you only want incremental change. But if you want to disrupt a market, then go for it. Either build a greenfield site and a new business to challenge your core, or be very deliberate about transformation.

We did that, unknowingly, with Quote Me Happy. We built it on agile technology but as a standalone. It grew and grew until it started competing with the core business. That is what many organisations are doing today, creating new businesses within and cannibalising themselves from the inside.

The other model is to go big, spend a lot, and get everyone behind one architectural vision. That is what Aviva did. Both approaches can work. But if you do not think big, you will only ever continuously improve. Continuous improvement is fine, but if you want real disruption, you need a clear strategy: either spend big on a unified digital vision, or run parallel businesses that compete with your core.

‍That is a really clear answer, and I think a lot of people will take something valuable from it. Thank you, Hugh, there has been so much to unpack, and your perspective has been incredibly insightful. I’ve really enjoyed this conversation, and I’m looking forward to continuing it at future events and seeing how these ideas play out in the industry.

Good to meet you too. These are important conversations for the industry, and I hope the points we discussed today help others think differently about how they approach transformation.

‍