2. What could the product look like?
Travel insurance products today are unsophisticated… we already know this. From research, I found that Travel Insurance today is:
- The red-headed step-child of the insurance sector;
- Mainly paper/ human centric; &
- Mainframe tech stacks built in the late 80’s early 90’s.
What could it be, if nothing was created before it. Here are some thoughts:
To consider for the product:
- What should we cover? How do people travel with today? Has it changed over the last decade?
- Insurance is typically a product users don’t trust. How do we build trust?
- Travel Insurance today relies on known where users are going. Could we use geo-location technology to make this seamless? Geo-fencing… could this be used?
- Facebook is full of user travel data.. today, everyone ‘check’s in’ and shares photo’s while traveling — could we use this?
- What are the main reasons for claiming? Is there something missing in the current product suite?
- What’s the likely weather while away? Is it tropical cyclone season? Does this affect a users travel experience?
- Could understanding what airlines, transport or hotels users are using impact our insurance? Do people claim more if they use a specific airline or stay at a specific hotel?
So with all that… how might we tackle this?
Be mobile first
Being mobile-first or native means we can use a host of features including providing on-point notifications based on travel information changing or updating. We could use geo-location technology from the smart phone to understand if the cover matches their movements. We could use Facebook SDK to gather more detail about the user and personalize the experience based on this data. We could do similar things on the web, however the geolocation data matched with common behavior on the device pushes a stronger case for mobile. Better yet, a large portion of us take a smartphone while traveling, so it make sense that we build on that first, not a laptop or PC.
Use a REST API
REST API’s go hand-in-hand with mobile development these days. However when it comes to insurance, much of the understanding and fabric of the products are still evolving. Sure, the API can handle the basic core/ hygiene functions of the app, however I aim to create micro-services connecting to all sorts of meaningful services. If we hooked in Amadeus (travel framework), Smart Traveller (safety platform) and WeatherAPI, we’d get a deep understanding of the user, the locations the user is visiting and what risks will be present during the trip.
Add A.I to continuously automate
Part of being an insurer is to collect the appropriate data, analyze against some business rules and create a price based on the risk. Using AI, we could automate the pricing phase of insurance with up-to-date business rules mashed with real-time data collection of the user, the location data and supplementary data that affects the policy. On the flip-side, we could use AI to power the claims process checking policy data, user data and claim business rules to automate decisions. I estimated around 60 micro-services could be used to validate a claim using AI.
Could chatbots help automate claims processes?
This one I feel is worth the exercise in experimentation. I do feel that chatbots can be useful when the intent is clear and valuable. Some chatbots I’ve seen try to do too much and the user is often overwhelmed or confused with the responses. I think for simple claim processes that don’t have as many variables, chatbots could be used. For more complex claims, like medical claims, we should attempt to blur the line between chatbots and real humans creating a seamless and valuable experience. Easier said than done!
Be relationship centric, not product centric
One angle I think is often missed is what truly matters when building a product to meet the needs of today’s users. User expectations have shifted fundamentally over time. Today, building relationships is where it’s at, so we want to focus on that.