Le point essentiel que nous avons retenu en créant des API de lignes commerciales avec 12 assureurs

Mise en ligne

12-API-learned

Cette dernière année a vu un regain d'intérêt en matière d’échange de données des lignes commerciales et nous en sommes très contents. Depuis 2007, Policy Works collabore avec 12 assureurs différents afin de développer divers API d’échanges de données de lignes commerciales (intégrations). Nous avons beaucoup appris en cours de route et comme beaucoup, nous voulons que la connectivité permette d’assurer le succès. Nous partageons donc certaines de nos expériences.

Quel sont les points essentiels que nous avons appris ?

Ne changez pas le comportement des utilisateurs.

Les représentants du service à la clientèle, les responsables du marchandage et les gestionnaires de comptes utilisent des systèmes de gestion de courtage (lignes personnelles) et des systèmes de gestion commerciale (lignes commerciales) pour gérer leurs stratégies. Ils utilisent ces systèmes avec grande efficacité. Ce qui est un avantage, car au quotidien, ils subissent une pression énorme : traiter des renouvellements, commercialiser de nouvelles affaires et créer de multiples certificats. L'efficacité du système se traduit par la productivité de la société de courtage.

Au tout début des API de lignes commerciales, nous avons introduit des solutions de « passerelle », de Policy Works vers les portails des assureurs. Cela modifiait les processus de travail de l'utilisateur, en particulier pour les nouvelles affaires. Bien qu'une bonne partie des données capturées dans notre système étaient téléchargées, l'intégration allait à l'encontre des habitudes bien formées. L'utilisation de la solution « passerelle vers portail » restait à un niveau très bas.

Pourquoi ? Les gens n'aiment pas changer de comportement. À moins bien sûr lorsque…

L’expérience utilisateur est bien plus engageante (qu’elle ne l’est à présent).

Si vous souhaitez changer le comportement et voulez réussir, les nouveaux processus doivent être bien plus engageants. Lorsque nous avons développé les API vers les portails, l'expérience utilisateur n'était pas excellente. Un plus grand nombre de champs devaient être remplis sur plusieurs portails et souvent différents portails affichaient différents champs. Et donc, si un spécialiste du marchandage essayait d'obtenir trois cotations sur une affaire, il se retrouvait sur trois différents portails.

L’expérience n’était pas plus engageante que d’envoyer tout ça par courriels, par télécopies ou simplement appeler le souscripteur. Hélas, l’utilisation illustrait cette expérience.

Alors, en travaillant avec AXA, nous avons lancé AskBack (une vision et une idée géniales), où nous nous connections directement à leur système de gestion de souscription. Le système AXA manipulait les données de soumission saisies et « posait » d'autres questions qualifiantes dans une interface intégrée à Policy Works.

L'objectif était d’obtenir des cotations en temps réel. Mais cela se produisait rarement car les règles de souscription étaient si strictes que les spécialistes du marchandage et les représentants du service à la clientèle subissaient une boucle infinie de questions-réponses.

Une meilleure expérience ? Pas du tout.

Nous avons affiné ce processus avec d’autres assureurs. La solution fonctionnait (du point de vue technologie) mais ne gagnait pas de reconnaissance de la part des courtiers pour les raisons suivantes :

  1. Les règles de souscription étaient trop contraignantes ;
  2. Les types de risques étaient enfermés dans un carcan trop étroit, mettant ainsi fin au processus en temps réel ; et
  3. En raison des points 1 et 2, les processus aboutissaient trop souvent à une
    « demande transmise à un souscripteur. »

Le courtier passait beaucoup de temps à répondre à un tas de questions, pour finalement être dirigé vers un souscripteur ? Après quelques essais, qui continuerait à le faire ? Personne.

L'expérience utilisateur ne correspondait toujours pas à celle qui existait déjà : des PDF entièrement complétés envoyés à plusieurs souscripteurs directement à partir du système du courtier.

Ce qui nous amène à comprendre que si vous ne pouvez pas rivaliser avec le comportement existant, exploitez-le.

Exploiter le comportement existant.

Cela nous ramène à la situation actuelle. Pour ce que ORBiT, IBAO, IBAC et CSIO prêchent depuis une décennie : l'échange de données / la connectivité doivent démarrer et se terminer dans les systèmes de courtier.

Mais cette déclaration est incomplète. La deuxième partie de ce principe est :

Toute solution de connectivité doit être invisible pour l'utilisateur ; elle doit être parfaitement intégrée aux processus de travail existants.

Sans déviation. Sans changer de comportement. Sans boîte de dialogue supplémentaire. La solution de connectivité doit être invisible pour tous les utilisateurs.

En appliquant nous-mêmes nos propres règles, nous avons réussi et nous l’appelons la technologie Smart Doc (pour en savoir plus, cliquez ici). Les utilisateurs de Policy Works envoient leurs soumissions aux marchés de leur choix. À l'aide d'un service Web, les données de la soumission sont extraites dans le système de cotation du souscripteur.

Le processus est transparent pour les utilisateurs existants de Policy Works ; il ne requiert aucune modification de processus ou de comportement de l'utilisateur. Les souscripteurs n'ont pas à ressaisir les données dans leur système. Et ils possèdent toujours un document de soumission physique avec des images, pouvant être utilisé pour évaluer le risque.

La RSA l'utilise actuellement, ainsi que SGI Canada, Coachman, L'Unique et Promutuel. (Un autre assureur utilise cette API dans un environnement de test, qui sortira bientôt dans l’industrie.)

L’intention n’était pas de promouvoir notre solution Smart Doc, mais bien de dire qu'après 12 années de connectivité des lignes commerciales et 12 intégrations, nous avons appris que pour que l’échange de données réussisse, les solutions doivent 1) démarrer et se terminer dans les systèmes de courtier et 2) être invisibles pour l'utilisateur.

Dans le respect strict de ces deux principes, nous constatons une augmentation de la connectivité des courtiers.

Analytiques pour les directeurs

Les courtiers axés sur le commerce ont besoin de savoir ce qui se passe avec leur livre. Nous avons développé une feuille de route pour les livres électroniques d'analyse afin de vous aider.

Obtenir le livre

Topics: Lignes commerciales, data, analytics