Background
Dentolo is an insurance company that has been growing in the past few years and the core product is an online application where customers can log in to submit a claim by sending invoices and request reimbursement.
This application is called Customer Account Area and in addition to claims submission and management, some features for changing personal data such as name, phone number and address were implemented after the Operations team realised that the growing number of customers was requiring manual effort from the Customer Support team to make changes that could be done by customers themselves with an automation flow that would update the database without the need of customers contacting the support via phone or e-mail.
Then shortly after I joined the same scenario of growing requests from customers was happening with cancellations of contracts and alongside with an update in German law for web services to make it simpler and easier to cancel contract, so it was time to make improvements.
Problems
- There were several conditions to be considered for the automation o the cancellation request be executed by our system depending on different cases such as how long the contract was created and active, and if at least one reimbursement was made.
- At the same time that we needed to comply with law requirements and provide an easy to find flow with a minimal amount of clicks, we also had to be careful to not increase the cancellation rate or create concerns in customers that would led to more requests to Support Team.
Goals
- Provide a flow a flow that could be finished in a few steps and with no room to confusion that could generate more requests to Customer Support.
- Decrease cancellation requests to Customer Support.
Process
My first step for this project was to research focusing on 2 things:
Understand everything related to the cancellation process and conditions being used.
Map all use cases possible to make sure I would create a flow that would cover as much as possible, and possible edge cases would be considered for a further iteration if needed.
Therefore I started analysing the flow for both customers and Customer Support agents to identify pain points and possible improvements, and while researching I found out that there were 6 different types of cancellation where we could enable the flow for customers for only 2 of them (luckily these 2 were also the most frequent ones), so the scope had to be:
Withdraw - Contracts that have been active for less than 14 days.
Regular cancellation - Contracts that have been active for at least 15 days or more.
After the scope being defined and aligned with Product Management and Engineering, the next step was to dig deeper all the use cases that could affect the cancellation within withdraw and regular cancellation scenarios and then define the flows accordingly.
Then I ended up with 2 flows that considered the main scenarios as conditions:
For Withdraw cases there were 3 main conditions that could overlap between each other or none happened at all, and for each possible case we needed to inform customers accordingly:
- Claim created
- Reimbursement done
- Monthly payment status (exported or debited)
And for the Regular Cancellations, there were more conditions on top of the 3 for Withdraw:
- Within minimum period of 24 months of active contract
- After minimum period of 24 months of active contract
With all this information collected it was time to organise conditions and what each one would mean for customers to define what we should inform them to prevent further concerns that could lead them to reach out to support if the flow was not clear enough, then I seated with engineers and QA to understand and list all outcomes from the conditions, combine them with law requirements (easy to find and few clicks) and translated and this information into design requirements for the final interface:
- The option for the cancellation should be available in high traffic pages of Account Area.
- The option should be clear to understand with a clear text.
- There should be one single confirmation after the first click to cancel.
The most relevant information regarding the conditions (effective date of cancellation, reimbursement of debited monthly payments and cancel of open claims and pending reimbursement requests) should be highlighted and positioned in a way that would not be easy to go unnoticed or require scrolling down the page to be visible.
Reasons for cancellation survey could not be mandatory or shown before the confirmation of cancellation request in a way users would need to click around to see the confirmation in another screen.
With the design requirements my last step before going to Figma to design the final flow was to check data in Hotjar and Metabase to identify where to place the option and how, and after analysing I defined that:
The option would be a link with static text that would either be “Withdraw” or “Cancel” depending on the time of active contract (this difference is very important in the German language in the context of contracts).
The option would be available in the dashboard (homepage) right above policy information and in the contact page where customers can send requests to Customer Support as both pages had high traffic.
I decided to use a link instead of a button to not use a very highlighted visual element to not risk motivate cancellations but the link would have clear texts and available in 2 different pages, and especially the option in the contact page was contextualised as request to cancel using the form was between top 5 types of requests.
Outcome
Then I designed the solution for Dentolo and Petolo (back then we did not have Vitolo insurance yet), engineers implemented it in one sprint and me and the Product Manager collaborated with data team to support us with the tracking of the results where we should keep an eye on 2 metrics:
- Total cancellations of contracts after rollout of the feature to react fast I case we realised that the feature was driving an increase of cancellations.
- Share of automated cancellations with source in Account Area (Kundenkonto in German) to verify of the feature was achieving the goal of decreasing requests to Customer Support.
After 3 months no increase in cancellations were identified, and after 12 months the feature performance is stable representing around 70% of total cancellations, which means the requests.
Learnings
This project was a great example for me of a successful feature development even without validation research of concept, and it was great to see that I managed to deliver the expected results without compromising total cancellations.
Also the team and the stakeholders learned with data that changes and improvements in cancellation flow will not affect users who are not planning to cancel their contract, only it makes the experience easier and better for the ones who would cancel their contract anyway.
