Blog

Data migration is fun!

Data Migration 

Data migration is not the fun bit.  When you’re upgrading your business’ technology stack with a new system the new app is the fun bit, the automation, the chatbot… that stuff.  But not the data migration.  

Why isn’t it fun? 

There’s a few awkward bits: firstly, before you can kick off data migration you need to get hold of all your data. As a first step this involves letting your old girlfriend (software house) know you’ve got a new one.  Then, as they’re processing that little bombshell, they’re asked for a machine-readable data dump for a transfer.  Like asking a newly ex-ified girlfriend if she wouldn’t mind just transcribing all your years of conversations and providing them in a4 notebooks with equally spaced columns, grouped by date.   This has to be tactfully managed to avoid being a real dump of a data dump.  

How it gets into the new system

There are a number of ways to get data into a new system.  Not all of them are horrible, and there are often lots of benefits to the process.  The basic options (all of which Ignite has done as some point) are: feeding the data through a validated API configured to requirements; using the automation framework to input risk details through the UI’s validation; rekey.  Horses for courses, and none are options to be ruled out.  

Benefits of data migration

Lots of companies have pre-GDPR data that they haven’t dealt with appropriately.  Data transfer is an excellent way of correcting this issue.  Data can also get a bit mangled over time with inconsistent inputs or database types.  Data transfer, especially through a validated API or automation framework offers the opportunity to cleanse data into formats that can better reported on and understood.  

Business risk

Data transfer is perceived as a business risk.  It is true to an extent, but these days it is increasingly seamless: test runs can be done in minutes, and mapping is increasingly easy.  Part of the skill comes in designing the new system.  If, in migrating, the existing product structure is largely retained, with upgrades to the functionality around it rather than the data capture itself, then migration can be easier.  Also consider how much data really needs to be transferred, and what can simply sit in an external data repository to be used for uncommon events like an investigation.  

Cost

Data transfer no longer needs to be expensive.  As long as there is decent access to historic data in some sort of machine readable format (e.g. historic EDI or Bordereaux) then it is something that, with proper management, can be done without headache or heartache.

The Impact of Price Walking

I wrote a blog in December 2020 about the potential impacts of price walking regulation that came into effect at the start of last month. I predicted a stalemate where customers would shop around less, renewal prices would be more competitive, and new business prices would be more expensive. This has not come to pass… yet.

What we have seen so far across our broker base is a great deal of change and churn. Those brokers and insurers that practiced price walking are being hit the hardest, and those which didn’t are making hay. There is a rebalancing process underway – the aggregate market prior to the new regulation being announced was relatively stable in comparison to this month. That is all changed as companies grapple with questions such as whether to prioritise renewals or new business, and how much of a fee they can reasonably charge.

To give an idea of the scale of the flux: two brokers using the Ignite policy admin platform that didn’t historically price walk have seen new business grow 135% and 181% beyond last month, and this was only by the 20th January…. Meanwhile, another broker budgeted to write 1,100 new business and had only managed 200.

It is worth mentioning that the new legislation also heavily favours newer high-growth businesses that can afford to prioritise new business over the more lucrative renewals and build market share. Ignite powers a number of these so our stats may be skewed.

One thing has changed already: the ‘crazy’ pricing (as one top-50 broker put it to me) that plagued the market in the second half of last year (in reference to heavy negative commissions and a land grab before the regulations hit) has at least calmed down.

So, a new prediction for the future: there will be churn for the next 3-4 months, then it will calm again, but watch out for more action in Jan-23 as all these new business cases come up for renewal! Opportunities abound…

100 days of Ignite as part of Verisk

Dear Diary,

It’s been 100 days since Verisk’s Sequel acquired Ignite. There is a whole backstory to that which has already been written about here.  But what has actually happened in our first hundred days?

Whilst it might be my first time, our acquirer is an old hand at such things. Verisk acquire approximately 1 billion companies per year and therefore have an entire team dedicated to integrating those companies into the Verisk “family”. There are work streams for HR, finance, accounting, security, data, infrastructure, networks, training… About 12 in total.

Naturally, I have delegated furiously and my excellent team has taken the majority of the flak.  That said, there has undeniably been a lot to do for everyone.  

Whilst that might be a negative, there have been plenty of positives. The collective benefits to all Ignite staff of being part of Verisk are substantial.  Things we couldn’t countenance/afford as a small company are now the normal: Health care, big pension, gift matching, dental… the list goes on.  The call to discuss the benefits with staff took 90 minutes. There have also been substantial upgrades to our hardware, infrastructure, data security, and networks.

One of the things Verisk is very good at is not interrupting the flow of business as usual work. If ever the integration is becoming too onerous, it is put off for a few weeks so as not to be a disruption.

Getting to know a company of nearly 10,000 staff and tens, maybe even hundreds, of business units, has been quite a task. There are immeasurable benefits to being part of such an organisation – learning which are the relevant ones and which order to attack things in is the real challenge. After 100 days I feel I am now getting a sense of the whole. Everyone has been incredibly welcoming and generally disabused me of the misapprehension that large companies move slowly and attract people who do likewise. There’s lots going on and many opportunities.

I feel like I’m only just scratching the surface so far… let’s see how things have got on by day 200…

Innovation vs Stability

The paradox

When you’re a young company, one of the best bits of the job is the pace of change, innovation, disruption, and new ideas. As the company grows you take on new concerns, pesky things like revenue, clients, more staff, live systems… Essentially, you become more responsible.

As a company, everyone knows you have to innovate in order to succeed.  However, clients also demand stability, reliability, and predictability.  

So what is the solution to this paradox?

In doing one you sacrifice the other. It is possible to achieve perfect stability if one never changes or innovates.  And with a total focus on innovation, there would be little or no stability. 

The answer lies in finding the right balance for both business and clients. To ensure you continue to be at the cutting edge, even as a company grows, it is vital to continually test the boundary of innovation.  And that does mean occasionally putting a foot over the boundary and, to mixed metaphor, rocking the boat a bit.

In Ignite terms, this means trying new things as often as we can, and accepting that sometimes we might get it wrong and that it might have consequences (e.g. breaking some functionality or even some system downtime)

To avoid being sucked into a “stable” bureaucratic company system we must be sure to continually demystify the system itself, challenge assumptions, iterate and reflect. I usually hate buzzwords like these so I’ll break them down individually… 

Demystify the system – make sure everyone knows what everyone else is doing. There should be no black boxes, closed loops, or sub-groups with mysterious priorities. 

Challenge assumptions – accept that there is no one right way of doing things, and make the time to try new things and fail in the process. 

Iterate – make regular changes, and make each change as small as possible. This speeds up the velocity of change and makes the effects of changes more apparent.

Reflect – always look for feedback on what could be done better, and use this to further iterate and challenge assumptions. 

Ignite is growing rapidly, and even as we do so we’ll try to live by these ideas to keep us right in the middle of the fine balance of innovation and stability.  

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…

« Previous Page — Next Page »