How we enabled our Sales to build and price custom coverages
Building a new health insurance product is a tedious process. It generally involves a lot of people:
- Sales to define a set of guarantees fitted for a client
- Insurance and data experts to check its compliance and price it
- Operators to configure the newly created product in claim management systems
At Alan, we designed and implemented a Product Builder that our sales can autonomously use to build, price and share a health insurance offer in a few minutes.
In this article, we will showcase the main innovations and technical challenges of our approach.
Create autonomy
Sales tool with clear UX
We strive to offer our members delightful applications with a clear and nice user experience.
But we didn’t want our internal sales users to be let down. It’s always frustrating when tools for clients are shiny and polished, but internal tools are ugly, cluttered with too many buttons, and buggy.
Our intent was that sales could have a clear and simple web interface, without any need to be an insurance expert. The tool had to optimise their efficiency.
To achieve this, the whole flow was designed very early in the process by one of our UX Designers after some user research with sales.
Technically, the Product Builder uses the same stack as Alan’s web application: PostgreSQL database, Python/Flask for the backend, React and Redux with Typescript for the front-end, and our internal Design System for styling to match Alan’s application look and feel.
As we didn’t want to reinvent the wheel, we also took advantage of a few additional libraries we love, like Formik for forms, Yup for form validation and React-tostify for error and warning messages. This stack allows us to provide good performances as well as a dynamic and user-friendly interface. For instance, forms are regularly auto-saved (server-side) and the tool provides contextual feedback messages.
Compliance checks
In France, health insurance products have to be compliant with a set of constraints: some are a legal obligation for the insurer, others are an obligation for the company covering their employees, depending on their branch (activity segment, like tech companies or restaurants). In both cases, we want our proposed products to be compliant. Indeed, simplifying the life of company admins is part of our mission!
Therefore our data model makes it possible to enforce all kinds of checks required by these constraints: mandatory guarantees, absolute minimum/maximum reimbursement levels, etc.
On the client side, we provide immediate feedback to the user and educate them:
- When entering any invalid information, a warning immediately appears
- If the user misses it and tries to submit the form all the same, they are scrolled to the first invalid field.
Make pricing fast
Once sales have input all the required information, they need to price the product to be able to share an offer.
In a previous article, we explained the main concepts behind our pricing methodology. Despite all its advantages, it has one major drawback. Implementing it naively would lead to an unaffordable pricing time: two hours to price one product!
It would have been a pity to optimise time spent in the UI when the final step would take hours.
The approaches we rejected
Before explaining how we sped up the pricing engine, it’s worth focusing on why a naive approach would be so slow.
To estimate the expected cost of a custom guarantee level, we rely on 2 steps:
- Smart sampling: we replicate the demography of the target company with anonymised sample member profiles from our portfolio
- We replay past cares of these profiles in our claim engine, taking the newly considered reimbursement formula into account
Using our internal claim engine is the key part of this strategy. Yet, this engine has initially been designed to accurately reimburse users, not to optimise execution time. It takes about 100ms to process one care, which is more than enough to reimburse our users instantaneously on a day to day basis.
We estimated there was no point in trying to optimise the engine. Gaining a 4 factor would have resulted in 30 min to price a product, which is still way too much. Gaining a 100 factor to reach an acceptable pricing time of ~1 min would have needed, if ever possible, huge changes in the way the engine is architectured. It would also have led to more complex and less maintainable code. The cost and risks of this approach outweighed by far its potential benefits.
We could also have considered creating a simplified version of the claim engine, making it a pure function that doesn’t rely on side effects, like querying the DB when decision on the reimbursement depends on the past (example: you have to wait 2 years before renewing your glasses). But we rejected this idea very quickly. The whole point of our pricing methodology is to use the exact production system to be as accurate as possible. We also couldn’t afford duplicated maintenance costs. Indeed, the claim engine regularly evolves.
We had to move to a smart idea to conciliate speed with reduced maintenance.
Pre-calculation strategy
Simulating past cares is a requirement of our Pricer’s methodology. Nevertheless, we don’t need to wait until we receive a pricing request to simulate them.
We decided to pre-calculate once and for all the result of past cares for existing Alan member profiles against a dozen of predetermined reimbursement levels for each guarantee. This took about 24 hours.
Then to price a guarantee for the desired reimbursement level:
- For each sample profile, we sum the pre-calculated reimbursement amounts for this guarantee and reimbursement level
- If the level was not pre-calculated for, we linearly combine the 2 closest. For instance, if we pre-calculated for every multiple of 10 € and the desired level is 55 €, we average the results for 50 and 60 € with equal weight.
- We annualise the covered amount sum for each sample profile. For instance, if the profile has been covered by Alan for 2 years, we divide the sum by 2.
- We average the annual covered amount for all sample profiles
The result is an annual average expected cost per guarantee. This is called a pure premium in the insurance world.
From the pure premiums, we easily derive the final prices of our products, including taxes and the service fee of our business model.
Instead of letting users wait 2 hours to get a price, we spent 24 hours pre-calculating data once for all. Then we are able to price products for them in less than 30s.
Future challenges
The first version of the Product Builder was shipped in a few weeks. It is now fully operational and intensively used, as we are in the middle of the health insurance sales season.
Still, we have several challenges in front of us to improve it and ensure its evolutivity.
Dedicated infrastructure
In order not to delay the delivery of the application, we relied on our existing infrastructure. It mainly consists of an operational backend designed for short transactional queries and a queuing system with dedicated workers for asynchronous jobs.
Implementing a computation heavy service such as the pricing part of the Product Builder was new for Alan, but we’ll have more and more use cases with such requirements. It puts the reactivity of our backend at risk, as it could become a bottleneck, especially on the database’s side.
We are considering creating and relying on a dedicated infrastructure that will be much more suited to computation heavy projects.
It should enable, along with other optimisations, to reduce pricing time to a few seconds only.
Continuous evolution
Our pricing engine is currently a frozen system. We precomputed data once for all.
In the future, we want to be able to integrate data from the new claims of existing member profiles regularly, which will increase the accuracy of the prices as the amount of data is growing.
Still, we don’t want to lose one important feature of the pricing engine as it is today: we provide price stability for a given client while there are ongoing discussions. Continuing to ensure this while making the engine a continuously evolving system will be particularly challenging and interesting.
Automatic data extraction
Today, most of the time sales spend in the Product Builder is dedicated to reproducing a coverage as close as possible to the one a prospect has with competition.
They would dream of a system able to automatically extract and structure data from competitor contracts and match guarantees and reimbursement levels with Alan’s grid.
This is very challenging as, between several insurers, guarantees are often organised differently. Some examples:
- Competitors can split in two a guarantee that is unique in our grid
- Competitors can merge two guarantees that are independent in our grid
- Competitors can express guarantees in a different referential (we use total reimbursement, others exclude amount reimbursed by sécurité sociale)
Still, even providing a partly working system, with the ability to manually correct would already be of great help for sales. We could also leverage their manual corrections as source of truth labels to start building a continuously improving Machine Learning system.
Conclusion
The Product Builder is a perfect example of the Software Engineering vision we have at Alan.
On one hand, all engineers are fullstack developers, which means we must be able to implement a product initiative autonomously from end-to-end, without having to rely on other individuals or teams to complete some parts (backend, frontend, mobile).
On the other hand, we all have our specialties that we are invited to thrive at when selecting projects we work on. In the case of the Product Builder, some of us could particularly take advantage of their front-end or data engineering skills.
Alan is hiring talented software engineers to revolutionise healthcare. If you’re interested, contact us at jobs@alan.com.
