Customer Profile

Founded in 2013 by Devendra Rane, Coverfox is India’s largest Insure-tech platform that has integrated with more than 35 insurers and offers more than 150 policies in motor, life, travel, and health insurance. The portal helps bring transparency, simplicity, and ease to the process of buying and managing insurance in India. Using its proprietary technology and algorithm-based platform, users can compare and choose from a range of plans across top insurance companies, understand key features and buy policies instantly and safely

The Objective

In the Insurance business, policy renewals are the mother lode, the bucket of gold at the end of the rainbow. You manage to use all the tricks up your sleeve to acquire a new user on your platform, only to realize that the user has renewed the policy elsewhere. Your recurring source of income just became a flash in the pan.

Coverfox realized this early on, which is why they decided to tackle the retention problem head-on. They used the WebEngage Journey tool to automate engagement for the user’s lifecycle.

Problem Statement

• Increasing policy renewals for users
• Creating personalized campaigns for users holding multiple policies

For a Marketing Automation platform, identifying the user is very important. Each user is assigned a unique identification (User ID), which is linked to the user’s online activity and other attributes. However, there are certain businesses that have a diverse portfolio and one individual user might be utilizing multiple services, or owning several products. This makes accurate behavioral mapping a little complex for one User ID.

Coverfox had a similar issue. Their platform helps broker multiple types of insurance policies: health, life, car, bike, travel, etc. So effectively, one user can be holding multiple insurance policies. Now, each insurance policy is determined by a start and end date which is very crucial. If you take a policy renewal campaign for example, then communication regarding the same would have to be sent to each user with their primary identifier in the system, i.e. User ID.

Here’s an example:

Your system sends a message to the user about renewing their insurance policy, but the user gets confused because he has 4 active policies at that point in time! Similar data issues can also happen where the message goes out to the user for renewing a policy that has already been renewed. This is a bad experience for the end-user and needs to be avoided.

To get around this problem, Coverfox identifies each policy as an individual user. This way, everything regarding that particular policy gets attributed to a unique User ID, and all online activity gets mapped to it directly. This has helped the brand create a highly targeted communication strategy which is deeply contextual and personalized.

Remember the movie ‘Inception’? Christopher Nolan’s cult classic explored the concept of people experiencing a dream within a dream. Coverfox’s retention strategy features something similar: an intricate lifecycle marketing campaign having a journey residing on a journey. Their multi-tiered journey is nothing short of a masterpiece, and the best part about it is its effectiveness: It works like a charm.

The Process

Let us analyze the multi-tier journey concept that Coverfox ran to such great effect.

1) Parent Journey

This journey accounts for a user attribute change (Policy Date change), and upon meeting this primary condition along with a few other requirements, it gives out an instruction to summon an API call. This API call starts another journey that has a detailed engagement flow pre-defined.

• The parent journey is started by a simple trigger – the system checks for a user attribute change. When the date of the policy’s expiry changes, the parent journey gets initiated.
• The system checks to see whether the user ID is in the segment of car policy owners.
• If the user ID belongs to the Car Insurance segment, then the journey waits for exactly 31 days before the policy ID expires to move to the next step.
• Next, the system checks to see whether the Users who have entered till this step do indeed have a renewal due.
• If the users are in the segment of policies with a renewal due, the journey requests an API call to begin the Child Journey. This is where it gets interesting.

2) Child Journey

This is the journey that is started after a change in the user attribute via a custom API call. It contains all the engagement options (Email, SMS) that have been defined to nudge the user at regular intervals upon meeting certain conditions to enhance the chances of conversion, i.e. policy renewals. 

