Schadensmeldungen triagieren, bevor sie landen.

Ausgangslage.

Ein mittelständischer Sachversicherer mit rund 240 Mitarbeitern. Schadensmeldungen kommen aus vier Kanälen ein: über ein Kundenportal, über E-Mails an mehrere Sammeladressen, über die Online-Formulare von Maklern und über die Telefonhotline, deren Transkripte täglich als E-Mail einlaufen. Insgesamt rund 1.200 Fälle pro Woche.

Der bestehende Triage-Prozess war historisch gewachsen. Im Schadenservice saßen zwölf Mitarbeiterinnen, die eingehende Meldungen lasen, einer Sparte zuordneten (Haftpflicht, Hausrat, Kfz, Gebäude, sonstige), den Kundendaten im Bestandssystem abglichen und den Vorgang dann an die jeweilige Fachabteilung weiterleiteten. Pro Meldung etwa vier bis acht Minuten, vor allem wegen der Wechsel zwischen Systemen und der Zeit, die das Lesen ungewöhnlich formulierter Meldungen erforderte.

Das Problem war nicht nur die Zeit. Das Problem war, dass die Bearbeitung häufig erst am Folgetag begann. Der Kunde erlebte eine Versicherung, die auf eine Meldung nicht sofort reagiert — was bei einem Schadensfall emotional besonders relevant ist. In einer internen Befragung gaben 60 Prozent der Befragten an, die fehlende sofortige Rückmeldung mache ihnen mehr aus als die eigentliche Bearbeitungsdauer.

Zusätzlich entstanden durch manuelle Zuordnung regelmäßig Zuweisungsfehler — etwa eine Haftpflicht-Meldung, die irrtümlich in der Hausrat-Abteilung landete und erst dort umgeleitet wurde. Solche Fehler kosteten weitere Tage. Auch die Unterscheidung zwischen einfachen Standardschäden und solchen, bei denen Betrugsrisiken bestehen, lag allein in der Einschätzung der jeweiligen Mitarbeiterin. Ohne systematische Auswertung.

Das Management hatte zuvor zweimal versucht, das Problem durch Prozess-Vereinheitlichung und Leitfäden zu lösen. Beide Anläufe hatten kurzfristig Verbesserungen gebracht, waren aber nach einigen Monaten wieder zurück auf das alte Niveau gefallen. Die schiere Menge und Varianz der eingehenden Meldungen überforderte jede manuelle Struktur.

Unser Vorgehen.

Wir haben zwei Tage bei der Mandantin verbracht. Am ersten Tag haben wir jeder Triage-Mitarbeiterin zugeschaut, wie sie mit eingehenden Meldungen umgeht. Am zweiten Tag haben wir einen repräsentativen Ausschnitt aus 200 Meldungen der letzten Wochen durchgesehen — Muster erkannt, Ausnahmen markiert, Mehrdeutigkeiten identifiziert. Aus dieser Analyse ist eine Taxonomie mit 18 Unter-Kategorien entstanden, die den tatsächlichen Entscheidungsbaum der Triage-Mitarbeiterinnen widerspiegelt.

Daraus ergab sich eine Struktur, die das Projekt tragen konnte. Wir haben Meldungen in drei Kategorien geteilt: Eindeutige Fälle (Sparte klar erkennbar, Kunde im Bestand, Schaden plausibel) — etwa 75 Prozent. Grenzfälle (mindestens ein Merkmal mehrdeutig) — etwa 18 Prozent. Echte Zweifelsfälle (widersprüchliche Angaben, unbekannter Kunde, oder Meldung mit rechtlichen Implikationen) — etwa sieben Prozent.

Die Anforderung an den Agent: Die eindeutigen Fälle vollständig zuordnen und an die richtige Fachabteilung senden, inklusive angereicherter Kundendaten und einer Zusammenfassung. Die Grenzfälle mit klarem Hinweis an die Triage-Mitarbeiterinnen zurückspielen. Die Zweifelsfälle gar nicht selbst entscheiden — sondern direkt an die Abteilungsleitung leiten, mit strukturierter Zusammenfassung und Markierung der kritischen Punkte.

Nach diesem Scoping haben wir ein Qualitätsziel festgelegt: mindestens 90 Prozent korrekte Erstzuordnung in der Eindeutig-Kategorie. Darunter wäre das Projekt nicht live gegangen. Zusätzlich haben wir einen Prozess zur monatlichen Qualitäts-Messung aufgesetzt — ein Zufalls-Sample von 50 Fällen pro Monat wird manuell nachgeprüft, die Ergebnisse fließen in ein Qualitäts-Dashboard.

Ein weiterer Punkt war die Einbindung der Datenschutzbeauftragten von Woche zwei an. Die Versicherungsbranche ist in Sachen Datenschutz besonders sensibel, und wir wollten Überraschungen kurz vor Livegang vermeiden. Die Freigabe lief parallel zur Entwicklung, nicht sequentiell danach.

Die Umsetzung.

Der Agent besteht aus drei Stufen. Zunächst werden eingehende Nachrichten aus den vier Kanälen in ein gemeinsames Format normalisiert — E-Mail-Header, Telefon-Transkript, Portal-Formular-Daten landen alle in derselben Struktur. Dieser Normalisierungs-Schritt war anspruchsvoller als erwartet: Jeder Kanal hatte eigene Metadaten, unterschiedliche Formate für Kundennummern, teilweise unvollständige Ansprechpartner-Felder.

