In Insurance, Will the Quickest Always Win?
Insurance has spent years being told it needs to move faster. Transformation programmes need to deliver sooner. Technology needs to be adopted more quickly. Decisions need to happen faster.
So at Camelot SHIFT, we asked a deliberately provocative question:
Will the quickest always win?
It didn’t take long before the room started challenging the premise. Quickest at what? And towards what outcome?
What followed was a hands-on and practical discussion about AI, transformation, governance, operating models and customer experience, with plenty of examples of what happens when the technology moves faster than the organisation around it.
The conclusion was not that pace does not matter. It was that speed only helps if you are moving in the right direction and the rest of the business is capable of moving with you.
Adaptability may matter more than raw speed
One of the earliest distinctions was between being fast and being adaptable.
Long-term transformation plans become harder to defend when the technology itself is moving faster than the planning cycle. The discussion turned instead towards shorter cycles of action and learning: try something, see what happens, adapt and scale where it makes sense.
That doesn’t mean abandoning strategy, but it does mean recognising that the route to get there might change. A business can still know where it wants to go without pretending it knows every turn it will need to take along the way.
The organisations that do this well may not be the ones that correctly predict the future five years out. They may simply be better at changing course when the picture changes.
AI is speeding up the work before organisations have caught up
Some of the most useful examples came from the technology side of the discussion.
One example described AI tools being connected across different stages of delivery, from project requirements and design through to coding, testing and deployment. Work that once moved through long, sequential cycles can now happen much closer to real time. That creates a very different operating environment.
The conversation also touched on the possibility of smaller teams working much more directly with the business, rather than relying on lengthy hand-offs and occasional input over many months. That sounds like exactly the kind of acceleration the industry has been asking for.
But it also exposes the next problem. The technology can move quickly. The governance, operating model and change capability around it may not.
Sometimes moving faster requires groundwork first
Governance was one of the least glamorous but most important themes in the room. As organisations create more agents, tools and automated processes, somebody still needs to understand what exists, where it sits and how it moves safely into production.
But the answer wasn’t to put every new idea into another six-month approval process. In fact, the opposite came through strongly.
If teams understand the architecture, the boundaries they can work within and the route into production, they can move much faster without reopening the same conversations each time.
One phrase from the discussion summed this up neatly: slow down to speed up. Do the groundwork once, properly, and you create more room to move later.
Automation can create work, as well as remove it
One of the best examples of the evening showed why transformation cannot be judged on technology alone.
A process had been introduced to automatically extract and ingest risk information that an underwriter had previously entered manually. Technically, it worked. The problem was what happened next.
The data still needed checking before it reached underwriting, so the work shifted elsewhere in the organisation. What looked like an automation win suddenly created a conversation about whether extra resources were needed to support the new process.
The technology had removed one task but hadn’t actually removed the work.
Another example involved an underwriter who carried on manually entering information, even after a new system had been introduced to do it for them. From the outside, that can look like resistance to change. Dig a little deeper and the reason becomes more understandable: there was not enough trust in the new process, and explaining what was needed felt slower than simply doing it manually.
Again, that’s not a technology problem. It is a trust, adoption and operating model problem.
The sprint gets the attention. The harder work comes afterwards.
One analogy from the discussion compared transformation with training for a sprint versus training for a marathon.
The sprint is exciting. A pilot creates momentum. It gives people something visible to point to. It can prove that a piece of technology works. Scaling it across a business is then a very different challenge.
That requires the less visible work of understanding processes, modelling operational impacts, improving data and making sure people actually have the capacity to engage with the change.
The discussion made the point that many organisations begin transformation work when the teams involved are already under pressure. People are pulled into workshops to explain what they do. Processes get mapped and months pass.
By the time the solution is ready, the process itself may already have moved on.
The issue is not a lack of effort. It’s that transformation often sits on top of an organisation that is still changing underneath it.
Greenfield is easier. Integration is where it gets interesting.
Another practical example looked at an automated quote-and-buy capability built largely as a new set of systems.
The process could take information from broker partners, run triage, clearance and sanctions checks, apply business rules and return a quote in seconds where the previous process might have taken days.
On its own, that is a strong success story. The harder questions came afterwards.
How do you integrate that capability into the wider organisation?
How do you scale it across more products?
How does it interact with legacy technology?
And how much technical debt are you creating along the way?
That is where speed becomes a bit more complicated. Building something new can be relatively straightforward compared with embedding it into a large, established organisation.
Are we asking for ROI too early?
The conversation also challenged the way organisations think about investment.
There is understandable pressure to show a return quickly, particularly when AI spend is increasing. But that can push teams towards the easiest cost-saving use cases because they’re simpler to quantify.
One contributor recalled an industry discussion where senior leaders were asked what material business change they could directly attribute to significant technology investment.
No one in the room could give a clear answer. That doesn’t mean the investment had no value. However, it raises an important question about whether businesses are always measuring the right things.
If AI is only viewed through the lens of doing today's work more cheaply, the industry may miss opportunities around growth, distribution, customer experience and entirely different operating models.
ROI still matters. The time of the question matters just as much.
Keep coming back to the customer
Perhaps the simplest story of the evening was also one of the most effective.
One example involved someone trying to return a football shirt online and get a voucher. A basic customer request. Instead of speaking to someone easily, they ended up spending around an hour interacting with a digital process and repeatedly typing “yes” simply to stop the system timing out.
At the end of it, they still didn’t get the outcome they needed. Somewhere inside that organisation, the process may well have looked more efficient.
More customers handled. Fewer people required. Better digital adoption. For the customer, it was simply worse. That’s the danger of optimising a metric rather than an outcome. Technology can make something faster without making it better.
So, will the quickest always win?
The consensus? Probably not on speed alone.
The discussion pointed towards something more useful: build an organisation that can move quickly more than once.
That means understanding the problem properly before building the solution. Teams must put enough governance and architecture in place so that people can move without constantly stopping for permission. And organisations need to consider adoption, data and the operating model from the start, rather than once the technology is finished.
It also means being willing to change direction when the evidence tells you to. The organisations that do this well may not always be first out of the blocks.
But they are far more likely to keep moving when the first burst of momentum runs out.
Continue the conversation at Camelot GATHER
On 9 December, Camelot brings the wider insurance community together at 1 Moorgate Place, London for Camelot GATHER.
One of the evening’s conversations will explore The Practical Realities of AI in Insurance, looking at what happens when AI moves beyond ambition and into the day-to-day operation of a real organisation.
