The next BIG thing in price comparison

What are price comparison websites?

Everyone is familiar with price comparison websites. They have some of the largest marketing budgets in the UK. There is fierce competition between them and they provide the largest volume of introductions to Insurance brokers of any distribution class.

How do they work?

Price comparison websites work by collecting quote data from customers and firing that data off to a myriad of insurance brokers. The brokers go to the panel of insurers and respond with a price. When a customer wants to buy they click through to the broker’s website and make payment there. During the course of their policy they will interact with the broker but not with the price comparison website.  

What’s the conflict?

Comparison websites and brokers should be working in harmony but they don’t because they have differing aims.

During the policy period the price comparison website wants the customer to return to get a new quote and hopefully earn a new introductory commission from another broker. Conversely, the broker wants the client to stay with them and not go back to the price comparison website.

What if this were to change?

Here is an idea that would revolutionise both the customer experience and the relationship between price comparison websites and their brokers. Customers should never leave the price comparison website. They should still buy a policy from a broker but do this within the price comparison website. When they want to make a change they should go back to the price comparison website; likewise at renewal they should be sent a set of price comparison results.  This would be great for the customer as surveys show that customers often think they are a customer of the price comparison website and not the broker. It would also mean the customer only needing to put their details and payment details into one system. It would also be good for the broker because customers would be more likely to choose brands that offered this service rather than brands that required leaving the price comparison website. It’s a trust and convenience thing.

It’s obviously also good for the price comparison website because they remain in control of the customer throughout their lifetime. The big winners here will be the customers, the price comparison websites, and the brokers that are the first movers in this space. 

Why is it not being done already?

Legacy technology.  Major brokers operate on legacy systems that do not support the necessary APIs for customer self service and payments that this model would require.

Will it happen?

I sincerely hope so. 

How will it happen?

It will be led by the price comparison websites. If they offer this opportunity to those brokers that are technologically able to support it, it would force the other brokers to update their systems and offer this better level of customer service and choice.

The death of innovation

What’s the problem?

Innovation is a good thing, right?

Usually true, but in insurance there’s a large cadre of people who take pride in their inertia. For this reason, in the past decade, there was not much real innovation in insurance. Whilst there has been more in recent years, very few of the big insurers are coming to the party. The UK is one of the more advanced marketplaces in the world, and it’s still pretty backwards by the standards of other industries (e.g. marketing, fashion, even banking is ahead of us). Why is that?

Lack of investment? No – there are billions being pumped into Insurtechs around the world.

Lack of ideas? No – there are huge communities of tech entrepreneurs like the InsurtechUK which foster innovation with great people and great ideas.

The real problem

If you ask anyone involved with insurance which are the slowest dinosaurs in the jungle the answer is: insurers. Even getting an agency (a standard contract to distribute an insurer’s products) takes months. Try to ask them to work with new technology as you’d better be prepared for a long old slog.

So there are lots of insurtech innovators out there, with great tech, great ideas, loads of funding… but nothing to sell!

The big insurers have a monopoly that is perpetuated by the big software houses. Try to set up a new insurer? That takes even longer than it does to set up a new brokerage – you’re talking about years to get approved by the FSA. What tech startup wants to spend years just getting regulated to get going?

What’s the result?

There are a small handful of large insurers, and they only work with a small handful of large software companies. Both have dated technology that prohibits innovation either from the inside or from the outside.

I spoke with one top-10 insurer last month who admitted they wouldn’t know how to integrate a new software house because they hadn’t done it for over 15 years and there was no one left who remembered! It’s not an isolated example.

What about IHP?

IHP (Insurer Hosted Pricing) was supposed to offer the insurers products to the wider market with nice interfaces that didn’t require an enormous amount of technical support or oversight from the insurer. Well, that didn’t work (see also my other blog on why).

What is the solution?

There are two ways this could go:

1. Insurers could rebuild the APIs (interfaces) of their IHP solutions to make them easily accessible to all insurtechs. This would create amazing distribution possibilities for their products and foster collaboration and innovation and competition.
2. A new (much bigger and scarier) breed of insurers could emerge from the likes of Amazon, Google, or large VCs. They will have distribution, technological superiority, and won’t have read the rulebook of ‘we don’t work with new companies’.

