– Data Analytics

So gelingt Versicherern der Einstieg ins High-Performance Pricing

3 Tipps, worauf Versicherer beim Set-up achten sollten

Share on facebook
Share on twitter
Share on linkedin
Share on email
Kunden über reichweitenstarke Portale zu erreichen, ist im Versicherungsgeschäft längst zur wichtigen Optimierungsdisziplin geworden

ABSTRACT

Wie der Aggregator Rating-Kompetenz zum Muss erhebt

Nähe zu potenziellen Neukunden auf reichweitenstarken Portalen herzustellen, ist längst komplizierter, komplexer – und eine eigene Optimierungsdisziplin geworden. Nennen wir sie High-Performance Pricing. Höchste Zeit, dass sich Versicherer diese Disziplin vollständig erschließen – vom Konzept bis hin zur Realisierung. Unsere Experten Johannes Gronewald und Ali Rahimi skizzieren, worauf es hier ankommt.

An Plattformkonzepten orientieren

Plattform-Aggregatoren, die Marktangebote screenen, den Best-Price verkünden und idealerweise die Brücke zum ureigentlichen Policen-Anbieter schlagen, gehören im Versicherungsgeschäft längst zum State of the Art. End-to-End-integrierte Plattformen und Marktplätze machen im Zuge der digitalen Transformation schon lange auch vor Versicherern nicht mehr halt. Das bedeutet einerseits: Die Unternehmen erhalten über Check24, Verivox und Co. Reichweite und Leads – aber nur, wenn sie a) nach den Regeln der Plattformanbieter spielen. Und wenn sie b) transparente Angebote und Policen zu einem mindestens wettbewerbsfähigen Preis anbieten. Das bedeutet andererseits, dass Angebote c) nach den Algorithmen der Plattformbetreiber gerankt werden und Versicherungsanbieter d) nicht mehr nur bei Standardprodukten extrem gefordert sind.

Versicherungsbranche im Wandel: Warum kein Anbieter mehr um High-Performance Pricing herumkommt

Die zunehmende Markttransparenz durch digitale Transformation treibt die junge Disziplin High-Performance Pricing voran. Aggregatoren-Plattformen sorgen dafür, dass der Wettbewerbsdruck steigt. Zumindest Standard-Versicherungsprodukte sind über Portale wie Check24, Verivox und Co. bei Preis und Leistung eins zu eins vergleichbar. Versicherer, deren Rating Engines schneller auf Anfragen über die Portale reagieren, haben obendrein eine bessere Chance, mit eigenen Angeboten prominent gelistet zu werden. Gegen Werbegelder lässt sich das organische Ranking weiter verbessern. Zudem bieten die Vergleichsportale auch Dienste zur Performance-Analyse und zur Einrichtung von Schattentarifbüchern an. Letztere dienen dazu, die Prämienberechnung zu optimieren.

Schnell bedeutet, zumindest gegenüber Endverbrauchern, binnen Sekundenbruchteilen Antworten an die Kundenplattformen auszuliefern – ähnlich schnell wie im Hochfrequenzhandel an der Börse. Lediglich Produkt- und Service-Innovationen werden im Angebots-Ranking gegenüber Endkunden indirekt honoriert. Bei Versicherungen in den Bereichen private Haftpflicht, Kfz oder Hausrat lassen sich Produktinnovationen kaum noch realisieren. Und verkürzte Kündigungsfristen, Exklusivdeckungen, Telematik etc. tragen längst keine Alleinstellungsmerkmale mehr in sich. Der Preis in Kombination mit der Geschwindigkeit hingegen schon. Schwierig gestaltet sich indes der Zugang zu den vielschichtigen Zielgruppen. Vor diesem Hintergrund lautet die technische Frage:

Wie gelingt es Versicherern, die entsprechenden Rating-Instanzen auf- und sicher auszubauen?

Deployment-Ort

  • On Premise
  • Hybrid
  • Private Cloud
  • Public Cloud
  • Serverless

Deployment-Rhythmus

  • CI (Deployment ist bis zur Testebene automatisiert, wird manuell in Produktion gegeben)
  • CD (Deployment ist bis in Produktion vollständig automatisiert, freigegebene Änderungen werden vollautomatisiert Code-technisch gebaut, getestet, integriert und sind dann für Endkunden binnen Minuten nach Änderung verfügbar)

