Kundenservice-Anwendung im Versicherungswesen mit Pega GenAI Blueprint erstellen

Ich stelle Ihnen kurz Pega Blueprint im Zusammenhang mit dem Kundenservice für Versicherungen vor. Blueprint ist unsere sich rasch weiterentwickelnde, GenAI-gestützte Software für die Anwendungsentwicklung, die den Prozess der Konzeption und Gestaltung von Geschäftsanwendungen vereinfacht und verkürzt. Dank der Integration in unsere Unternehmensanwendungen und die Low-Code-Entwicklungsumgebung können Teams mit Blueprint Teams innerhalb von Tagen statt Monaten eine funktionierende Software bereitstellen.

Schlüpfen wir in die Rolle eines Business-Analysten bei der U+ Insurance. Wir sollen eine neue Kundenservice-Anwendung für unser Kontaktcenter und unsere Self-Service-Kanäle finden. Zuerst besuchen wir die Website Pega.com/de/blueprint , die kostenlos zugänglich ist. Der erste Schritt umfasst die Festlegung des Kontexts. Wir wählen die Versicherungsbranche, dann den Sachschäden- und Unfallbereich, den allgemeinen funktionalen Kundenservice-Kontext und schließlich den Kundenservice im Versicherungswesen aus.

Dieser Kontext führt uns nicht nur durch die Erstellung unserer GenAI-Prompts, sondern unterstützt uns auch bei der Anpassung an eine unserer bestehenden Unternehmensanwendungen, wie in der Anwendungsbeschreibung dargelegt. So können wir beides nutzen: die generativen KI-Funktionen von Blueprint und das umfassende funktionale Branchenwissen, das wir im Kundenservice für Versicherungen aufgebaut haben.

Sobald ich zum Senden auf „Submit“ klicke, erstellt Blueprint eine persönliche Design-Umgebung für mich. Diese basiert weitgehend auf dem Kundenservice für Versicherungen und ich kann die Umgebung manuell oder mit GenAI leicht erweitern und anpassen. Der Blueprint-Design-Prozess führt mich durch sieben Schritte. Der Anwendungskontext ist nun vollständig. Als Nächstes kommen die Case-Typen oder die Workflows, gefolgt vom Life-Cycle und Datenmodell für jeden Workflow, anwendungsweiten Datenobjekten (wie das Kundenprofil oder Details zur Police) und schließlich die Personas, die die Benutzer repräsentieren.

Der Blueprint Creator kann nun jederzeit die PDF-Datei ausdrucken oder den Zugriff innerhalb von Blueprint freigeben. Sind alle Schritte abgeschlossen, wird die Datei erstellt, die wir dann in unsere Low-Code-Entwicklungsanwendung importieren. Dieser Prozess dauert nur einige Stunden statt Wochen, Monate oder sogar Jahre wie beim herkömmlichen Anwendungsdesign-Prozess. Zudem gibt es keine besonderen Schulungsanforderung. Die Verwendung von Blueprint ist äußerst intuitiv.

Hier ist nun unsere vorläufige Case-Liste. Alles ist enthalten: von der ersten Schadensmeldung bis hin zur papierlosen Abwicklung. Das scheint ein solider Start für unser operatives Schaden- und Unfallversicherungsgeschäft zu sein. Jeder Case verfügt über einen eigenen Case-Life-Cycle und ein eigenes Datenmodell. Nun hat jedes Unternehmen seine Besonderheiten. Deshalb zeige ich Ihnen gleich, wie einfach Sie etwas mit generativer KI oder auch mit manuellen Anpassungen ändern können.

Wenn z. B. eine neue Versicherung für Golf-Carts hinzukommt, kann ich den Verwendungszweck mit nur wenigen Sätzen anpassen. Wenn ich dann auf „Generate more“ klicke, schlägt Blueprint einige neue Optionen vor. Blueprint läuft übrigens auf der Azure AI. Im Folgenden werden mehrere neue Case-Typen für eine Golf-Cart-Versicherung vorgeschlagen. Sehen wir uns einmal einen Case ein, wie man einen Schadensfall meldet, bei dem ein Golf-Cart beteiligt war. GenAI hat eine solide Abfolge von Stages generiert. Wenn wir uns die Steps näher ansehen, scheinen sie ein sehr guter Ausgangspunkt zu sein.

