Utiliser Pega GenAI Blueprint pour créer une application de service client pour les assurances

Je vais vous présenter Pega Blueprint dans le contexte du service client pour les assurances. Blueprint est notre logiciel de création d’applications alimenté par l’IA générative, un outil en constante évolution qui simplifie et accélère le processus de définition et conception d’applications métier. Grâce à son intégration avec nos applications d’entreprise et notre environnement de développement low-code, Blueprint permet aux équipes d’itérer avec des logiciels opérationnels en quelques jours au lieu de plusieurs mois.

Imaginons-nous à la place d’un Business Analyst chez U+ insurance. Nous sommes chargés de trouver une nouvelle application de service client pour notre centre de contact et nos canaux (Channels) de self-service. Nous commencerons par aller sur Pega.com/fr/blueprint qui est accessible à tous gratuitement. La première étape consiste à définir le contexte en sélectionnant Insurance puis Personal property and casualty, puis le contexte fonctionnel Customer service et Customer service for insurance.

Ce contexte guide non seulement nos prompts GenAI, mais nous aide également à nous aligner sur l’une de nos applications d’entreprise existantes, ce qui s’est produit ici, comme le reflète la description de l’application. Nous sommes ainsi en mesure de tirer parti du meilleur des deux mondes : les capacités d’IA générative de Blueprint et l’expertise fonctionnelle et sectorielle approfondie que nous avons acquise dans le domaine du service client pour les assurances.

Une fois que j’ai cliqué sur Submit, Blueprint crée un environnement de conception personnalisé pour moi, largement basé sur Customer Service pour l’assurance, que je peux facilement étendre et modifier manuellement ou avec GenAI. Le processus de conception de Blueprint me guide à travers sept étapes. Nous avons déjà terminé le contexte de l’application. Viennent ensuite les types de dossier (Case Types) ou les workflows, suivis du cycle de vie (Lifecycle) et du modèle de données (Data Model) pour chaque workflow, des data objects à l’échelle de l’application tels que le profil client et les détails de la police, et enfin les Personas, qui représentent les utilisateurs du système.

À tout moment, le créateur du Blueprint peut imprimer le PDF ou partager l’accès au Blueprint. Une fois toutes les étapes terminées, le fichier qui sera importé dans notre application de développement low-code est créé. Ce processus prend plusieurs heures au lieu des semaines, mois, voire années nécessaires au processus traditionnel de conception d’applications. De plus, cela ne nécessite aucune formation particulière. L’utilisation de Blueprint est très intuitive.

Voici maintenant notre liste initiale de dossiers. Elle couvre tout, de la première notification de sinistre à la dématérialisation. Cela semble être un bon début pour notre activité de services d’assurance IARD. Chaque dossier a son propre cycle de vie (Lifecycle) et son propre modèle de données (Data Model). Chaque entreprise a ses particularités, et je vais vous montrer à quel point il est facile d’apporter des modifications à l’aide de l’IA générative et d’ajustements manuels.

Ainsi, par exemple, si notre compagnie d’assurance s’est développée pour inclure l’assurance des voiturettes de golf, je peux modifier le texte d’objectif de l’application en quelques phrases seulement. Ensuite, en cliquant sur Generate more, Blueprint alimenté par Azure AI suggère plusieurs nouvelles options. Voici plusieurs nouveaux types de dossier (Case Types) pour l’assurance de voitures de golf. Examinons l’un d’entre eux pour soumettre une demande d’indemnisation suite à un accident de voiture de golf. GenAI a généré une séquence robuste de phases (Stages), et si nous examinons les étapes (Steps), elles semblent constituer un excellent point de départ.

Supposons maintenant que chez U+, nous souhaitions recueillir des informations sur les conditions météorologiques et l’état de la chaussée dans le cadre de notre processus d’admission des déclarations de sinistres. Désormais, je peux facilement modifier le cycle de vie (Lifecycle) en sélectionnant la phase (Stage) de l’application, en ajoutant une étape (Step) et en la plaçant dans le bon ordre séquentiel. Ainsi, elle sera intégrée au workflow. Nous devons juste ajouter le champ. Nous allons donc procéder à la capture et au stockage de ces données météorologiques. Pour ce faire, nous allons accéder au modèle de données du dossier (Case Data Model). Nous le changerons peut-être plus tard en liste de sélection, mais pour l’instant, nous allons simplement en faire un champ de texte et une description suffira.

À tout moment, je peux passer en mode aperçu pour voir à quoi ce workflow pourrait ressembler pour un utilisateur final. C’est là que l’approche Center-out de Pega fait toute la différence. Nous avons conçu le dossier (Case) une seule fois et pouvons désormais le restituer sur différents canaux (Channels), qu’il s’agisse d’un utilisateur du back-office, d’un site Web mobile, d’un centre d’appels, d’un self-service ou, dans le cas présent, d’une simulation de chat en direct. Comme vous pouvez le voir, notre nouveau champ pour les données météorologiques est également déjà intégré. Et grâce à la puissance de Pega GenAI, si vous cliquez sur l’onglet Dashboard dans l’aperçu du service client, vous pouvez voir des simulations générées par l’IA de nos rapports prêts à l’emploi qui correspondent au contexte de votre Blueprint.