Zweitens klassifiziert ein Sprachmodell die Sparte und extrahiert die zentralen Meldungs-Informationen — Schadensart, betroffenes Objekt, Kontaktdaten, freier Text, Hinweise auf Dringlichkeit oder auffällige Umstände. Das Modell liefert seine Antwort in einem strukturierten JSON-Schema, das sich direkt in die nachfolgende Logik einfügt.

Drittens reichert ein deterministischer Schritt diese Informationen mit Kundendaten aus dem Bestandssystem an und wählt das Zielsystem aus. Hier haben wir bewusst nicht auf das Sprachmodell gesetzt: Das Modell entscheidet die Sparte und extrahiert Felder — die Zuordnung zum Kunden und die Auswahl der Abteilung folgt deterministischen Regeln. So wird jede Entscheidung nachvollziehbar und prüfbar, und die Fachlichkeit der Triage-Mitarbeiterinnen bleibt im Code abgebildet, nicht im Modell.

Das Bestandssystem hatte eine REST-API, die aber nicht alle relevanten Informationen bereitstellte. Für Kundendaten nutzten wir die API, für die Schadenshistorie mussten wir auf einen zweiten, nur per SQL erreichbaren Datenbestand zugreifen. Beides läuft innerhalb der IT-Infrastruktur der Mandantin, kein Datenabfluss, keine externen Abhängigkeiten.

Besonders sensibel war der Umgang mit personenbezogenen Daten. Wir haben dafür ein EU-gehostetes Sprachmodell gewählt, dessen Anbieter-Vertrag das Training auf Kundendaten explizit ausschließt. Die Datenschutzbeauftragte des Versicherers hat den Datenfluss vor dem Livegang formell freigegeben, und wir haben eine knappe Datenschutz-Folgenabschätzung mitsamt Konfliktanalyse für sie vorbereitet.

Ergebnis.

Nach neun Wochen ging der Agent produktiv. Von 1.200 wöchentlichen Meldungen werden aktuell rund 900 vollautomatisch an die richtige Fachabteilung geleitet, durchschnittlich innerhalb von vier Minuten nach Eingang. Die Erstzuordnungs-Qualität liegt in diesen Fällen bei 92 Prozent — gemessen an einer fortlaufenden Stichproben-Prüfung.

Die verbleibenden rund 300 Meldungen pro Woche werden von den Triage-Mitarbeiterinnen bearbeitet. Aber in einer anderen Ausgangslage als zuvor: Der Agent hat jede Meldung bereits analysiert und einen Vorschlag mit Begründung gemacht. Die Mitarbeiterinnen validieren oder korrigieren, statt zu klassifizieren — eine qualitativ andere Arbeit.

Für den Kunden bedeutet das: Fast jede Meldung wird am Tag ihres Eingangs von der zuständigen Fachabteilung bearbeitet. Die zuvor problematische „Lücke zwischen Eingang und Erstbearbeitung" ist von durchschnittlich 28 Stunden auf weniger als drei Stunden geschrumpft. In der jüngsten Kundenbefragung war das der am häufigsten positiv genannte Effekt.

Die Triage-Abteilung wurde in Summe um drei Stellen schlanker — nicht durch Entlassungen, sondern durch Versetzungen in die Fachabteilungen, wo die Entlastung durch den Agent neuen Spielraum geschaffen hat. Zwei dieser drei Mitarbeiterinnen arbeiten heute als Ansprechpartnerinnen für den Agent: Sie pflegen die Taxonomie, prüfen neue Kategorien, bilden die Schnittstelle zwischen der Fachseite und der IT.

Was wir gelernt haben.

Der teuerste Teil war nicht das Modell, sondern die Normalisierung der vier Eingangskanäle. Die Annahme, dass ein Sprachmodell schon „irgendwie die Strukturen findet", hat sich nicht bewährt — die Qualität steigt dramatisch, wenn der Input in einer einheitlichen Form ankommt. Diese Investition in die erste Stufe hat sich über alle folgenden Schritte ausgezahlt.

Zweitens: Die frühe Einbindung der Datenschutzbeauftragten war entscheidend. In zwei anderen Projekten mit ähnlichen Setups waren wir später dran — und das hat jedes Mal Wochen gekostet, weil am Ende nachgebaut werden musste. Bei diesem Projekt lief die Freigabe parallel zur Entwicklung, was sehr hilfreich war.

Drittens: Die Triage-Mitarbeiterinnen, die zuvor skeptisch gegenüber der Automatisierung waren, sind nach Livegang zu den aktivsten Verbesserungs-Melderinnen geworden. Sie sehen jetzt strukturierte Fälle und können gezielt sagen, wo der Agent eine Klassifikation besser hätte treffen können. Das Feedback fließt regelmäßig in die Weiterentwicklung ein.

Viertens: Das Qualitäts-Dashboard, das wir fast als Nebenprodukt gebaut haben, ist inzwischen das wichtigste Steuerungs-Instrument für den Agenten. Die Abteilungsleitung sieht monatlich, wo die Zuordnungs-Qualität liegt, in welcher Sparte sie besonders gut ist und wo Nachjustierung nötig ist. Ohne dieses Dashboard wäre der Agent eine Black Box geblieben — mit ihm ist er ein Werkzeug, das sich kontrollieren und verbessern lässt.