Nehmen wir nun an, dass wir bei U+ im Rahmen unseres Schadenaufnahmeprozesses auch die Wetter- und Oberflächenbedingungen erfassen möchten. Nun kann ich den Life-Cycle ganz einfach bearbeiten, indem ich die Application Stage auswähle, einen Step hinzufüge und ihn an der richtigen Stelle im Ablauf platziere. So wird der Step in den Workflow integriert. Wir müssen aber nur das Feld hinzufügen. Fahren wir fort, um diese Wetterdaten erfassen und speichern. Dafür werden wir das Case-Datenmodell aufrufen. Auch wenn wir es später möglicherweise in eine Auswahlliste umwandeln, werden wir es vorerst als Textfeld einrichten, wobei eine Beschreibung ausreicht.

Ich kann jederzeit in den Vorschau-Modus wechseln, um zu sehen, wie dieser Workflow für einen Benutzer aussehen könnte. Hier zeichnet sich der Center-out-Ansatz von Pega besonders aus. Wir haben den Case ein einziges Mal entworfen und können ihn nun über verschiedene Channels hinweg darstellen – sei es für Backoffice-Benutzer, Mobilgeräte, das Self-Service-Callcenter oder, in diesem Fall, einen Live-Chat-Simulator. Wie Sie sehen, ist unser neues Feld für Wetterdaten ebenfalls bereits integriert. Dank der Leistungsfähigkeit von Pega GenAI können Sie, wenn Sie in der Kundenservice-Vorschau auf den Tab „Dashboard“ klicken, KI-generierte Simulationen unseren vorkonfigurierten Berichten anzeigen, die auf den Kontext Ihres Blueprint abgestimmt sind.

Der Abschluss des Blueprint-Prozesses erfordert einige Eingaben auf Anwendungsebene, im Datenmodell und bei der Definition der Personas, die in der Anwendung verwendet werden sollen. Sobald der Blueprint-Prozess abgeschlossen ist, stehen mir mehrere Optionen zur Verfügung. Ich kann den Zugriff auf den Blueprint als PDF zur Überprüfung für Beteiligte freigeben, Bluetooth nicht verwenden. Ich zeige Ihnen mal, wie die PDF-Datei aussieht: recht übersichtlich und leicht verständlich. Anschließend kann ich auf die Schaltfläche „Download“ doppelklicken und so die Datei mit allen Pega-Konfigurationsdetails erstellen, die wir für die Entwicklung unserer Anwendung auf Grundlage von Pega Customer Service für das Versicherungswesen brauchen.

Als Nächstes melden wir uns bei unserer Low-Code-Entwicklungsumgebung an und ich importiere den eben erstellten Blueprint. Jetzt können wir sehen, wie weit die Fertigstellung unserer Anwendung fortgeschritten ist, und mit der Navigation und Simulation der Service-Cases beginnen. Ich kann alles von Grund auf neu erstellen oder einen Blueprint verwenden. Natürlich werde ich den Blueprint nehmen und die Datei auswählen, die wir vor wenigen Minuten exportiert haben.

Anschließend werde ich einige Validierungen von Case-Typen, Daten und Personas durchführen. Sehen wir uns die Case-Typen an. Ich stelle fest, dass die vordefinierten Service-Cases für die Vererbung konfiguriert sind. Dagegen sind die neuen Service-Cases für die Golf-Cart-Versicherung so konfiguriert, dass sie auf Basis von Blueprints erstellt werden, da sie für die zugrunde liegende CSI-Anwendung völlig neu sind.

