Makler wollen sich nicht einloggen

Das Maklerportal als Konzept beruht auf einer Annahme, die schon beim Entwurf fragwürdig war: dass Makler bereit sind, ihre eigene Arbeitsumgebung für jeden Versicherer separat zu verlassen, sich in ein Portal einzuloggen, dort Daten einzugeben, die sie längst in ihrem Maklerverwaltungsprogramm haben, und anschließend zurückzukehren. Diese Annahme war vor zwanzig Jahren zweifelhaft. Heute ist sie widerlegt.

Der Makler arbeitet in einem System, seinem Maklerverwaltungsprogramm, in dem alle Kunden, Verträge und Vorgänge zusammenlaufen. Jeder Schritt, der ihn aus diesem System herauszwingt, ist ein Bruch. Bei einer Handvoll Versicherern ist das noch erträglich, bei zwanzig oder dreißig wird es zur täglichen Reibung, die niemand mehr akzeptiert. Die Folge ist eine Portallandschaft, die kaum genutzt und schlecht bewertet wird.

Login-First gegen API-First

Hinter der Frage steckt ein grundsätzlicher Architekturgegensatz. Das Portal denkt Login-First: Der Makler kommt zum Versicherer, loggt sich ein, holt sich seine Information. Die Zukunft denkt API-First: Die Daten kommen zum Makler, direkt in sein Verwaltungsprogramm, ohne dass er irgendwohin gehen muss. Der Unterschied ist nicht kosmetisch, er kehrt die Richtung des Datenflusses um.

API-First bedeutet, dass der Versicherer seine Funktionen und Daten über standardisierte Schnittstellen bereitstellt, die das Maklerverwaltungsprogramm direkt anspricht. Der Makler sieht kein Portal mehr, er sieht seine gewohnte Oberfläche, in der die Daten des Versicherers einfach vorhanden sind. Das Portal verschwindet nicht unbedingt ganz, aber es verliert seine zentrale Rolle, weil die eigentliche Arbeit woanders stattfindet.

Wohin der Markt zeigt

Die Richtung ist längst sichtbar. Die BiPRO-Normen liefern die standardisierte Grundlage für genau diesen Datenfluss: Norm 420 für Tarifierung, Angebot und Antrag, Norm 430 als gesellschaftsübergreifendes Maklerpostfach, Norm 490 für die Übermittlung des Maklermandats, die Normenreihe 500 für Bestands- und Vertragsauskünfte. Zusammen ermöglichen sie, dass Geschäftsvorfälle direkt zwischen Versicherer und Maklerverwaltungsprogramm ablaufen, ohne den Umweg über ein Portal.

Anbieter wie Insurgo und andere Spezialisten für Maklerpostfächer zeigen, wie das in der Praxis aussieht: Dokumente und Daten landen automatisch im Verwaltungsprogramm, zugeordnet und verarbeitet, ohne dass der Makler sich irgendwo einloggen muss. Der Trend zu API-First und zur direkten Anbindung an das Maklerverwaltungsprogramm ist damit keine Vision mehr, sondern eine Bewegung, die bereits läuft.

Warum Versicherer den Wechsel scheuen

Wenn die Richtung so klar ist, warum investieren viele Versicherer weiter in ihr Portal? Der Grund ist meist nicht technische Unkenntnis, sondern Bequemlichkeit und Kontrolle. Das Portal ist die eigene Plattform, mit eigenem Auftritt, eigener Datenhoheit und der Möglichkeit, dem Makler die eigenen Inhalte zu präsentieren. Der Wechsel zu API-First bedeutet, einen Teil dieser Sichtbarkeit aufzugeben, weil der Makler die Daten nutzt, ohne das Portal des Versicherers je zu sehen.

Diese Sorge ist verständlich, aber sie verkennt die Realität. Ein Portal, das kaum genutzt und schlecht bewertet wird, liefert auch keine Sichtbarkeit. Die vermeintliche Kontrolle über den Auftritt ist wertlos, wenn der Makler das Portal meidet. Wer die Sichtbarkeit über das Portal verteidigt, verteidigt einen Kanal, den die Nutzer ohnehin nicht mögen.

Wer jetzt noch ins Portal investiert, investiert ins Faxgerät

Die Pointe ist unbequem, aber sie trifft den Kern. Ein Versicherer, der heute viel Geld in ein neues, schöneres Portal steckt, ohne die direkte Datenanbindung an das Maklerverwaltungsprogramm zu lösen, investiert in eine Technologie, deren Konzept überholt ist. Das Portal wird vielleicht schöner, aber es bleibt der Umweg, den der Makler nicht gehen will.

Das heißt nicht, dass das Portal über Nacht verschwindet. Es heißt, dass die Investitionsschwerpunkte sich verschieben müssen. Der Euro, der heute in eine neue Portalfunktion fließt, wäre in einer sauberen Schnittstelle, die Daten direkt ins Verwaltungsprogramm des Maklers liefert, besser angelegt. Diese Schnittstelle ist es, die der Makler honoriert, nicht das nächste Portal-Update.

Der Übergang muss nicht abrupt sein

