#10 - Grâce aux “opérations”, comment les assureurs peuvent rivaliser avec les insurtech

Lorsque j’étais en charge des « opérations » en Santé et Prévoyance chez MERCER, on demandait régulièrement à nos clients ce qu’était pour eux une ‘bonne gestion’ ? Souvent, après un long silence, la même réponse : “une bonne gestion, c’est une gestion dont on n’entend pas parler”.

Ça montre le niveau d’attente des clients DRH et le mot d’ordre des mes collègues commerciaux : “faites le job, faites le bien… et surtout pas de vague”. Une vision défensive de la gestion.

Chez ALAN, changement de discours. Il faut se différencier par l‘UX, donc “les Ops” doivent pleinement participer à la différenciation. Une vision offensive de la gestion.

Ces deux approches ne valent pas généralité. Il n’y a pas là une “bonne” et une “mauvaise” pratique. Il y a un même élément de la chaîne de valeur mis en musique de façon différente, selon les ambitions et les résultats attendus. Différente, mais pas irréconciliable.

Gestion et UX, même combat !

Vue de loin, l'UX est souvent assimilée à l'interface utilisateur (UI). C’est évidemment très réducteur. Dans l'assurance, l'UX est également déterminée par la gestion. Lorsque le digital ne peut pas simplifier des processus lourds / réglementés, vous pouvez choisir d’agir sur les conditions d'assurance afin d'éviter les frictions.

Prenons un exemple : les complémentaires santé en France permettent aux parents de couvrir les enfants majeurs qui sont encore à leur charge (je simplifie). D’où des démarches à accomplir pour justifier de la situation des enfants majeurs, sous peine de suspension de leurs droits. C’est lourd pour le gestionnaire, lourd pour les assurés : il y a des oublis, des droits suspendus, des réclamations, des droits rétablis, des frais de santé à régulariser. Bref, une tannée. Avec ALAN on a décidé que les enfants pouvaient être couverts jusqu’à 24 ans, point-barre. On ne demande pas de justificatif entre 18 et 24 ans et on suppose qu’au-delà, ces jeunes adultes auront quitté le bercail ou auront leur propre assurance. Pas de friction… et pas de réclamation en 5 ans que j’ai supervisé les opérations chez ALAN.

Il faut aller dans les plus petits détails et questionner chaque hypothèse : si nous omettons tel sujet lors de la souscription, que se passera-t-il maintenant ou en cas de sinistre ? Quelle va être la réaction des utilisateurs ? Comment pouvons-nous mesurer la justesse de nos choix ?

ALAN s’est montrée assez radicale sur cet exercice. Est-ce qu’un acteur établi pourrait également fluidifier l’expérience en agissant sur les Conditions générales ? Sur le marché de la Santé collective, ou le “remplacement à l’identique” est une pratique courante, on serait tenté de répondre “vaut mieux éviter, ça va faire des vagues”. ALAN a challengé cette vision en promettant en contrepartie une UX bien supérieure.

Laissez le client fixer vos priorités

Pour l'assurance, les défis liés aux opérations sont nombreux : l’émission des contrats, l’encaissement des primes, le support aux clients, la gestion des flux financiers et, bien entendu, la gestion des sinistres.

Qu’on soit un gros acteur ou un petit, la question du focus se pose de la même façon. Ce qui importe, c'est de partir de ce que l’utilisateur remonte, et non de partir d'un plan préconçu. Pour un acteur établi, le plan préconçu serait de décider de développer tel service et de ne le lancer que lorsqu’il est finalisé à 100%, quitte à y consacrer une année pleine.

Lorsque nous avons lancé notre première assurance Santé avec ALAN, nous n'avions pas eu le temps de développer tous les services en ligne habituels. De nombreux utilisateurs avaient besoin de consulter une simple liste de leurs remboursements ; ils nous contactaient via notre chat, en disant : "Je ne trouve pas où sont listés mes remboursements, pouvez-vous m’aider ?". Nous interrogions alors la base de données manuellement et envoyions un joli PDF. Les utilisateurs étaient un peu surpris de ne pas pouvoir le faire eux-même, mais puisqu'ils obtenaient leur liste sous dix minutes, ça passait.