Verfügbarkeit/Änderbarkeit

  • 24/7
  • Preiselastizität (etwa Daily Pricing)

Verortung des Ratings
(relevant für Skalierung)

  • Im Bestandsführungssystem
  • Zusätzliche Instanzen des Bestandsführungssystems (High Volume Quoting: HVQ)
  • Extern gekauft (eigenständige Anwendung)
  • Extern selbst entwickelt (eigenständige Anwendung)

Nicht alle Branchen/Sparten haben dieselben Performance-Anforderungen

  • Kfz-, private Sach-/Haftpflichtversicherungen: Hohe Performance-Anforderungen (deutlich unterhalb 1 Sekunde Antwortzeit)
  • Firmen-/Gewerbeversicherung: Weniger zeitkritisch

Anbindung/Schnittstelle
(je nach Anwendung verschiedene Anforderungen)

  • BiPRO für Aggregatoren
  • BiPRO für Makler mit Software
  • Custom für Bestandsführungssystem
  • Custom für Aggregatoren
  • Custom für Serverless

Welche Anforderungen Versicherern durch High-Performance Pricing entstehen

Damit Versicherer ihre Wettbewerbsfähigkeit stetig verbessern und ausbauen, müssen sie die Customer Journey entlang des gesamten meist direkt. Auf dieser Grundlage lassen sich Marktangebote sinnvoll platzieren und gegebenenfalls nachschärfen: Die dem Rating nachgelagerten Analysen erzeugen Faktoren, die das Rating einige Tage oder Wochen später modifizieren. Findige Versicherer schaffen hiermit beträchtliches Potenzial, um sich vom Wettbewerb zu unterscheiden.

Der Preis für eine bestimmte Versicherung ist für viele Kunden das ausschlaggebende Kaufkriterium. Denn: Viele Leistungen sind, etwa bei Kfz-Versicherungen, bis hin zum Marderbissschutz vergleichbar.

Kundenbewertungen, Warenkorbabbrüche und Stornoquoten werden zunehmend das Rating beeinflussen​

Hingegen spielt das gewählte Rahmenpaket, das sinnvollerweise direkt mit dem Abschluss einer Police abgedeckt ist, auch weiterhin eine wichtige Rolle. Mangelt es bei der Assekuranz an der Kulanz (etwa nach einem Verkehrsunfall), den Versicherungsnehmer hilfsbereit zu unterstützen, leidet in der Folge die allgemeine Kundenzufriedenheit. Dies schlägt sich langfristig auf die Kundenbewertungs-Ergebnisse bei den Aggregatoren nieder. Weitere Rating-Faktoren neben Preis, Zielgruppennutzen und Kundenzufriedenheit ist die Stornoquote. Perspektivisch wird auch der Warenkorbabbruch einen wichtigeren Einfluss auf das Rating nehmen. Daher tun Versicherungsunternehmen gut daran, den Antragsprozess attraktiver zu gestalten, um Kundenattraktivität, Servicequalität und Convenience zu optimieren. Eine dadurch verbesserte Kundenbindung lässt sich anhand von Kündiger- und Weiterempfehlungsquoten messen.

Lösungsdesign für ein skalierbares Rating-Modul: Wie Versicherungen Analysen durchführen sollten – ein Beispiel

Angenommen eine Versicherung nutzt als Kernsystem eine aktuelle Guidewire InsuranceSuite und hat festgelegt, keine High-Volume-Quoting-Mechanik (HVQ) des PolicyCenters einzusetzen: Daraus ergibt sich, dass die Preisberechnung – das Rating – der gesamten Systemlandschaft modular zugänglich sein muss: Benötigt das Kernsystem eine Preisauskunft, wird diese nicht direkt im PolicyCenter ermittelt. Stattdessen sendet sie der Aggregator an das externe Rating-Modul. Empfänger ist eine spezielle, auf Performance optimierte Rating Engine (zum Beispiel eine von IKOR entwickelte, eigenständige Technologie). Externe Preisanfragen von Aggregatoren, Maklern und möglicherweise auch Endkunden werden ebenfalls an das Rating-Modul gesandt.

Damit Produktanpassungen im Kernsystem auch dem Rating-Modul zugänglich sind, muss entweder eine Verbindung zwischen Rating-Server und Kernsystem bestehen. Oder der Versicherer betreibt den Rating-Server komplett unabhängig vom Kernsystem. Allerdings ist der Aufwand, jede Produktänderung manuell in das Rating-Modul zu überspielen, bei dieser redundanten Variante in der Implementierung und Wartung sehr hoch. Es entstehen potenzielle weitere Fehlerquellen und der Time-to-Market verlängert sich.