• Leading on from the parent journey, the child journey brings in the users who have a car insurance policy renewal due in 31 days. This is also the event trigger that sets off this particular journey in motion.
• Post-event trigger, the system is instructed to proceed to the next step in the journey 30 days before the policy’s expiry date.
• T-30 days before the policy expires, the system checks to see if renewal payment has been made for the policy ID.
• The Journey ends for policies that have been successfully renewed. However, there are very few customers who are aware of the benefits of renewing early. So, the number of users renewing the policy before its expiry is a minority.
• Therefore, the system then sends an email to the users. This email is a reminder that informs the user about the impending policy renewal date in 30 days and urges them to make the renewal payment right there via a link.
  

Personalization Depth Explained:

1. First name of the policyholder.
2. Car’s make and model number and the registration number along with the number of days left for the car insurance policy’s expiry.
3. Policy number along with the exact date of the policy’s expiry.
4. Details of the service provider that the policyholder is currently using, along with the details of renewal for the same policy including price.
5. Pricing details of other service providers for the same policy.

Now keep in mind that all of these factors are personalized for each unique policy ID, which means that such a highly contextual email is being sent out at a massive scale.

The journey moves to the next step after reaching the event horizon, i.e. 30 days before policy expiry. Now, the journey instructs the system to proceed to the next step 15 days before the policy ID’s expiry date.

When the policy is 15 days away from expiry, the journey repeats itself with one additional step: The system triggers an SMS along with the Email to the users informing them about the 15-day deadline of their policy renewal.

Introduction of intentional delays:

Now, this process gets repeated multiple times as the policy nears expiry date. The time intervals are T minus 10 days, T minus 5 days, T minus 1 day, and finally on the eve of policy expiry i.e. T minus 0 days.

As the policy renewal day creeps closer, the engagement intensity increases. This can be evidenced by the additional engagement flow in the journey. This is an extension of the renewal journey that only runs for policies starting from the T minus 15-day renewal mark, until the day after expiry.

The system is instructed to wait for 1 day. After which it performs a check to find out renewal payment status. If the payment hasn’t been made, the system checks the Email open status for the last email. If the email was opened, then an SMS is sent to the user urging them to renew their policy in advance. The same step is repeated if the email was unopened by the user with a slightly modified SMS.

Now, the decision to leverage SMS as a channel is made after some deliberation and performing several checks to ensure whether payment has been made or not. This is because SMS is an expensive medium, and it is also a rather private channel. Some might consider it to be an intrusion of their privacy or disregard it as Spam if it is overdone.

1 day after policy expiry, the system checks for users who have missed their policy renewal cycle and sends a reminder email to the ones who haven’t renewed yet.  

The Exit Trigger:

The Journey has a built-in ‘Exit Trigger’ event that can end the journey immediately upon its realization. The exit trigger here is the ‘Policy Renewal’ event. Every time a policy gets renewed, the corresponding ‘User ID’ moves out of the journey immediately. This is done to save the user from being engaged unnecessarily because the conversion goal has already been achieved.

Can We Help? – Lead Your Growth By Customer Retention, Not By Acquisition 

The Result

• In the very first month after implementing journeys, the policy renewals increased by 15 percent for Coverfox.
  
• On the back of an intelligent lifecycle marketing strategy, Coverfox managed to increase their Policy Renewals by 30 percent overall.

• 85% of the two-wheeler insurance policies are getting renewed with zero human involvement. With Intelligent marketing automation, their bike insurance policy renewals have been happening on autopilot. 
  
• With WebEngage, about 40% of policy renewals have been unassisted. This has reduced operational costs massively for the business. 
• Coverfox increased their Email open rates by 40 percent, and Email CTR by 10 percent. They did this by engaging with users at the right time with the right message. Their communication strategy was very contextual and personalized for each individual insurance policy. 

• Website traffic from emails has increased by 25%, making the Email channel a powerful communication tool for the brand.

Earlier, the company was using a combination of multiple ESP’s & SSP’s to run their communication campaigns. This made life difficult because performance tracking was all over the place. More so, seamless execution for multiple channels required extensive efforts. With WebEngage, they managed to unify the best of both worlds under one roof with advanced automation capabilities.