By 2019, GoBear's business model was that of an aggregator only comparison platform. The aggregator business model though satisfying the customers' needs for more transparency, and convenience in searching for financial products, presented multiple challenges:
The company's mission was to improve people's financial health and provide access to financial products to everyone. In order to achieve this, GoBear needed to shift its business model to cover the end-to-end user experience and gain more insights into how consumers make decision and purchase.
We launched travel purchase experience late 2019, but shortly after COVID hits South East Asia, the travel industry came to a halt and the company needed to pivot to another product vertical.
We found that motor insurance in Singapore takes up a large share of the local general insurance market. Compared to travel insurance, motor insurance has a significantly higher Average Order Value ($30-$200 vs. $800-$1000).
In 2019, motor insurance made up the largest share of the general insurance market with 27%. This was followed by health (16%), property (13%), employer’s liability (9%) and travel (5%).
– General Insurance Association↵
COVID accelerates the need for consumers to move online for purchases, which Singapore with its digitized population can smoothly make the transition.
Since GoBear was already providing search and compare functions for multiple car insurance plans, we decided to narrow down the scope further to car insurance.
We looked at our competitors in the region to identify opportunities for differentiation.
Some aggregators on the market have implemented their own online self-service purchase with insurance providers of cheaper offerings and more straightforward purchase journey (fewer form fields and pricing factors).
Insurance providers also have online purchase funnel however the experience varies, most with complex checkout experience and lengthy form fields.
Apart from online services, though considered indirectly, we were also competing with agents and brokers who provide offline services to consumers, these agents often belong to one specific insurance provider while brokers represent multiple insurers. Consumers often prefer agents or brokers for big purchases, this process provides them with trust, convenience in the form of advice and purchase process.
We conducted a survey with 300 participants in Singapore, age 21 to 55. Some criteria included: owning a vehicle, having previously purchased car insurance, and being the main or joint decision maker for purchasing insurance in their household.
From our surveys and interviews, we learned that car insurance is not a "want" purchase but a "need" purchase, meaning consumers buy car insurance as a "condition" in order to be able to drive their cars on the road.
Additionally, we identified the 2 main drivers for car insurance purchase: price and value (value for money).
Price sensitive buyers
Buyers who want ease and convenience at lower price point and often choose default plans and buyers who prioritise pricing above other factors, basic coverage works for them.
Value sensitive buyers
Buyers who know cars or insurance well and buyers who own special cars that need specific and customised type of insurance, they want the best values that best suit their needs.
We also found that around 70% of buyers research their insurance online via insurance websites or aggregators but only 24% of purchase happens online.
Online buyers use insurance provider websites or brokerage websites for purchase while offline buyers use insurance provider agents (23% of total offline purchase), car dealers or showrooms (19%), go to branch offices of insurance providers (17%) or purchase through a broker or financial advisor (6%).
The 2 major challenges buyers face when buying car insurance online were trust and convenience.
Buyers have trust issues with buying big ticket (more expensive) items online, and especially if it was from aggregators like GoBear and still prefer offline channels.
Buyers found online purchase checkout tedious and time consuming. "Too many details to fill", and they didn't always have all the information handy.
From our findings, we outlined 3 hypotheses that could be considered our short term, medium term and long term bets, each with their own tactical steps.
If we provide a better online purchase experience with reputable insurers, we'll be able to capture a portion of the online insurance market while steering the business model to capture more values for GB.
For the first phase of development, we aimed to build up the core purchase capability on top of the existing search & compare product. This was to leverage upon existing system for faster development time and existing users.
We wanted to prioritise features like fewer form fields, autofill to alleviate customers' pain points with online purchase to provide a competitive edge against traditional insurers.
At the same time, we could experiment with top of the funnel messaging to cater better to our price sensitive and value sensitive groups in order to bring higher quality traffic (customers with higher intent to buy) into the purchase funnel.
Conditions:
If we provide a mixed online - offline service experience we may be able to capture more of the offline insurance market as trends show slow growth with online purchases as well as an apparent need for human touch
Following Phase 1, we needed to continue building towards our medium as well as long term bets. To capture more data, while still providing substantial values for our customers, we planned to work on account for customers to manage their purchases.
This could mean:
We could also start introducing channel mix into the journey and experiment when we had a customer service agent/team.
Conditions:
If we are able to provide a more customized or personalized experience with usage-based insurance we'll be able to provide a unique differentiator against competitor.
Phase 3 & 4 will be later shaped by the data we acquire and what we do with it.
GoBear aimed to introduce white label insurance products, cross-sell multiple insurance plans as well as developing usage-based products and recommendation mechanism personalised based on customers' data collected.
With the short term, medium term and long term bets in mind, I drafted a plan for what the product evolution could look like from building up purchase capability with purchase funnel, to data collection with account features, and recommendation engines.
Business constraints:
Insurance constraints:
Tech constraints:
We decided that with the insights from our research as well as limitations at hands, coupled with the time pressure to pivot to a new offering, our core features for the first release should:
We outlined core principles to draft the first version of our purchase funnel to guide our decision making when deep diving into the details of design implementation.
Fundamentally, the car insurance purchase journey is the same across all aggregators and insurers.
One of the things we wanted to push for was to reduce the number of fields required for customers to complete their purchase. We dug into our partners' API docs to identify "optional" form fields that we didn't need to include into the form.
At the same time, we faced a dilemma when our business partners required additional form fields for data collection. The team decided to implement this requirement but later ran usability test to evaluate whether the form fields did indeed affect the customer experience.
The limitations with our partners' APIs also presented us with a big challenge, as we could only surface the final premium price of the insurance plan after customers filled in all of their information. This meant there would be a price update happening at the end of the purchase journey before payment. This is one of the most common reasons for cart abandonment in e-commerce. We decided to make transparent this change as the price updated with a clear call-out message.
A marketplace or aggregator always needs to integrate with external partners and their APIs. We worked closely with our back-end engineers to ensure that we captured all the potential error scenarios.
Looking through the API documents, a pattern emerged. All partners required:
Every time an API request was sent, a host of error scenarios could occur. They, however, were largely uniformed depending on what the API requests were supposed to do. For example, an API request for premium update would most likely return "policy not found" or "system timeout" errors.
Balancing between ensuring consistency and designing a "good unhappy" experience for our customers, we mapped out the entire unhappy journey and error message types that helped provide customers with system visibility and an idea of what action they could take following an error.
We worked on additional details to ensure more convenience and trust for our customers throughout the journey:
We also rethought how the previous funnel was implemented and removed the logic of page. Previously, each step of the purchase funnel was hard coded, e.g. certain form fields could only be set up on certain page. Moving forward, we worked to remove this constraint so that the form fields could be:
Upon internal testing and feedback we identified some assumptions that we wanted to validate through usability tests with external users.
We drafted a set of tasks and questions to evaluate whether our assumptions were true. We ran a usability test with 15 external users and the results showed:
Following up on the usability tests, we identified areas of improvements and prioritised a list of additional features (and removed a few previous implementations).
As we launched our self-service purchase funnel and continuously improve it, we also welcomed our first agent into the customer service team.
This enabled us to rethink how we could better provide support for customers who did not qualify for online purchase. By allowing customers to speak to an "offline" agent, via email or call, we could reproduce the human touch without having to send agents on the ground. This was the first step in building up the capability to support offline sales.
"Online - offline mix" sales funnel proved to be a 3-4 times more successful than our self-service funnel, a positive signal that a mixed channel approach was needed.
Through continuous testing and monitoring the data as well as feedback from our customer service agent, we came to the realization that price accuracy was still the biggest issue for our self-service customers. With the top of the funnel only sending an estimated price and the final pricing updating only at the end of the funnel, customers would need to go through the entire process before knowing how much they needed to pay.
This pushed us to take a step back and asked ourselves whether we could succeed at pushing for self-service, online purchase while making no change to the current top of the funnel experience.
What if we captured the "swing factors" (or factors that may affect the final premium) upfront, at the top of the funnel, to provide the most accurate quote that also saved users the experience of having to fill in information multiple times for multiple partners?
We achieved around 30% of our purchase goals despite making some improvements to other metrics (decrease drop-off in the funnel, decrease in time taken for users to complete the online purchase, etc...)
The company unfortunately folded shortly after we launched the car insurance purchase and I left the company for a brief sabbatical. This gave me some time to reflect on some of the successes and failures along the way.
The principle of improv now sounds like a broken record in the design circle but I found this true time and again as I worked to resolve conflicting interests and requirements in product development. Working in fintech and insurtech means that sometimes you need to interact with very traditional approaches and being able to say "Yes, and..." i.e. saying yes, staying open to ideas but also providing evidence and alternatives while pushing back is especially important.
Moving fast and breaking things seems to be the start-up way. There's merit to the approach. Accumulated technical debts without proper maintenance and regular migration and refactoring, however, eventually resulted in slow development velocity and long delivery cycles. This further reduced the risk appetite to radically change the way we approached product development or new ideas. This meant missed opportunities and with COVID, this could even mean the life or death of a business.
Instead of continuously focusing on new features, regular cadence to tackle technical debts, (and design debts) could significantly reduce not just development time and cost but also allow the business to take more risks, pivot and adapt to changes in the market.
There's a certain enthusiasm when it comes to building digital products. However, for certain industries like insurance, offline experience still dominates a large portion of the market. Digitalisation is only a part of the overall experience, a more holistic view of the product as a multi-channel service is essential in shaping a business that provides the right values, through the right channels, at the right time to customers.
This point is further driven home especially in the context of the markets we're in. Culturally there's even a higher level of mistrust towards online purchase of big ticket items in SEA, even though in Singapore is more technologically well-versed, human touch is still crucial.
Insurance marketplace has the typical issue of a long purchase cycle as well as strong attachment to brands. This means that we needed to compete not only in terms of features but also excellent product offerings to make users "divorce" their current options. This goes back to viewing the business and service more holistically, and tackling in tandem different parts of the ecosystem.