Par ailleurs, en analysant nos interactions avec les utilisateurs, nous avons remarqué, qu'ayant un grand nombre de startups dans notre portefeuille, il arrivait souvent que des assurés quittent une entreprise pour en rejoindre une autre, les deux étant clientes d'ALAN. La gestion des transferts des droits des utilisateurs dans une telle situation est techniquement délicate et une erreur peut perturber fortement l’expérience utilisateur.

Plutôt que d'investir pour automatiser l’export des listes de règlements, nous avons donc d'abord mis en place un outil de back-office pour mettre à jour la base de données en cas de changement complexe. Ce que j’en conclus : si nous avions présupposé les besoins des utilisateurs plutôt que d'attendre des remontées granulaires, nous aurions probablement choisi d'automatiser des extractions de données simples plutôt que des modifications de base de données complexes.

Ce mode de fonctionnement me semble aussi applicable pour les acteurs établis : ne pas over-engineerer - aller aussi loin que nécessaire pour résoudre les problèmes vraiment identifiés, sous un délai imparti ; ne pas anticiper les problèmes qui n’ont pas encore été remontés - parce que vous ne savez pas quand et selon quelle magnitude ils se produiront.

C’est ce qui s’appelle mettre réellement le client au centre !

Faites des choses qui ne “scalent” pas

L’exemple précédent montre aussi que ne pas automatiser tout de suite permet de voir où sont les vraies frictions et d’agir là où il le faut vraiment. Dans une startup, on n’hésitera pas à faire les choses à la main dans un premier temps, ne serait-ce que par manque de bande passante. Mais cela permet aussi de mieux appréhender les frictions et de prendre des décisions plus informées.

Chez un acteur de grande taille, cette approche “manuelle” se heurte à des impératifs d’industrialisation qu’on peut comprendre. C’est aussi une question d’agilité dans les usines de gestion : une fois qu’on déploie un mode opératoire industriel, il est plus compliqué de le modifier.

Prenons un autre exemple : la carte de tiers-payant. Pour l’ensemble du marché, c’est un papier plié en 6 au fond du portefeuille, avec plein de codes uniquement compréhensibles pour les professionnels de santé. Chez ALAN, on la voit d’abord comme le premier contact entre l'utilisateur et la marque. Pour un nouveau venu sur un marché mature, c’est une occasion pour se différencier. On a investi sur un format carte de crédit inséré dans un welcome-pack original, façon origami. Nous avons reçu des réactions enthousiastes sur les réseaux sociaux. Mais il y avait des inconvénients : son coût unitaire et une mise sous pli manuelle. Nous savions dès le départ que cette carte ne passerait pas à l'échelle, mais nous avons persisté, considérant qu’il y aurait suffisamment de fonctionnalités exceptionnelles pour compenser une éventuelle déception lorsque nous reviendrions à un format plus classique.

Découpez les grands défis en petites rondelles

Toute organisation fait face à de grands projets. Derrière le distinguo (que je ne développe pas) entre le “cycle en V” et les “méthodes agiles”, il y a la façon dont une organisation appréhende les grands défis. Soit on veut mettre sous contrôle l’ensemble du problème à résoudre sous forme d’un projet, la montagne peut alors s’avérer insurmontable. Soit on découpe le projet en petits défis qui constitueront autant d’étapes plus faciles pour arriver au sommet.

La mise en place du support clients d'ALAN était considéré comme un énorme défi. Cela nécessitait l'intégration de compétences nouvelles, les former au produit, le déploiement d’un genre de CRM pour soutenir le service, de fonctionnalités online pour les utilisateurs, de fonctionnalités de back-office, etc. Dans une organisation traditionnelle, nous aurions tout attaqué de front. Chez ALAN, nous divisons ce grand chantier en de multiples petites étapes et séquençons le déploiement de manière à franchir des étapes incrémentales en continu.

Pour commencer, on n’a pas recruté une équipe dédiée au support, on répondait nous-même au chat, à tour de rôle, à la main, en profitant pour hiérarchiser la roadmap tech en fonction de la récurrence des demandes des utilisateurs. En fin de compte, itération après itération, nous avons construit le support client progressivement, sans révéler de défauts durables dans nos réponses.

