Zwei Nutzer­gruppen, zwei Design­systeme

LKHs Broker arbeiteten seit Jahren mit einem Legacy-Portal und den Excel-Tabellen, die daneben entstanden waren. Jede Regel zu einem Zusatzversicherungsantrag existierte mehrfach: im alten System, in den Tabellen, in den Köpfen der Leute am Telefon. Eine ändern hiess alle prüfen. Das ist die Überraschungssteuer, und LKH zahlte sie bei jedem Produkt-Update.

Die Entscheidung

Die Entscheidung war nicht ein Interface für alle. Sondern eine Designsprache mit zwei Designsystemen darunter: ein dichtes für Broker, die den Jargon und die Sonderfälle kennen und Kontrolle wollen, und ein geführtes für Kunden, die ohne Vorwissen kommen und an die Hand genommen werden wollen. Gleiche Tokens, gleiche Komponenten im Kern, zwei Kalibrierungen obendrauf. Beide sehen weiterhin nach derselben Firma aus.

Was das Portal können musste

Das Broker-Portal musste vollständig genug sein, um die Tabellen von knapp 200 Brokern und das Legacy-System in einem Zug abzulösen, sonst wäre niemand gewechselt. Und zum ersten Mal in der Geschichte von LKH konnten Kunden eine Zusatzversicherung komplett am Bildschirm beantragen, ohne Broker dazwischen.

Release 1.1

Release 1.1 kam, wie es immer kommt: neue Tarife, eine regulatorische Änderung, ein Feld, das das Backoffice brauchte. Jede Änderung landet jetzt einmal, im System, und erscheint auf beiden Seiten. Klärungsanrufe zwischen Brokern und LKH sind um 65 Prozent zurückgegangen, und ein Antrag pendelt nicht mehr zwischen Einreichung und Entscheid. Das ist der Teil, der nach dem Launch günstig bleibt.