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!