Alan as a Service — The technical foundations

Sharing the Alan Experience as a service

Alan as a Service provides the “Alan Experience” to mutuelles and insurers, meaning their members have access to our lightning fast reimbursements (👋 reimbursements in less than an hour), our simplified contract management (👋 bye-bye paper contracts), and innovating health services (👋 virtual clinic, Alan Mind, Alan Clear, etc.).

💡 To learn more, you can read our blog: Alan as a Service : notre nouvelle solution destinée aux organismes complémentaires (french)

Building Alan for us is already a hard mission, how do we manage to build it for everybody? We do this by leveraging our current product and our current technical stack.

Let’s have a look at our technical vision before diving into the technical details of Alan as a Service.

Keeping our technical vision in mind

Floating in a suit, in space, requires technical vision 🧑‍🚀 (Photo by Brian McGowan on Unsplash)

We believe in boring tech: we don’t have shiny new technologies and we keep our solutions as simple as possible. Nevertheless, we’re able to build great products, because simple tech applied to complex problems, like health insurance, gives us the best chance at being successful.

💡 You can read about our vision for tech: Boring Tech, Pragmatic Engineering, and Complex Challenges

For Alan as a Service, this means writing as little code as possible. We began by asking ourselves: can we launch without writing a single line of code? (spoiler: number of lines to change is single digit 🤯)

As for any new product, we want to reduce the time to market as much as possible, ship something, and iterate fast. No need to write thousands of lines of code.

Let’s dive into how Alan as a Service works from a technical standpoint, by looking at the various technical components that make it possible.

Reusing our technical stack

We want to maximize code reuse, so we have to first identify the key components that make up Alan’s insurance infrastructure:

• The Health Plan is the centerpiece used by Alan as a Service. At its core, the plan defines the set of health coverages. For example, for our Blue coverage, we define a set of guarantees, which serves as basis to calculate your reimbursements when you go see to the doctor (e.g. Consultation Généraliste OPTAM & Secteur 1 : 400 %, soit 100 €)

💡 You can read about how we define our coverage internally: How we enabled our Sales to build and price custom coverages

• The Claim Engine is the component that calculates how much the member will be reimbursed for a given medical act. At its core, the engine handles care acts, like going to the doctor, having a scan, etc. For example, for a specific care act, the engine will find the corresponding guarantee from the health plan, compute the proper reimbursement (e.g. on May 15th you go see Généraliste Secteur 1, the insurer amount to reimburse is 20 €), and trigger the reimbursement

💡 You can read more about the claim engine: Alan’s Claim Engine: Technical Design Principles

By using those two components, the core features of Alan as a Service are already implemented: we then define our partner’s coverage in our system, the associated care acts, and specific rules to handle them.

Let’s take Lamie Mutuelle, our first Alan as a Service partner, as an example:

Defining the health plan

For Lamie Mutuelle, the first step was to define a “Lamie x Alan” plan together. This health plan is a standard health plan with guarantees, it is defined in yaml, consists of standard guarantees also used in an Alan plan, and some “custom” guarantees that are specific to Lamie for Lamie.

Here is what it looks like:

On the left some “standard guarantees” which are shared with Alan plans as well, on the right some “custom guarantees” for Lamie.

How do we make a difference between an Alan plan and an Alan as a Service plan? We set plan.insurer_name = Lamie on the health plan, “et voilà” 🎉 (remember how we said we didn’t need a lot of code?)

Since the plan is central to our data model, from a specific insurer_name , we can handle most other features:

• Generating the proper legal documents for signature, which are specific to the risk carrier, in our example, Lamie Mutuelle
• Showing the company administrator a specific co-branding in the application and emails, so that their members see who the insurer is.
• Showing the insurer name in our backoffice, Marmot, so that our user care experts and operators can adapt their processes depending on the insurer
• Generating reporting, which are data extraction, for us and for our partners, which also serves as a basis for the monthly billing

Let’s take a closer look at each of these features.

Creating the co-branding in the application and emails

For each Alan as a Service partner, we define the co-branding constraints together. Since each has their own requirements, we have a co-branding component that makes it possible to show the logo and text that are specific for each partner, depending on the page or the email being shown. Here’s how it looks like:

Example of the co-branding during the onboarding (red rectangles), as well as the link to the co-branded contracts

We do not add co-branding everywhere: we do not propose our service as white label. Instead, we discuss with our partner on how to represent both brands, see where it makes the most sense for the members and the company admins, which have different context and usage.

For example with Lamie, we decided to show the co-branding for the company admin, but not for the member, which we thought simplified the experience for everybody. The co-branding can be shown in various parts of our service, such as the application, the contracts, the emails, etc.

Alan as a Service is not only code and configurations, it also has impacts on operational teams and on our processes. Let’s have a look at how it impacts them.

Looking behind the scenes at our backoffice and management processes

When a member or an administrator submits a question, it arrives in an inbox in Intercom, then it gets handled by our user care experts. They use our internal backoffice, Marmot, to find the information on the member, the company, and the contract, which helps them tailor the perfect answer for them 🚀

In other words, we handle all customer service requests using the same process, but for Alan as a Service, the user care experts might answer differently, so we have to show them the proper information. Here’s how it looks like:

We see the “Insurer name” in Marmot, our backoffice, for both the member on the left and the company on the right

What other processes do we reuse for Alan as a Service?

• We reuse how we handle operations, which feeds the Claim Engine with claims data for the reimbursements. Our operators are trained with parsing rules for specific guarantees, with specific rules for Alan as a Service members as well
• We reuse how we do billing for collecting premiums and reimbursement for paying back claims

Improving our limitations and iterating towards market fit

We have a vision for insurance: comprehensible coverage and fast reimbursement. This vision is sometimes at odds with some practices from the industry. For example, we don’t show guarantees expressed in “% of PMSS” (Plafond Mensuel de Sécurité Sociale), because we think it is easier to understand if it is expressed in euros.

This also means we might not support what our partners support, for example in the guarantee table, or for specific management rules, which may or may not be a problem during the construction phase of a new Alan as a Service joint offer. With this in mind, there’s still much to do.

We launched Alan as a Service recently, and we’re excited to continue to improve it! Here are some topics we are currently exploring:

• Develop APIs, so that our partners can handle parts of the process themselves (e.g. the contract signature)
• Open internal tools, such as Marmot, so that our partners can handle parts of the contract lifecycle management themselves (e.g upselling, contract termination)
• Support more guarantee formats, like new guarantee limits, and other management processes, so that creating an offer or migrating portfolios with a new partner is simpler

Looking back on our public launch

We haven’t built a space station, but we did launch something 🚀 (Photo by NASA on Unsplash)

Building Alan as a service required very few technical changes. This is a good sign that our system can support many other use cases, and is extensible if need be. It shows that good abstractions are in place.

These new use cases have forced us to reinforce and consolidate our technical stack: we fixed bugs and made parts of our code base more generic.

💡 Interested by using Alan as a Service? Check out our Alan as a Service page

Alan as a Service is just getting started, we can’t wait to show you all the new cool things we’ll be building! 🚀