Eine Produktanpassung im Bereich Kfz-Versicherung könnte beispielsweise eine hinzugefügte neue Deckung eines Tarifs sein – wie bei einer künftig relevanten Zusatzversicherung für autonomes Fahren. Ein solcher Vorgang muss im ersten Schritt mit dem externen Rating-Modul abgeglichen werden. Der folgende Schritt wägt wiederum ab, wie der Versicherer die Zugriffsmethode auf benötigte Rating-relevante Daten behandeln soll: direkter Zugriff aus dem Speicher (Cache) oder Abruf der benötigten Daten aus einer internen oder externen Datenquelle (Datenbank, Data Lake etc.)

Versicherungsunternehmen sollten Rating-Routinen dazu dynamisch festlegen. Diese regeln, in welcher Reihenfolge Rechenschritte erfolgen, um eine bestimmte Prämie zu errechnen (etwa bei einer Haftpflicht-Basisprämie). So gewährleisten sie eine hohe Wiederverwertbarkeit. Zudem sollten sie abwägen, ob sie bei einer Preisanfrage eine einzige Preisvariation oder gleich mehrere berechnen wollen. Parameter wie Zahlweise (monatlich, halb-jährlich, jährlich) lassen sich beispielsweise in einem Array einspielen. Über das Array gibt die Rating-Instanz auf Grundlage dieses Parameters jede angeforderte Preisvariation aus.

Versicherer setzen dieses Vorgehen ein, um auf einer Angebotsseite mehrere vorberechnete Preisausprägungen direkt darzustellen. Um für künftige Anwendungsfälle aufgestellt zu sein, sollte jede Performance-Abwägung genauestens überlegt sein:

Tipps

Mit diesen 3 Tipps steigen Versicherer ins High-Performance Pricing ein

Der Start von Versicherungen ins High-Performance Pricing erfordert Ideen, Konzepte und Realisierungen. Diese drei Tipps ebnen Organisationen den Weg:

1. So legen Sie die strategische Basis für High-Performance Pricing

Versicherer müssen eingangs klären, wofür sie ihren Rating-Server tatsächlich einsetzen wollen: Welche Nutzergruppe wollen sie bedienen? Mit welchem Volumen können und müssen sie rechnen? Als sicherer gilt die Strategie, auf den Plattformen zuerst in einen Teilbereich des Markts einzusteigen sowie Funktionalität und Resonanz in kleineren Etappen zu analysieren, auszuwerten und zu verbessern. Hintergrund: Vergleichsportale stellen – trotz großer Tarifvariationen – die eigentlichen Leistungsmerkmale zwischen allen Anbietern recht genau gegenüber – ein riesiges Lernumfeld für Assekuranzen. So gelingt es ihnen, ihr Ranking anhand des kumulierten Gesamtangebots aufzuzeigen, zu verbessern und ihr Wissen auf andere Sparten auszurollen. Aus diesem Grund sollten Versicherer analysieren, ob sie in bestimmten Kategorien, etwa bei Telematik-Tarifen, ein besseres Leistungsangebot erzeugen, um in Ranking weiter vorn zu landen.

2. Verhalten zwischen Kernsystem und Rating-Instanz abstimmen: So planen Sie Ihre Systemarchitektur

Treffen Sie Ihre konzeptionelle Entscheidung, wie Kernsystem (Bestandssystem) und Rating-Modul künftig zusammenarbeiten: Eine weitreichende Einbettung des Ratings in das Bestandssystem sollten Versicherer allerdings möglichst vermeiden. Ansonsten steigt die Gefahr von Angriffen von außen auf sensible Kundendaten (Policen-Information, Kundendaten). Stattdessen sollten die Organisationen abstimmen, mit welchen Rechten und Privilegien ihr Rating-Server mit dem Kernsystem kommunizieren darf. Die valideste Variante besteht darin, die Rating-Instanz komplett vom Kernsystem (und damit das Kernsystem vom direkten Internetzugriff) abzuschotten.

