IT is boring, we all know that. But it starts to get interesting when wonky IT affects your insurance quote engine, or fails to make customers happy. Good IT can boost your profit margin and one way that can be achieved is by understanding APIs. Yes, we know it’s nearly the holidays and the World Cup is on, but have a read of this piece by Craig Olivier, Head of Business Development at Genasys Technologies.
As in the insurance industry, the tech world is one full of acronyms. If you’re not an out and out techie, it’s probably hard to work out whether you should be excited about AES or CHAP or worried about PPTP.
There is one acronym however that anyone in the insurance industry who is looking to enhance customer interaction should be excited about – and not just because it sounds like a beer: API, or Application Programming Interface to give it its full name.
While APIs have been around for some time, it’s only more recently that they have become a critical system requirement to allow different technologies to interact with each other.
In an ideal world, everyone would have a single software platform that does everything their business may require. This would allow all information to reside in one place and all interaction to happen on a single platform.
But sadly we don’t live in an ideal world. There are a number of services, data providers and operating systems all performing certain tasks and combined, they deliver the full eco system facilitating the business requirement. You need the ability to run a core back-end platform with the ability to leverage best of breed complementary systems to enrich the customer experience.
Perhaps a simple analogy can explain APIs. Think about a rail network. Trains provide the ability to move people or goods from one point to another. Quite a bit of work is required up front to plan what routes are required, clearly defining what beginning and destination points are to be serviced. Once this is understood, then a set of infrastructure needs to be put in place to facilitate this including the laying of tracks, possibly building tunnels, agreeing what type of trains will be supported (electric, diesel, etc) and providing for the supported dependencies.
When this is all in place, you can start thinking about the schedules of when trains can run, what routes will be supported at what times and then possibly a booking system, which can be seen as part of the security protocols and throughput control.
So in essence, an API publishes certain end points or access points (think tracks and stations) that can be consumed by other systems. So when software platforms are defined, certain of their core functions are published via an API to allow external systems and platforms to leverage internal functionality using clearly defined API calls that can instantiate these requirements.
Back to the insurance space, I’ve outlined a few good examples of where APIs can be used to enhance the end-to-end lifecycle.
Single view of customer
Most businesses are looking to have a single view of customer across multiple lines of business. This allows for up-selling and cross-selling opportunities together with combined discounts and generally better management information. In reality, most organisations have a number of core lines of business systems that run in isolation. If these systems have open architecture and provide API end points, this information can easily be collated into a single view.
APIs can also facilitate a single record from a customer perspective allowing covers to be added to the existing customer rather than recapturing common information. This also ensures that the customer centric information is recorded in one place rather than duplicated to prevent information from getting out of sync.
Empowering Digital Channels
When it comes to direct to consumer business, distribution channels are required to be able to provide the ability to quote and bind new business.
We’ve actually achieved this using a Conversational User Interface (CUI) or Bot. Products and rating is defined in the back-end application which is published via the API. The Bot can then understand the end user’s intent and facilitate data capture via various methods – for example taking photos of a driving licence, dropping a pin to identify address information and then pass all this information via the API into the back-end.
The information can then be validated using the underwriting engine and calculate a premium which is presented back to the end user. If the quote is acceptable, it can be bound which in turn will accept the quote in the back-end and activate the policy.
This can also apply to external portals or embedded insurance functionality at point of sale. Essentially, any quote and buy functions happening on other environments or platforms can engage with the core underwriting and rating systems to facilitate quote and buy, or further facilitate the claims process.
Data enrichment is key to enhancing the customer interaction. The ideal is to ask few questions, if any, and have the ability to enhance the data using additional feeds.
There are a number of simple enrichment sources such as Company Registration Number lookup, What3Words and Google Maps to identify address information, but let’s use the example of Experian to illustrate what can already be delivered. It’s possible to obtain full details of a vehicle from its registration number so there’s no need to ask for this information at quote time. Taking it a step further using a photo of the car, APIs can be used to extract the registration number and then use Experian to get all the vehicle details. This ensures the correct risk is covered without requesting the prospective insured to capture this information.
There has been massive growth from the insurtech space. The drive is essentially to disrupt the product space and how and when policies are sold by developing new interactive sales front-ends in the form of applications or widgets in existing platforms (e.g. Amazon) that facilitate policy sales.
The theory is that if you offer the right product at the right time then people are more likely to buy. However most of these disruptor companies or initiatives do not have back-end policy admin functionality so they either need to build it bespoke or try and integrate with legacy insurer platforms which don’t have open architecture. Integration with a modern application that has published APIs allows for seamless integration and then immediately the insurtech has full back-end functionality, possibly giving it a competitive edge in the distribution space.
Mobile and Usage Based Insurance
Another major growth area is providing insurance functionality to customers via mobile apps together with client portals. This allows insureds to self-serve from getting quotes, performing mid-term adjustments on their policies to the ability to register and track claims.
Driving the product innovation side of things is the move to usage based insurance. This allows for items to be insured when needed – for example, the insured can simply open the app on their smart device and swipe to the left to start cover on a specific item. We’re also seeing further integration into telematics devices to gain more accurate underwriting information of how and when an insured drives.
This is all available via a mobile app, which needs these functions published via the back-end system APIs.
The days when software platforms could exist in isolation performing single tasks are long gone. They need to be designed with an open architecture that facilitates simple integration from other platforms or sources. Technology needs to support an ecosystem of complementary functions and data providers to create seamless customer interaction and prevent duplication of functions and or information.