Quick Quote - how might we reimagine complex sign-up forms?

• As part of an Ideas Factory ideation session we mashed up several of our Futures Board themes - how could we reimagine customer onboarding? And how could we reimagine complex online forms.
• We chose to ideate around the online quoting process for rural insurance.
• With the idea that if data was publicly available, why make the user re-enter it - we queried public property information and used computer vision to scan Google Earth imagery to create a risk profile of the property.

We do a lot of customer digital onboarding flows. A LOT! Between handling identity verification and authorisation requirements (including liveness tests), internal system constraints, and information needed from the customer to sign-up for a particular product or client - forms can become crazy long and crazy miserable for users.

We have three cards that are permanent residents on our Futures Wall:

• How might we reimagine customer onboarding?
• How can we reinvent complex online forms to do the heavy lifting for users?
• How could we better provide contextual help to users?

We decided to mash these up and cracked into one of our bigger #ideasfests. It’s always easier for the team to ideate around a particular problem statement. We gave them online quoting for insurance for a lifestyle block or farm (currently a 45 minute phone call).

Some false starts

We started with ideation and design. The original concept was to come up with a clever interactive experience using imagery and storytelling that would do the heavy lifting for the user. It’s fair to say that by the time we had tackled this from several angles (and knowing the quantity and complexity of data pathways we needed to handle to do a rural insurance quote) it became clear that we were making things more complicated for the user. Not less.

The reboot - why require the user to do anything at all?

We rebooted, threw in another designer and changed the question: how might we do a complex quote, without the user having to do anything at all?

The idea (and challenge) pivoted to: let’s see if we could reduce the effort for the user down to the simple requirement to add the address of the property they want to insure. Ultimately there is a LOT of data out there, and some really smart technology. At this point we added a developer into the mix to help with the problem solving.

What if we could sift through public information on properties and locations, and analyse satellite imagery to understand what needs to be insured, and what sorts of specific risks should be covered?

We built a working prototype that asked the user for just one thing:

Sourcing public data, and scanning Google Earth images

From there, we sourced public information on the property, including:

• The size of the home with number of bedrooms, bathrooms
• Whether it has garages, swimming pools or other valuable additions
• Location to nearby roads and other potential hazards such as waterways.

We then used computer vision to do some basic image analysis of Google Earth images for the property and used both sets of information to identify:

• Additional buildings on the land (such as barns or sheds)
• Blocks of trees and their proximity to roads and therefore powerlines
• A likely profile of the land usage for example several paddocks increases the likelihood of the need for ride-on mowers and/or some livestock to keep grass down
• Other potential hazards.

This enabled us to surface a view of the land with hazards or potential coverables identified.

A screen recording of the (actual) quote experience

With all that in hand, we could create an initial quote of the recommended insurance (with some simple options to modify cover if needed). The process eliminated the need for long forms asking the user to dig up information that they might not have in hand straight away, and provided a quick and seamless experience that could be linked straight into policy systems to create quotes for customers. The experience takes 30 seconds.

Some technical things

We actually built a fully working prototype. Nate used datasets including Koordinates for property data such as buildings, roads, waterways, lakes, pylons, flood risks, conservation land, and paddocks. We also scanned the Google Earth images using Turf. Turf is a modular geospatial analysis engine written in JavaScript. It performs geospatial processing tasks with GeoJSON data and can be run on a server or in a browser. Trees are an important risk variable in rural areas as you are liable for damage if they are blown over onto power lines and cause power outages, or onto fences so that stock gets out.

And finally, a related Ideas Fest

The ideation session for Quick Quote generated multiple ideas. We moved another idea (Companion Form) into a different ideas fest.