Wie auch immer diese Entscheidung ausfällt, sollten Produktinformationen zwischen Kernsystem und Rating-Modul synchronisierbar sein. Das vermeidet zusätzlichen Implementierungsaufwand innerhalb des Ratings. Produktänderungen bzw. Produktanpassungen müssen dann entweder über eine automatische Dateneinspielung erfolgen oder – je nach Anforderung – manuell ins System gelangen. Aber Vorsicht: Schlechte Umsetzung führt schnell zu doppeltem Arbeitsaufwand – und zu einem verlangsamten Time-to-Market.

Um bei der Preisberechnung eine durchweg ausgezeichnete Performance abzuliefern, sollten Versicherer alle benötigten Rating-relevanten Daten im Speicher (Cache) der jeweiligen Server-Instanz vorhalten. Der Königsweg beim Hochfahren des Rating-Moduls besteht darin, alle benötigten Daten wie Ratebooks (Tarifbücher), Rating-Faktoren und weitere Rating-relevante Daten in den Cache zu laden. Das verbessert die initialen Zugriffszeiten auf diese Daten. Und es lassen sich damit sehr gute Durchschnittszeiten zur Berechnung einer Prämie erzielen. Hingegen sinkt die Performance, wenn weitere Daten aus internen oder externen Datenbanktabellen abzurufen sind. Die Performance-Anforderungen sind ausschlaggebend für den Spielraum einer Preisanfrage.

Auch die Entscheidung, wie das Rating-Modul gehostet werden soll, ist ein Gradmesser für Performance: Möchte ein Versicherer seine Anwendung selbst On Premise betreiben, muss er saisonale Effekte über das gesamte Jahr hinweg betrachten. Dazu gehören beispielsweise auch Phasen, zu denen Nutzer vermehrt Preisanfragen zu einem besseren Tarif im Folgejahr stellen – Zeiten für Lastspitzen. Während ein On-Premise-Konstrukt meist ein statisches Server-Set-up nutzt, das zu jeder Zeit die Höchstleistung erbringen muss, ermöglichen Cloud-Lösungen eine dynamische Skalierung. Lastspitzen lassen sich so gut abfedern. Dasselbe gilt für selbstgehostete Cloud-Lösungen. Auch sie ermöglichen eine umfassende Skalierung der Rechen-Ressourcen im Bedarfsfall.

3. Kontinuität einplanen: So wägen Sie Aufwand und Sicherheit bei Wartung und Support ab

Sobald der Rating-Server aufgesetzt ist, muss dieser kontinuierlich gewartet und erweitert werden. Dazu benötigen Versicherungsunternehmen ein Konzept, wie neue oder abgeänderte Produkte ins System zu integrieren sind. Meist werden dazu mehrmals im Jahr neue Ratebooks mit neuen Tarifversionen eingespielt. Das ermöglicht es den Unternehmen, den Markt mit neuen Versicherungsmöglichkeiten oder vereinfachten Preiszusammensetzungen zu versorgen.

Eine Daily-Pricing-Funktion hilft dabei, täglich oder gar stündlich auf Preisänderungen am Markt zu reagieren. Die eigentlichen Tarifversionen bleiben dabei jedoch unangetastet. Stattdessen berücksichtigen die Unternehmen im einfachsten Fall einen bestimmten Rabatt oder eine Erhöhung auf den Gesamtpreis.

Das Hosting von Rating Engines in der einfachen Version arbeitet On Premise. Dennoch empfiehlt es sich, dass Versicherungsunternehmen auf eine Hybridversion setzen – eine Mischung aus On-Premise- plus Cloud-Lösung in Spitzenzeiten – für die optimale Skalierfähigkeit. Noch schneller arbeiten sogenannte Hyperscaler wie AWS oder Microsoft Azure. Am schnellsten sind Assekuranzen indes per Serverless Computing, wenn sie Aggregatoren direkt an eine Cloud-Funktion beim Hyperscaler anbinden. Dann ist auch in puncto KI-Nutzung bei optimaler Geschwindigkeit viel möglich.

Share on facebook
Share on twitter
Share on linkedin
Share on email

Ansprechpartner

Ali Rahimi ist Chief Product Owner bei IKOR Finsure

Ali Rahimi

Chief Product Owner im Dock Finsure
finsure@ikor.one
+49 40 8199442-0

Johannes Gronewald ist Senior Architect bei IKOR Finsure

Johannes Gronewald

Senior Architekt im Dock Finsure
finsure@ikor.one
+49 40 8199442-0

Empfehlungen