Sobald ich auf „Submit“ klicke, erstellt App Studio meine U+-Versicherungsanwendung. Während dieses Prozesses werden verschiedene Komponenten eingerichtet, darunter Workflows, Datenmodelle, Benutzeroberflächen und Integrationen. Das dauert ungefähr 10 bis 15 Minuten. Lassen Sie uns eine kurze Pause einlegen oder, wie bei einer Kochsendung im Fernsehen, das Warten überspringen und das fertige Produkt sofort präsentieren.

Sehr gut, die Erstellung der Anwendung ist abgeschlossen. Da ich mich im Control-Panel befinde, sehe ich die Bereiche, in denen Standardkonfigurationen eingerichtet wurden und in denen in der Regel zusätzliche Konfigurationen nötig sind, wie beispielsweise Daten, Integration, Kanäle, Benutzergruppen und mehr. Lassen Sie uns die verschiedenen Cases näher betrachten. Hier sehen wir also verschiedene Case-Typen. Wir können nicht nur die von uns erstellten Cases einsehen, die für die Golf-Versicherung neu sind, sondern auch die vordefinierten Cases, wie beispielsweise die zuerst zu erfolgende Schadensmeldung. Darüber hinaus gibt es Infrastruktur-Cases wie „Interaction“ oder den Case „Offer fulfillment“ für die Angebotsumsetzung, die beim Importieren automatisch erstellt wurden.

Jeder Case enthält Referenzierungen auf bereits eingerichtete, unterstützende Datenobjekte. Sehen wir uns die Schadensmeldung bei Unfällen mit Golf-Carts genauer untersuchen. Hier können wir den Case-Ablauf anzeigen, den wir mit Blueprint erstellt haben. Wir können auch die Daten zum Case einsehen, einschließlich der Wetterdaten, die wir dem Blueprint hinzugefügt haben. Nehmen wir nun an, wir möchten das Wetterdaten-Feld in eine Picklist zum Auswählen umwandeln. Wir können dies hier direkt in App Studio schnell und einfach erledigen.

Als Nächstes öffnen wir die Ansicht für den Step, mit dem wir Informationen zum Vorfall sammeln. Fügen wir nun das neu erstellte und soeben geänderte Picklist-Feld für die Wetterangaben zu dieser Ansicht hinzu. Wenn wir nun simulieren möchten, wie die App in einem realen Case funktioniert, können wir das Interaction Portal starten und ein Demo-Szenario mit Beispieldaten ausführen. Hier sehen wir den Datensatz von Mary Johnson und die Standardzusammenfassung mit ihren Versicherungsdetails.

Wenn wir den Case öffnen, können wir die Aufnahme wie bei einer echten Interaktion mit einem Kunden durchführen. Außerdem sehen wir hier unser neues Feld, das wir gerade zur Veranschaulichung in eine Picklist umgewandelt haben. Nun können wir auf „Wrap up“ klicken und feststellen, dass unsere visuelle Zusammenfassung alle Details dieser Interaktion wie erwartet erfasst hat. Zudem können wir sehen, wie die Anwendung die Workflows in aktuellen Cases protokolliert hat, und durch Klicken auf die Vorschau schnell auf einige Details zugreifen.

Zusammenfassend lässt sich sagen, dass wir innerhalb weniger Minuten von der Definition unseres Branchen- und Funktionskontexts zu einer voll funktionsfähigen Software gelangt sind, mit der wir nun experimentieren können. Dank Blueprint und der Low-Code-Entwicklungsumgebung von Pega haben wir neue und bestehende Cases nahtlos integriert, die erforderlichen Datenmodelle eingerichtet und sogar Simulationen mit realen Cases durchgeführt. Das Tempo, in dem wir das umgesetzt haben, unterstreicht nicht nur die Leistungsfähigkeit und Effizienz unserer Tools, sondern verdeutlicht auch, wie schnell Teams vom Konzept zur Live-Iteration gelangen können, was sofortiges Feedback und kontinuierliche Verbesserungen ermöglicht.