Versicherer sind bekannt dafür, dass ihre Systeme historisch gewachsen sind. Unser Kunde — ein mittelgroßer Sachversicherer in der deutschsprachigen Schweiz — bildete keine Ausnahme: drei Kernsysteme aus drei Jahrzehnten, Kundenkommunikation primär über Brief und Telefon, eine Self-Service-Plattform, die 2014 gebaut wurde und seit 2019 nicht mehr aktiv weiterentwickelt wird.
Die Ausgangslage
Die Zahlen waren deutlich: 68% der eingehenden Kundenanfragen waren reine Auskünfte zu bestehenden Verträgen — Deckungssummen, Laufzeiten, Selbstbehalte. Jede dieser Anfragen bedeutete Sachbearbeiter-Zeit. Der Rückstand im Postfach wuchs wöchentlich um 3–4%. Gleichzeitig war die Fluktuation im Kundenservice hoch — der Job war frustrierend, weil er überwiegend aus repetitiven Standard-Anfragen bestand.
Die Erwartung an uns: Eine Lösung, die die Standard-Auskünfte im Self-Service abbildet, ohne dabei die regulatorischen Anforderungen (FINMA, DSG) zu verletzen.
Die Architektur
Wir haben in drei Phasen gearbeitet:
Phase 1: Strukturierung der Policy-Daten. Die Kernsysteme liefern Daten in unterschiedlichen Formaten. Ein Schema-First-Ansatz mit JSON Schema definierte ein einheitliches Policy-Objekt. Pro Kernsystem wurde ein Adapter gebaut, der aus dem alten Format das kanonische Schema erzeugt — im Stream, nicht im Batch.
Phase 2: KI-Assistent mit strengem Scope. Der Assistent hat Zugriff auf exakt drei Tool-Interfaces: getPolicy(customerId), getClaims(customerId, range?) und getContactChannels(topic). Alles andere fällt auf menschliche Bearbeiter zurück. Wir haben bewusst nicht versucht, den Assistenten "smart" zu machen — das Safety-Profile ist durch den engen Tool-Scope definiert, nicht durch Prompt-Engineering.
Phase 3: Graduelle Rollout. Erst wurde die neue Oberfläche für 5% der Kunden ausgespielt (AB-Test). Nach vier Wochen mit positiven Metriken auf 30%, dann auf 100%. Die alte Self-Service-Oberfläche läuft bis heute als Fallback — Kunden können jederzeit zurückwechseln. Bisher haben das 2.1% getan.
Die Ergebnisse
Nach neun Monaten im Vollbetrieb:
- Durchlaufzeit Standard-Anfragen: 2.1 Arbeitstage → 14 Minuten (95%-Perzentil)
- Sachbearbeiter-Auslastung durch Standard-Auskünfte: 68% → 18%
- Kundenzufriedenheit (NPS): +12 Punkte gegenüber Vorjahr
- Fluktuation im Kundenservice: –40% (andere Gründe spielen mit rein, aber der Trend ist eindeutig)
Die freigewordene Sachbearbeiter-Zeit fließt nun in die komplexen Schadenfälle — die Bearbeitung dieser Fälle wurde spürbar qualitativer. Das war nicht das primäre Ziel, ist aber der interessanteste Nebeneffekt.
Was nicht funktioniert hat
Wir hatten zu Beginn geplant, den Assistenten auch Schadenmeldungen entgegennehmen zu lassen. Das haben wir nach zwei Monaten Pilot wieder zurückgenommen. Der Grund war nicht technisch, sondern menschlich: Kunden im Schadensfall sind emotional belastet und erwarten menschliche Ansprache. Ein Assistent, der korrekt, aber unpersönlich antwortet, wurde als "abweisend" empfunden. Wir leiten jetzt Schadensfälle direkt an einen Menschen.
Ausblick
Phase 4 — geplant für H2 2026 — ist die Integration in den Makler-Kanal. Die Anforderungen dort sind andere: Makler wollen Bulk-Zugriff, keine Einzelabfragen. Die Architektur passt aber — das Tool-Interface getPolicy(customerId) wird zu listPolicies(brokerId, filter), der Rest bleibt gleich.