Pour terminer le processus Blueprint, il faut apporter quelques modifications du modèle de données (Data Model) au niveau de l’application et définir les Personas qui seront utilisés dans l’application. Une fois le processus Blueprint terminé, plusieurs options s’offrent à moi. Je peux partager l’accès au Blueprint lui-même, ou je peux le publier au format PDF à l’intention des parties prenantes qui n’utilisent pas l’outil de conception pour l’examiner. Mais ici, par exemple, je peux vous montrer à quoi ressemble le PDF, qui est assez simple et facile à comprendre. Ensuite, je peux double-cliquer sur le bouton Download pour générer le fichier contenant tous les détails de configuration Pega nécessaires à la création de notre application sur Pega Customer Service pour l’assurance.

Ensuite, nous allons nous connecter à notre environnement de développement low-code pendant que j’importe le Blueprint que nous venons de créer. Cela va nous permettre de voir où en est notre application, et de commencer à naviguer et à simuler tous les dossiers de service. On me propose deux options : créer en partant de zéro ou utiliser un Blueprint. Je vais bien sûr choisir un Blueprint et sélectionner le fichier que nous avons exporté il y a quelques minutes.

Je vais ensuite procéder à la validation des types de dossier (Case Types), des données et des Personas. Au niveau des types de dossier, je constate que les dossiers (Cases) de services prêts à l’emploi tels que la première notification de sinistre sont configurés pour être hérités, tandis que les nouveaux dossiers de service tels que l’assurance pour voitures de golf sont configurés pour être créés à partir de Blueprints, car ils sont entièrement nouveaux pour l’application Customer Service sous-jacente.

Si je clique sur Submit, App Studio créera mon application d’assurance U+. Au cours de ce processus, divers composants seront configurés, notamment les workflows, les modèles de données (Data Models), les interfaces utilisateur et les intégrations. Cela prendra environ 10 à 15 minutes. Profitons-en pour faire une petite pause ou, comme à la télévision, passons directement à la présentation du produit fini.

Voilà, la création de l’application est terminée. Maintenant que je suis dans le panneau de configuration, je peux voir les zones où les configurations par défaut ont été définies et celles où des configurations supplémentaires sont généralement nécessaires, telles que les données, les intégrations, les canaux, les groupes d’utilisateurs, etc. Examinons les différents dossiers (Cases). Nous pouvons donc voir ici plusieurs types de dossier différents. Nous pouvons voir non seulement les dossiers que nous avons créés et qui sont nouveaux pour l’assurance golf, mais aussi ceux qui sont prêts à l’emploi, tels que la première notification de sinistre. De plus, nous pouvons voir des dossiers d’infrastructure, comme les dossiers Interaction et Offer fulfilment, qui ont été créés automatiquement pendant le processus d’importation.

Chaque type de dossier (Case Type) comprend des références aux Data Objects associés qui ont déjà été configurés. Examinons de plus près la déclaration d’accident de voiture de golf. Nous pouvons donc voir ici le flux du dossier que nous avons créé dans le Blueprint, ainsi que les données du dossier, notamment les données météorologiques que nous avons ajoutées dans le Blueprint. Supposons maintenant que nous décidions de faire de ce champ de données météorologiques une liste de sélection (Picklist). Nous pouvons le faire rapidement et facilement ici, directement dans App Studio.

Ensuite, ouvrons la vue (View) pour l’étape de collecte des informations sur l’incident. Puis, ajoutons à cette vue le champ Picklist des données météorologiques, qui vient d’être créé et modifié. Maintenant, si nous voulons simuler le fonctionnement de l’application dans un cas d’usage réel, nous pouvons lancer le portail d’interaction et exécuter une démo, avec des exemples de données. Ici, nous pouvons voir le cas de Mary Johnson et la structure par défaut avec les détails de sa police.

Lorsque nous ouvrons le dossier (Case), nous pouvons procéder à la prise en charge comme s’il s’agissait d’une véritable interaction avec un client. Et nous pouvons voir ici notre nouveau champ que nous venons de transformer en liste de sélection à titre d’exemple. Nous pouvons maintenant cliquer sur Wrap up et constater que notre synthèse visuelle a bien capturé tous les détails de cette interaction, comme prévu. Nous pouvons même voir comment l’application a enregistré les workflows dans des dossiers récents, ce qui nous permet de cliquer sur l’aperçu pour accéder rapidement à certains détails.

En résumé, en l’espace de quelques minutes, nous sommes passés de la définition de notre secteur et de notre contexte fonctionnel à un logiciel entièrement opérationnel que nous pouvons commencer à tester. Grâce à Blueprint et à l’environnement de développement low-code de Pega, nous avons intégré de manière transparente les types de dossier (Case Types) nouveaux et existants, mis en place les modèles de données (Data Models) nécessaires et même effectué des simulations avec des cas d’usage réels. Cette transition rapide souligne non seulement la puissance et l’efficacité de nos outils, mais met également en évidence la rapidité avec laquelle les équipes peuvent passer du concept à l’itération en direct, pour un feedback immédiat et une amélioration continue.