Die Umstellung von Login-First auf API-First ist kein Schalter, den man umlegt, sondern ein Übergang, der sich gestalten lässt. In der ersten Phase laufen Portal und Schnittstellen parallel: Wer das Portal nutzen will, kann es weiter tun, aber die Daten stehen zugleich über Schnittstellen bereit, sodass die Maklerverwaltungsprogramme sie direkt abholen können. So entsteht kein Bruch, und kein Makler wird gezwungen, seine gewohnte Arbeitsweise über Nacht zu ändern.

Mit der Zeit verschiebt sich das Gewicht von selbst. Je besser die Schnittstellen funktionieren, desto seltener wird das Portal gebraucht, bis es schließlich nur noch für Ausnahmefälle dient. Dieser organische Übergang ist für regulierte, gewachsene Häuser der realistische Weg, weil er die Investitionen schützt und das Risiko begrenzt, ohne die Richtung zu verwässern.

Die Datenqualität bleibt die Bedingung

So überzeugend API-First ist, es löst ein Problem nicht von allein: die Datenqualität. Eine Schnittstelle, die fehlerhafte oder unvollständige Daten liefert, ist kein Fortschritt gegenüber einem Portal mit denselben Daten. Der Standard regelt nur den Transport, nicht den Inhalt. Entscheidend bleibt, dass der Versicherer als Datenlieferant vollständige, korrekte und einheitliche Daten bereitstellt.

Das verschiebt einen Teil der Arbeit von der Schnittstelle zur Datenpflege im eigenen Haus. Ein Versicherer, der API-First ernst meint, muss zugleich seine Datenqualität sichern, sonst exportiert er seine internen Datenprobleme nur schneller in das System des Maklers. Die beste Schnittstelle nützt wenig, wenn das, was durch sie fließt, nicht stimmt.

Was das für die Wettbewerbsposition bedeutet

Am Ende ist API-First eine Frage der Wettbewerbsposition im Maklervertrieb. Der Makler lenkt sein Geschäft dorthin, wo die Zusammenarbeit am reibungslosesten ist, und nichts ist reibungsloser, als wenn die Daten des Versicherers einfach in seinem Verwaltungsprogramm erscheinen, ohne dass er etwas tun muss. Ein Versicherer, der das bietet, macht sich zum bevorzugten Partner, während der Portalbetreiber die Reibung beim Makler belässt.

Diese Positionierung wird mit jedem Jahr wichtiger, weil die Erwartung der Makler steigt und der Aufwand, mit vielen Versicherern zu arbeiten, ohnehin hoch ist. Wer die direkte Anbindung früh und gut anbietet, sichert sich einen Vorsprung, den ein nachziehender Wettbewerber nur schwer aufholt. Die Entscheidung für API-First ist damit keine reine Technikfrage, sondern eine strategische Weichenstellung im Vertrieb.

Der Maßstab sind die Erwartungen aus anderen Branchen

Die Ungeduld der Makler speist sich nicht aus der Versicherungswelt allein, sondern aus ihrer Erfahrung als Nutzer überall sonst. Wer gewohnt ist, dass Daten zwischen seinen Anwendungen automatisch fließen, akzeptiert beim Versicherer nicht mehr den manuellen Übertrag aus einem Portal. Der Maßstab für gute Anbindung wird außerhalb der Branche gesetzt, und an diesem Maßstab wirken Login-First-Portale zunehmend wie ein Relikt.

Versicherer, die das ignorieren, messen sich am falschen Vergleich. Sie schauen auf andere Versicherer und sehen, dass alle ein Portal haben, und fühlen sich bestätigt. Der Makler aber vergleicht nicht mit anderen Versicherern, sondern mit dem reibungslosen Datenfluss, den er aus dem Rest seines digitalen Lebens kennt. An diesem Maßstab verliert jedes Portal.

Die Richtung ist entschieden, das Tempo nicht

Ob die Zukunft API-First ist, steht nicht mehr ernsthaft zur Debatte, die Bewegung läuft und die Erwartung der Makler treibt sie. Offen ist nur, welcher Versicherer wie schnell folgt. Wer früh und konsequent auf die direkte Anbindung setzt, gewinnt einen Vorsprung im Maklervertrieb, den ein späteres Nachziehen kaum aufholt. Das Tempo ist damit die eigentliche strategische Variable.

Was Versicherer jetzt tun sollten

Der erste Schritt ist eine ehrliche Bewertung des eigenen Portals. Wird es genutzt, wird es empfohlen, oder ist es ein teurer Kanal, den die Makler meiden? Der zweite Schritt ist die Priorisierung der Schnittstellen: Welche Geschäftsvorfälle lassen sich über standardisierte Normen direkt in das Maklerverwaltungsprogramm bringen, und welche davon haben für den Makler den größten Nutzen?

Wir helfen Ihnen, Ihre Maklerschnittstelle von Login-First auf API-First zu drehen, sodass Ihre Daten dorthin gelangen, wo der Makler arbeitet, und Ihre Investitionen in die Anbindung statt in ein überholtes Portalkonzept fließen. Buchen Sie eine Sprechstunde.