There are high barriers to entry in insurance but our current stock of insurers cannot continue to stifle innovation and hope the world doesn’t notice. Time is running out.

Personal vs Commercial Lines

I’m often asked if the Ignite Broker policy admin system “does” personal lines or commercial lines. Answer: it’s the wrong question. Let me break it down for you

P vs C: is there a difference?

Simply put – personal lines products are sold to individuals and commercial lines products to companies. To that extent they’re different. And commercial products are sometimes perceived as more ‘complex’ but is that true? In fact, to my mind, personal and commercial products are very similar, and there is a better question to ask when it comes to compartmentalising lines of insurance.

What are the key differences?

Commercial products tend to be more ‘complex’ in question set and placement because there is more variety to companies than there is to pets and their owners. Commercial products can also involve multiple insurers, payments direct to the insurer, and referrals. Personal lines products tend to be more price-sensitive and therefore have more point-of-quote enrichment, complex rating tables, and e-enablement.

Having said all that, there are also price-sensitive commercial products and complex personal products with bespoke underwriting.

Open market rates

There is one key area in which some systems can be said to be either commercial or personal lines-based. That is when it comes to Open Market Rates (OMR). A small number of large (and old/established delete as preferred) software houses have built up a large panel of OMR in their particular area of expertise (i.e. commercial or personal lines). For OMR commercial lines go to Acturis (https://www.acturis.com) and for OMR personal lines SSP (https://www.ssp-worldwide.com) or OpenGI (https://opengi.co.uk). These companies do this stuff well.

I am of the opinion that OMR are increasingly insignificant but that’s a blog for another day…

So is Ignite personal or commercial?

Coming back round to the question, Ignite does both personal and commercial lines, but only of certain types. Here is a sort of graph + Venn diagram to illustrate the point:

Ignite’s true sweet spot is in automated underwriting sold online (low on the y-axis). We predominantly do personal lines, because more of those products are e-enabled and traditionally fit a larger market. Having said that, Ignite is increasingly involved with SME, Cyber, and other less bespoke-underwritten commercial risks.

So can there be a cross over from personal lines into commercial lines? Absolutely! And there is great benefit to doing so: all of the learnings from complex online personal lines risks (e.g. streamlined customer journey, enrichment, automation, etc) apply to commercial too.

I suppose the conclusion is that, if you’re looking for a system for commercial products, see if you can’t find yourself a personal lines one!

Tech vs Human Touch… vs??

Insurance Times published an article recently on whether brokers should focus on tech or human touch: https://www.insurancetimes.co.uk/insight/the-big-question-september-2021-how-can-the-insurance-industry-best-marry-technology-and-a-human-touch/1438455.article

It was their Big Question for September.

The majority of the respondents focus on how tech can enable better efficiency/automation/customer experience. This seems pretty self-evident these days – you’ll not find many people who don’t see the benefits of it.

The elephant in the room is really the cost of the tech. It’s quite simple to hire and train a new member of staff to deal with customers or manual processes. It’s a well-trodden path and the £20k-odd per year cost is a benign and known one. The cost of tech can be enormous.

The answer therefore to tech vs human touch is actually tech + human touch. Which again might seem self-evident. But in fact, the two are still largely viewed in opposition by brokers. I’ve had a number of brokers recently tell me that they are a ‘service’ broker not an automated ‘sausage factory’. They add value by ‘talking to the customer’ and directly ‘addressing their needs’. These lines are used as an apology for not investing in technology.

I’m too nice to say it to them in person, but they’re wrong. Brokers that want to offer quality service to their customers need to offer technological solutions (24/7 online self-service, short question sets, chatbots) because this is better customer service, and it drives down the cost of administering policies (and therefore the cost of the policies themselves).

Brokers should accept that there is an element of the unknown to insurance (and risk) and therefore a single engagement strategy simply won’t work. As long as customers are not forced down a single route (either online or call centre) then they will use the service that works for them. Two customers of a very similar demographic might have vastly different requirements (e.g. a complex MTA or none at all) and vastly different preferences for communicating (e.g. one might not like people and prefer a chatbot).

The best option for clients is lots of options, and that is what tech enables.

And as a final nod to the elephant: why not charge for these services according to cost? There’s no shame in it costing more to have a call centre with a well-trained operative than a £50/month chatbot. Customers will understand…

The problem with Insurer Hosted Pricing

What is IHP?

Back in the day, insurers used to send out physical rate tables for brokers to use to calculate premiums. Brokers reported sales via a monthly bordereaux. This was a bit before my time, but I’m told they were good old days. Then the insurers started to send Excel rating guides to brokers (or more specifically brokers’ software houses) that were built onto the software house rating engine and reported to the insurer in daily EDI messages.

The current vogue is for Insurer Hosted Pricing (IHP) where brokers’ software houses apply directly to the insurer with quote information and are given back a price, and in some cases, even documents.

What was it trying to achieve?

The move from manual rate tables to Excel sped up the process of providing a quote. But rate updates still took weeks or months to implement. IHP was supposed to speed up rate updates, avoid software house fees, and make the insurer rates more widely available.

Did it work?

Sort of. Rate updates are now a bit quicker than they used to be because the insurer has direct control. But those rate updates still need testing, and so it’s not quite as quick as hoped. Also there is now the cost overhead of managing a public-facing API (much more complicated than just sending out a new spreadsheet of rates each month).

The area where it has really failed is in widening the availability of rates to the wider market, outside of the big 5 software houses. The idea of IHP was that with well documented, well validated, public-facing, open APIs, then innovative Insurtechs would be able to get access to rates without having to use one of the legacy big 5 software houses. That hasn’t happened. In fact, it takes even longer to integrate to IHP than it used to do to just build the pricing in a software house.

The head of e-trading at a Top-10 UK insurer admitted to me: “we’re just not sure why it takes so long, the whole point was that it was meant to be quicker! Despite IHP, we’ve not integrated to a new software provider in over 15 years. I’m not sure we’ve got anyone here who’d know where to start with it!”

What’s the solution?

There might not be one, but if there was, it would probably be in revisiting the APIs (that is the public-facing connection points for IHP) and re-modelling them to make them easier to access, easier to support, well documented, well validated and genuinely an opportunity for innovation. Currently IHP is cumbersome and just another layer of cost and delay in an industry that doesn’t need more of that!

What is a single code base?

A single code base: what is it, and why is it important?

No matter how tech-savvy you are (or not) you’ll have come across single code lines.  Perhaps you don’t realise when you have, but you have.  If you use accountancy software for example (e.g. Sage or Xero), you know that there are lots of other companies using it and that there are periodical updates to the software.  It gets better every now and then.  But you don’t notice when it happens, you just log in and there it is: better. 

The same is true for Ignite’s insurance software.  We have one version of our software and we update it every two weeks to make it better.  The updates are often small but they keep all our clients at the forefront of the system’s capabilities.

We do this even though it makes development slower.  It’d be much quicker to simply clone the latest version of your system and give that to a new client, rather than to merge all the functionality and fixes you’ve done for all the previous clients into a single code line.  

Why is this important?  Because lots of other policy administration software companies don’t use a single code base.  Instead, they have a major version upgrade they release every 6 or 12 or even 24 months. When there is a new version the clients are asked to pay for the upgrade. That’s fair enough, everyone has to earn money, but what if you don’t buy the upgrade?  Answer: your version of the software gets left behind and you’re stuck on a time-bomb of a system.  And if you try to upgrade in the future it might not work, because the people who used to work on your old version one, or two, or five years ago have forgotten how it works, moved to another company or retired.  Then hey presto: you’ve got a legacy system.  Suddenly upgrading is a business risk, and you’re going to have the same problem again in one, or two, or five years. 

As a software house, if you don’t have a single code line you end up with a tangle of systems a bit like human evolution’s ancestry as in the diagram shown: lots of defunct versions that get left behind along the way and go extinct. 

One of our esteemed competitors recently announced that they’re moving to a single code line.  Great news, good idea.  Two questions: what happens to all the poor buggers who’re on the old versions?  And secondly, do you really expect us to believe that you’re going to stick with a single code line in the future?  I’ll believe it when I see it.  

So if you’re on a system that has the words Version 6 (or similar) after it, then you might want to buy a platform that runs a single code base in the future…

Scoping your Requirements

So you’ve made the decision to buy a new Policy Administration System. Your existing system is too slow/buggy, changes are difficult or expensive, maybe you want to set up a new product line or brokerage, or maybe Covid-19 has pushed forward your digital roadmap.

Where to begin? Well, to start with you Google ‘insurance software’ or look at the ads in the Insurance Times. There are lots of companies out there, but finding out which is right for you is going to be hard. You contact a few but how to tell if they’re going to do everything you need? There are big companies and small companies. How do you compare apples with apples?

Bit of advice: you need to come armed with a set of requirements. You won’t get very far asking what systems do because they do an awful lot, and lots may not be relevant to you. Ideally, you need a Business Requirements document, or what we call a Scope.

The bigger and better this Scope is, the more likely you are to choose the right company and get the right system.

Shocking admission: Ignite Broker might not be the right system for you! And that’s fine with us. The last thing we want to be doing at Ignite is providing systems to clients who could get better ones elsewhere. There are some great tech products out there and if there is a better fit for your business then go for that.

Ignite is particularly good at certain things – e-commerce, digitisation, integrations, accounting, real-time pricing, the list goes on – but we’re not so good at others – open market products, paper-based operations, London markets, the list goes on.

The scope is all about defining what is important to your company and therefore which system provides best for those requirements. If you’ve got the expertise and time to write a detailed scope document (which can run to hundreds of pages) then go for it! If you haven’t then Ignite can help. The first stage of any project – before contracts are signed. Yes, we charge for it, but it will pay for itself many times over in the long run.

The scope document is systems agnostic, and you’re welcome to show it to other software companies. This way everyone knows what you need from your system and you can truly compare the systems in front of you.

So if you’re looking for a new system, contact us for a demo and talk to us about how a scope document can help you make the right systems choice.

One word of warning: if any company ever says they can build what you’re looking for, don’t buy it. The functionality you need is out there somewhere and comes out-the-box. In a good scope, bespoke work should be at an absolute minimum.

Evolving a data enrichment strategy

Most brokers/insurers are doing some sort of data enrichment these days – even if that’s only a vehicle lookup to check validity/value/etc, or a postcode to validate an address.

But there’s a lot more you can do with data enrichment, and there is a lot of data out there.

The big question is: where to start, and having started, how should your data enrichment strategy evolve?

Why do data enrichment?
Perhaps the most compelling answer is that everyone else is doing it! But in truth data enrichment also can result in:

• Increased pricing accuracy
• Streamlined customer experience
• Reduced cancelations
• Reduced fraud

To achieve these lofty aims you have to do things with the data, not just have it. And that is where a phased approach to data enrichment is important.

Phase I – validation
Let’s assume you’ve chosen a data enrichment partner or partners. The likes of LexisNexis, Experian, and Percayso (all of which Ignite integrates directly to) all offer an array of data to enrich the picture of someone getting an insurance quote.

There are a number of data fields that may be relevant. Try to collect as many as possible to start with, even if you’re not using them immediately.

In Phase I, concentrate on validation: make sure the risks you’re taking on genuinely are what they say they are. For example, don’t ask a customer if they have CCJs – just get the data and quote/decline based on that. Don’t ask if they’ve got motor claims – use CUE to validate it instead. This has the added benefit of asking fewer questions to the client, which makes their whole experience better.

Phase II – expanding the appetite
After 3-6 months, have a meeting including your data enrichment provider, your software house, and your insurer to discuss additions to the strategy. The discussion might include expanding the risk appetite to cater for technically higher risks (like younger drivers or higher value homes) but with the protection of knowing the providence of the client.

Phase III – claims
After 12 months of quarterly reviews, it’s time to dig into the claims data.

There will be some high-level correlations with claims that you can pick out using just Excel and some common sense. This is where collecting lots of data from the start comes in handy because you can review it now and see what might be relevant.

Implement a small number of changes at a time in order to avoid confusion over what is and what isn’t working.

Phase IV – machine learning
Finally, there are some correlations within large volumes of data that can’t be gleaned with the human in Excel. These include multi-factor correlations such as Age vs Postcode vs Credit Score or suchlike. To understand these insights some machine learning tools are required. This is a relatively specialist and technical subject (which Ignite’s team can help with), but it makes sense to get the easy wins in the first 3 phases first.

Data enrichment offers a complete picture of customers and improved pricing accuracy that can help you achieve a real competitive advantage. Stay ahead of the curve by evolving your data enrichment strategy.

To learn more about data enrichment and how we can support you, get in touch!

What is Insurtech?

What is insurtech?

Insurtech is a broad term to describe any of a new wave of technologies and companies that are actively trying to digitise insurance. Insurtech can come in many forms, but it is united by the focus on bringing digital benefits – such as automation of processes, online customer experiences, and machine learning – into the insurance space.

Examples of insurtech companies in the UK
Zego – https://www.zego.com/

Percayso – https://www.percayso-inform.com/

Wrapper – https://www.wrapperinsure.co.uk/

For a general overview of some of the most exciting UK insurtech’s visit: https://insurtechuk.org/

Why invest in insurtech?

Insurance is an area that has historically been slow to adopt technology. Industries like social media, travel, and fashion have stormed ahead, where financial services and insurance have lagged behind. Insurance is nonetheless a massive global industry with in excess of $5 trillion a year spent within it per year. The last 2-3 years have seen a considerable upturn in investment in this sector. Success stories of companies such as Lemonade and Hippo in the US and Zego in the UK have shown investors that there are sizeable returns to be made in Insurtech.

Willis Towers Watson 2020 Insurtech report

What are the benefits?

All participants in the insurance lifecycle benefit from quality Insurtech.

Insurers stand to benefit through better insights into their products through data access, enrichment and analytics.

Brokers can renew their focus on customer service when decent insurtech automates many of their manual processes.

The end customer is more likely to deal with and stay with insurtech-led brokers because their online experience is more pleasant, simpler and integrated.

Insurtech and AI

AI is a buzzword in many industries, and in insurance we can make use of AI in a number of ways. In truth the industry has some way to go before AI (or more likely Machine Learning – ML) is a backbone of all parts of the process. ML is already used by actuaries, but only used to a limited degree so far in customer-centric interactions such as next-best-step decision making and UX enhancements.

Insurtech is blazing a trail that is disrupting the old guard of insurance and the plethora of recent successes and scope for improvement in the market in general can only mean more interest, investment and innovation in this space over the coming years.

Microservices

The Ignite Broker platform provides a lot of functionality. That’s great, but it’s not always all relevant to our clients. The modern insurance broker needs to acquire best-of-breed software and that means picking and choosing functionality from different providers.

To allow brokers to do this Ignite Broker is built in a modular fashion. Brokers can choose which modules they need and substitute out or enhance ones that they can get elsewhere.

For example a broker might already have a great customer journey and website. No problem: Ignite has an API for that and the broker can use the Ignite policy administration and rating functions without changing their website.

Another example: a client might already have a rating engine (internal or external) that holds their pricing algorithms. Ignite’s policy administration system can simply call to this new rating engine as well as the Ignite proprietary one.

Most recently Ignite has been chosen to provide the Ignite Accounting module for a major broker platform supporting over £180m of premium. APIs between Ignite and the client mean both systems can run and be deployed independently, with loose coupling, and remain highly maintainable and resilient.

How is this done? Rather than having a large system that relies on all its parts to function, Ignite Broker is a series of smaller services that talk to each other, also known as “microservices”. Think of it like a honeycomb, where each of the cells are built on one another; independent but also integrated. For each cell we use the best available tech and, when something better comes along we crack the wax seal (as it were) and substitute in something better.

Some of our microservices include: rating engine, customer portal, commissions, complaints, and more.

If you’d like to read more about microservices go here

If you’d like a demo of the Ignite honeycomb (sort of), go here

« Previous Page — Next Page »