C’est tout à fait transposable dans une entreprise mature : cela s’appelle le product management, et ça a d’autant plus d’impact lorsque c’est déployé au delà des équipes de tech.

“Build before buy”

Les opérations d'assurance impliquent souvent des prestataires externes. Ils contribuent aux services de base (réparateurs, experts, éditeurs de logiciels, centre d’appels, etc.). Gérer des externalités est considéré comme un mal nécessaire par les acteurs historiques. Si cela ajoute de la complexité, ils en acceptent la contrainte au nom de la flexibilité ou de la variabilisation des coûts. Les startups, elles, voient le problème autrement.

"Reuse before buy, buy before build", c'est ce que disent souvent les entreprises en place. Dans le contexte d’une startup, "Reuse before buy" n'a pas vraiment de sens, puisqu’il n'y a pas grand-chose à réutiliser. Ensuite, "Buy" signifie devenir dépendant de l’extérieur : le service proposé par le presta est-il totalement aligné sur ce dont nous avons besoin ? Quel est l'effort requis pour l'intégration et la maintenance ? La feuille de route du fournisseur est-elle alignée avec nos enjeux ? Que se passera-t-il s'il abandonne ce produit ou augmente drastiquement ses prix ?

Lorsque les services en question sont au coeur de la proposition de valeur d’une startup, celle-ci optera pour le “build”.

Lorsque nous avons démarré ALAN, nous avons sélectionné un délégataire pour la gestion des sinistres et nous permettre de démarrer l'activité en focalisant nos investissements tech sur la vente, plutôt que sur la gestion. N'importe quel opérateur historique aurait fait de même, mais il aurait maintenu cette sous-traitance par la suite.

Chez ALAN, le jour même où le contrat a été signé avec ce TPA, le CEO me demande quand je pensais que nous pourrions internaliser l'ensemble. Je pensais qu'il plaisantait... ce n'était pas le cas 😬 : la gestion des sinistres est essentielle pour fournir la meilleure UX; s'approprier pleinement le processus est le seul moyen d'être libre d'essayer de nouvelles choses, d'itérer. L'ajout d'externalités ralentirait notre rythme, si ce n'est pire.

En fait, beaucoup d’acteurs établis font le choix de gérer en interne des prestations ou des développements tech. Où est donc la différence ? Elle est dans la façon dont le produit vit, une fois internalisé. Chez MERCER, nous avions notre propre plateforme IT propriétaire, mais les politiques du Groupe nous imposaient une cadence trimestrielle pour les mises à jour logicielles. L’entreprise évoluait donc à cette cadence (j’espère que ça a changé depuis 🤨). ALAN déploie en prod plusieurs fois par jour si nécessaire. Cela signifie qu’en amont, tous sont focalisés sur l’optimisation en continu du moindre détail qui améliore le service, selon des cycles ultra-courts. C’est comme ça que se gagne la course.

Il nous a fallu 18 mois pour construire, par couches successives, la machinerie de gestion des sinistres made in ALAN, mais elle a établi un nouveau standard de qualité de service sur le marché.

En guise de conclusion

Les acteurs établis assument un déficit d’agilité par rapport aux startups et y répondent par la force conférée par leur taille. Mais qui a dit que les acteurs historiques ne peuvent pas eux aussi casser les codes ?

La réponse se situe au carrefour de la gestion des processus et de la culture, c'est-à-dire lorsque les pratiques opérationnelles finissent par définir la culture de l’entreprise: l’inertie n’est pas un choix, ni une fatalité.

• Le diable (et l'UX) sont dans les détails : il faut s'y plonger réellement !
• Interroger la pertinence des pratiques établies du marché.
• S’appuyer sur les remontées des clients pour décider des prochaines étapes.
• Prioriser radicalement pour résoudre le problème le plus impactant avant de passer au suivant.
• Faire ce qu’il y a à faire, sans anticipation inutile, en adaptant les ressources dédiées aux enjeux.
• Itérer, itérer, itérer !