Der Arbeitsalltag eines Vertriebsteams in einer Versicherung hängt zum größten Teil von einem einzigen Werkzeug ab: vom Vertriebsportal, in dem Angebote erstellt, Verträge abgeschlossen und Kundendaten verwaltet werden. Ist dieses Portal veraltet, langsam oder umständlich zu bedienen, ist das nicht bloß ein IT-Problem — es bremst den Vertrieb unmittelbar und verschlechtert auch das Kundenerlebnis. Die Wirkung bleibt dabei nicht auf ein Team beschränkt: Kundenservice, Schadenabwicklung und oft auch das Marketing spüren die Folgen eines langsamen Systems.
Bei vielen Versicherungen ist dieses Portal über Jahre, teils über ein bis zwei Jahrzehnte in seine heutige Form hineingewachsen: ursprünglich für eine engere Aufgabe gebaut, dann Schritt für Schritt erweitert, geflickt, mit neuen Funktionen überbaut — ohne dass das Fundament je neu gedacht worden wäre. Das Ergebnis ist ein System, das funktioniert, aber immer schwerfälliger, immer langsamer und mit immer mehr Handarbeit verbunden ist.
Dieses organische, aber ungeplante Wachstum zeigt sich in irgendeiner Form bei fast jeder Versicherung mit langer Geschichte. Über die Jahre haben sich die Produkte verändert, die regulatorischen Vorgaben, die Vertriebskanäle — das darunterliegende System hat mit diesen Veränderungen aber oft nicht Schritt gehalten, sondern wurde bloß immer komplexer und immer schwerer durchschaubar.
Welche konkreten Probleme verursacht ein veraltetes Vertriebsportal?
Die Angebotserstellung ist langsam, weil die Vertriebsmitarbeiterinnen und -mitarbeiter Daten in mehreren getrennten Modulen oder sogar in unterschiedlichen Systemen erfassen müssen, bevor ein Angebot fertig ist. Die Kundendaten liegen verstreut, was bedeutet: Eine einfache Frage — etwa ob eine Kundin bereits ein anderes Produkt bei der Versicherung hat — erfordert oft den Blick in mehrere Oberflächen.
Ein drittes, häufig unterschätztes Problem: Fehlerhafte oder unvollständige Daten wirken sich bis in die späteren Abschnitte des Prozesses aus — ein bei der Angebotserstellung falsch erfasstes Kundendatum sorgt später, im Moment der Schadenabwicklung oder der Verlängerung, für Stockungen, wenn die Korrektur bereits deutlich aufwendiger und teurer ist. Dazu kommt die veraltete Benutzeroberfläche, und das ist nicht nur eine ästhetische Frage: Eine unübersichtliche, unlogisch aufgebaute Oberfläche bremst die Arbeit und erhöht die Fehleranfälligkeit. Auch die Einschulung neuer Mitarbeiterinnen und Mitarbeiter dauert in einem solchen System deutlich länger, weil die Logik nicht intuitiv ist, sondern aus einer über Jahre angewachsenen Reihe von Ausnahmen und Behelfslösungen besteht.
All das führt dazu, dass ein Angebot, das sich in einem modernen System in wenigen Minuten erstellen ließe, in der Praxis einen halben Tag in Anspruch nehmen kann — und jede dieser Verzögerungen ist ein Moment, in dem die Kundin womöglich woanders abschließt.
Dazu kommt ein weniger greifbarer, aber genauso realer Kostenfaktor: die Motivation im Vertrieb. Wenn ein großer Teil des Arbeitstags aus Administration und dem Navigieren zwischen Systemen besteht, statt aus der Arbeit mit Kundinnen und Kunden, wirkt sich das langfristig auch auf das Engagement und die Leistung des Teams aus.
Eine konkrete Referenz
Bei einer ungarischen Versicherungsgesellschaft sind wir genau auf dieses Problem gestoßen: Ein veraltetes, unterentwickeltes Vertriebsportal hat die Vertriebsprozesse gebremst und die Kundenbetreuung erschwert. Im Projekt haben wir das Portal mit einer zeitgemäßen Benutzeroberfläche, neuen Funktionen und einer geordneteren Datenhaltung ausgestattet — und damit die tägliche Arbeit des Vertriebsteams direkt unterstützt. Das Projekt hat rund ein Jahr gedauert; die genaue Dauer hängt vom Umfang und von der Komplexität ab.
Warum reicht es nicht, die Oberfläche bloß „schöner zu machen“?
Ein verbreiteter Irrtum ist, dass das Problem eines veralteten Portals rein optisch sei — dass es genügt, ein moderneres Design über das bestehende System zu legen, und die Sache sei erledigt. In Wahrheit liegt das Problem in den meisten Fällen tiefer: in der Datenstruktur und in der Logik des Systems. Wenn Kundendaten, Produktdaten und Vertragsdaten verstreut und schlecht miteinander verknüpft vorliegen, bleibt hinter einer neuen Oberfläche dieselbe langsame, fehleranfällige Funktionsweise bestehen.
Deshalb beginnt jedes solche Projekt mit einer Discovery- und Anforderungsphase, in der wir nicht nur die Oberfläche, sondern auch die dahinterliegende Datenstruktur und die Prozesse gründlich erheben. Erst auf dieser Grundlage lässt sich entscheiden, ob eine Erneuerung der Oberfläche ausreicht oder ob ein tiefergehender Umbau auf Datenebene nötig ist.
Diese Erhebung bringt oft überraschende Erkenntnisse: In vielen Fällen stellt sich heraus, dass die von den Nutzerinnen und Nutzern am meisten gehasste Funktion gar kein technisches Problem ist, sondern der Abdruck einer Geschäftsentscheidung von vor Jahren, die nie jemand hinterfragt hat. Eine gründliche Discovery-Phase bringt auch diese verborgenen, historisch gewachsenen Beschränkungen ans Licht — nicht nur die sichtbaren technischen Mängel.
Was kostet das Aufschieben ein Vertriebsteam?
Wenn ein Vertriebsportal die Arbeit bremst, taucht der Kostenfaktor selten als einzelner Posten in einem Budget auf — und schlägt trotzdem an mehreren Stellen durch. Der Vertrieb kann in derselben Zeit weniger Angebote erstellen, was das Umsatzpotenzial unmittelbar begrenzt. Nachträgliche Korrekturen aufgrund fehlerhafter oder ungenauer Daten bedeuten zusätzlichen administrativen Aufwand. Und der vielleicht am schwersten zu beziffernde, zugleich realste Effekt: Jene Kundinnen und Kunden, die wegen des langsamen Prozesses woanders abschließen, erscheinen in keiner Statistik — sie fehlen einfach in den Umsatzzahlen.
Demgegenüber sind die Kosten eines Modernisierungsprojekts, auch wenn sie anfangs beträchtlich wirken, eine konkrete, planbare Investition, deren Rückfluss über den schnelleren, genaueren Vertriebsprozess mit der Zeit messbar wird.
Wie ist so ein Projekt aufgebaut?
Der Prozess startet mit Discovery und Anforderungserhebung, danach folgt der Entwurf der Lösung — beratend, immer mit dem Vorschlag des kosteneffizientesten Wegs, der das Problem wirklich löst. Darauf folgt die Entwicklung (typischerweise Angular im Frontend, Java im Backend, wobei sich die Technologie flexibel am jeweiligen Projekt orientiert), danach das Testen und schließlich Übergabe und Dokumentation.
Wichtig ist dabei: Wir wägen jede Entscheidung im Gleichgewicht zwischen Kosteneffizienz und funktionaler Qualität ab — wir bauen nicht einfach das, worum wir zuerst gebeten werden, sondern beraten dazu, was in der jeweiligen Situation die beste Lösung ist.
Warum zählt das auch für das Kundenerlebnis?
Ein Vertriebsportal ist nicht nur ein Werkzeug für interne Mitarbeiterinnen und Mitarbeiter — es bestimmt indirekt auch das Kundenerlebnis. Wenn ein Angebot schnell und korrekt erstellt wird, bekommt die Kundin eine schnellere, professionellere Betreuung. Arbeitet das System langsam oder mit fehlerhaften Daten, ist das bis zur Kundin hin spürbar — sei es in Form eines fehlerhaften Angebots oder einer langen Wartezeit.
Warum lohnt es sich, gerade jetzt damit zu beginnen?
Im Versicherungssektor gilt besonders: Das regulatorische Umfeld und die Erwartungen der Kundinnen und Kunden werden laufend strenger. Kundinnen und Kunden vergleichen die Geschwindigkeit und Einfachheit von Versicherungsprozessen heute mit anderen digitalen Diensten — mit Banking-Apps, mit E-Commerce-Oberflächen —, auch wenn sie das nicht ausdrücklich sagen. Ein langsamer, papieriger Angebotsprozess sticht deshalb heute viel deutlicher vom gewohnten digitalen Erlebnis ab als noch vor ein paar Jahren.
Dieser Erwartungsunterschied stellt nicht nur die Geduld der Kundinnen und Kunden auf die Probe — er wirkt sich auch darauf aus, wie die Versicherung im Vergleich zu den Alternativen am Markt bewertet wird. Wer bei anderen Anbietern einen schnellen, digitalen Prozess gewohnt ist, neigt dazu, aus einem langsamen Angebotsprozess auf die Qualität des gesamten Unternehmens zu schließen — auch wenn diese Annahme den anderen, gut funktionierenden Bereichen der Versicherung nicht gerecht wird.
Dazu kommt: Mit jedem aufgeschobenen Jahr wird es schwieriger, Entwicklerinnen und Entwickler für die Wartung des Systems zu finden, weil die Kenntnis des alten Technologie-Stacks am Markt zu einer immer selteneren Kompetenz wird. Das heißt, Kosten und Risiko der Modernisierung sinken mit der Zeit nicht, sondern steigen — je länger ein Unternehmen wartet, desto schwieriger und teurer wird der Schritt.
Was zieht so ein Projekt für die Organisation nach sich?
Die Modernisierung eines Vertriebsportals ist nicht bloß ein IT-Projekt — sie berührt die täglichen Arbeitsabläufe des Vertriebsteams, den Kundenservice und häufig auch Compliance und Recht, schließlich läuft der Vertragsabschluss in einem regulierten Umfeld ab. Deshalb beschränkt sich die Discovery-Phase nicht auf die Untersuchung des technischen Systems — sie bindet auch jene Menschen ein, die das System Tag für Tag verwenden, damit die finale Lösung die praktische Arbeit wirklich erleichtert und nicht nur am Papier gut aussieht.
Diese Einbindung sorgt zugleich für eine reibungslosere Einführung — wenn der Vertrieb schon in der Planungsphase mitwirkt, wird das neue System viel leichter angenommen und erlernt, als wenn ein fertiges Produkt geliefert wird, das ohne die Nutzerinnen und Nutzer entwickelt wurde.
Häufig gestellte Fragen
Lohnt sich so ein Projekt nur für Versicherungen?
Der Versicherungssektor ist unsere bislang stärkste Referenz, und dort bündeln wir die Leistung derzeit auch. Das Problem veralteter, unterentwickelter Systeme zeigt aber ähnliche Muster in anderen datenintensiven, regulierten Branchen — im Bankensektor, bei Leasinggesellschaften oder bei anderen Finanzdienstleistern treffen wir häufig auf dieselben Symptome.
Wie lange dauert so ein Projekt?
Unser Referenzprojekt hat rund ein Jahr gedauert — das kann je nach Umfang und Komplexität abweichen, die genaue Dauer lässt sich auf Basis des Ergebnisses der Discovery-Phase bestimmen.
Was tun wir, wenn wir nicht sicher sind, ob das ganze Portal neu gebaut werden muss oder ein kleinerer Eingriff reicht?
Genau das ist das Ziel der Discovery-Phase — ihr müsst das nicht vorab entscheiden, sondern nur die Erhebung starten; auf Basis ihres Ergebnisses entsteht eine konkrete, begründete Empfehlung.
Muss das Vertriebsteam in den Entwicklungsprozess eingebunden werden?
Ja, das ist ausdrücklich empfehlenswert — die tägliche Erfahrung des Teams zeigt, wo die realen Reibungspunkte entstehen, und eine frühe Einbindung erleichtert außerdem die Akzeptanz des fertigen Systems.
Was passiert bei der Modernisierung mit den Daten aus dem alten System?
Die Datenmigration ist immer einer der kritischen, sorgfältig geplanten Schritte des Projekts — in der Discovery- und Planungsphase erheben wir auch das im Detail, damit die bestehenden Kunden- und Vertragsdaten reibungslos und ohne Verlust in das neue System übergehen.
Muss der laufende Betrieb während der Modernisierung stillstehen?
Nein — die Projekte werden typischerweise so aufgebaut, dass der tägliche Vertriebs- und Kundenbetreuungsbetrieb während der Entwicklung ungestört weiterläuft; die Umstellung erfolgt in Phasen und sorgfältig getaktet, nicht in einem einzigen riskanten „Big Bang“-Schritt.
Fazit
Wenn es auch in eurer Versicherung ein Vertriebsportal gibt, das die Arbeit bremst statt sie zu unterstützen, lohnt es sich, die Erhebung mit einem Discovery-Gespräch zu starten — bevor sich das Problem weiter vertieft und der Rückstand immer schwerer aufzuholen ist. Je früher ihr damit beginnt, desto mehr Spielraum bleibt für eine schrittweise, kontrollierte Umstellung statt einer hektischen, erzwungenen Ablöse.