KI im Kundenservice, die nicht peinlich wird

Im Kundenservice ist nicht die Fehlerquote das Problem, sondern die Autonomie

Fragen Sie, was eine falsche Serviceauskunft kostet, bekommen Sie einen Mittelwert zurück: ein paar Minuten, eine Entschuldigung, weiter im Text. Nur ist der Schaden nicht verteilt wie ein Mittelwert. Ein Bot, der einen Liefertermin falsch nennt, kostet einen Rückruf. Ein Bot, der eine Kündigung bestätigt, die nie eingegangen ist, oder einem Kunden erklärt, ein abgekündigtes Ersatzteil passe in seine Maschine, erzeugt einen Vorgang, eine Fehllieferung oder einen Beitrag mit Screenshot. Die hundert Antworten, die richtig waren, haben Ihnen dagegen nichts eingebracht: Eine schnelle, korrekte Auskunft gilt als Selbstverständlichkeit.

Der Erwartungswert von Autonomie startet also negativ und dreht erst ins Positive, wenn Sie Belege haben. Keine Demo, kein Benchmark eines Anbieters, sondern Belege aus Ihrer eigenen Warteschlange. Damit steht die ehrliche Antwort schon am Anfang: Das Modell entwirft, ein Mensch sendet — und dabei bleibt es, bis Ihre eigenen Tickets etwas anderes sagen. Das ist keine Ängstlichkeit, sondern die einzige Konstellation, in der ein Fehler nichts kostet.

Der Entwurfsmodus ist keine Übergangslösung, sondern Ihre einzige Evidenz

Der Entwurfsmodus gilt als die peinliche Phase, die man vor dem eigentlichen Produkt durchsteht. Das ist verkehrt herum gedacht. Jedes Mal, wenn eine Mitarbeiterin einen erzeugten Entwurf unverändert abschickt, haben Sie einen gelabelten Datenpunkt: Die Maschine lag richtig, im Produktivbetrieb, an einem echten Ticket, beurteilt von jemandem, der für die Antwort geradesteht. Jedes Mal, wenn sie den zweiten Absatz umschreibt, haben Sie eine gelabelte Korrektur — und das Diff verrät die Art des Fehlers: eine fehlende Information, ein falscher Ton, eine Regelung, die das Modell nie gesehen hat. Sechs Wochen davon, nach Ticketkategorie sortiert, sind ein besserer Evaluationsdatensatz als alles, was Sie beauftragen könnten. Und sie kosten nichts extra, weil Ihr Team diese Tickets ohnehin beantwortet hätte.

Die Automatisierungsentscheidung ist damit keine Ermessensfrage mehr. Sie sehen sich die Änderungsquote je Kategorie an. Lieferstatus: Die Entwürfe werden seit Wochen nicht mehr angefasst. Garantieumfang: Die Hälfte wird umgeschrieben. Also automatisieren Sie den Lieferstatus und den Garantieumfang eben nicht — und können begründen, warum. Diese Nachvollziehbarkeit wirkt wie Bürokratie, bis zu dem Morgen, an dem jemand fragt, warum eine Maschine das einem Kunden geschrieben hat.

Schwierig daran ist: Der Entwurfsmodus muss spürbar schneller sein als kein Entwurfsmodus, sonst ignoriert Ihr Team die Vorschläge stillschweigend und Ihre Evidenz ist wertlos. Wenn der Vorschlag drei Sekunden zu spät kommt, in einem zweiten Browsertab steht oder die Auftragsnummer nicht schon eingesetzt hat, fängt man von vorne an — und Sie halten am Ende das Modell für schlecht, obwohl die Integration schlecht ist. Der Entwurf gehört in das Antwortfeld, in dem Ihr Team ohnehin sitzt: Zendesk, Freshdesk, HubSpot Service Hub, oder was bei Ihnen läuft. Das ist keine Bequemlichkeit, sondern die Gültigkeit des Experiments.

Der Bot ist ein Spiegel Ihrer Dokumentation

Ein Modell, das aus seinen Gewichten heraus antwortet, ist ein Haftungsrisiko; eines, das aus Ihren Dokumenten antwortet, ist ein Produkt. So weit Standard: Retrieval legt dem Modell Ihre tatsächlichen Richtlinien, Handbücher und alten Lösungen vor und weist es an, daraus zu antworten. Weniger Standard ist der Satz danach. Retrieval macht Ihre Dokumentation tragend — und die Dokumentation der meisten Unternehmen trägt nicht.

Nehmen Sie einen ganz gewöhnlichen Zulieferer: eine Service-FAQ, zuletzt 2019 bearbeitet, eine Ersatzteilliste, die tatsächlich verbindlich ist, und ein Wiki, in dem die abgelöste und die gültige Montageanweisung zwei Seiten auseinanderliegen, beide ohne Datum. Richten Sie Retrieval darauf, tut das System genau das, was Sie verlangt haben: Es findet die Seite von 2019, antwortet daraus und zitiert sie. Jetzt ist die Antwort falsch und trägt einen Quellenlink — schlimmer als eine schlicht falsche Antwort, denn genau dieses Zitat überzeugt Ihre eigene Mitarbeiterin, sie ungeprüft abzuschicken. Verankerung macht ein System nicht wahrhaftig. Sie macht es treu gegenüber dem, worauf Sie es richten, und dem Mechanismus darunter ist gleichgültig, dass das Dokument veraltet war.

Keine Quelle, kein Entwurf

Ein fehlgeschlagenes Retrieval muss ein vollwertiges Ergebnis sein, kein stiller Rückfall ins Improvisieren. Wenn nichts im Korpus das Ticket beantwortet, lautet das richtige Verhalten: kein Entwurf, Ticket an einen Menschen. Nicht: ein hilfsbereit klingender Absatz aus Allgemeinwissen. Das sind ungefähr zwei Zeilen Code, und sie entfernen die Mehrheit der Antworten, die Ihnen peinlich geworden wären — denn „das Modell hat sich etwas ausgedacht“ und „es gab nichts, woraus es hätte antworten können“ sind meistens dasselbe Ereignis.

Vierzig gepflegte Dokumente schlagen viertausend ungepflegte

Der Reflex ist, alles zu indexieren: jedes PDF auf dem Laufwerk, das ganze Wiki, zehn Jahre Tickets. Widerstehen Sie. Vierzig Dokumente, für die jemand zuständig ist und die aktuell gehalten werden, schlagen viertausend, die niemand pflegt — denn in einem Retrieval-System liegt ein veraltetes Dokument nicht harmlos herum, es konkurriert um die Antwort. Zuständigkeit ist der eigentliche laufende Aufwand eines Service-Bots und die Position, die in jeder Kalkulation fehlt: Eine namentlich benannte Person muss dafür geradestehen, dass die Seite zum Widerrufsrecht in diesem Quartal stimmt. Findet sich dafür niemand, ist KI nicht Ihr nächstes Problem.

Nach Regeln eskalieren, nicht nach Confidence

Die verbreitetste Eskalationslogik ist eine Confidence-Schwelle: Das Modell bewertet seine eigene Sicherheit und übergibt unterhalb eines Werts. Das würde ich nicht bauen, und ich würde Ihnen davon abraten. Sprachmodelle sind schlecht kalibriert — eine erfundene und eine korrekte Antwort entstehen im selben Prozess und fühlen sich von innen gleich sicher an. Eine Schwelle hängt also die riskanteste Entscheidung des Systems ausgerechnet an das Signal, das dieses System am schlechtesten erzeugt.

Eskalieren Sie stattdessen anhand von Tatsachen, die Sie ohnehin haben, geprüft bevor das Modell irgendetwas erzeugt. Kategorie: Kündigung, Widerruf nach § 355 BGB, Beschwerde, alles, was einen Schadensfall oder eine Zahlung berührt — nie eine automatische Antwort, egal wie einfach es aussieht. Sprache: Ist Ihr Korpus deutsch und das Ticket türkisch, haben Sie keine Übersetzungsfunktion, sondern eine ungetestete. Verlauf und Ton: Die dritte Nachricht im selben Vorgang oder eine sichtlich wütende erste geht an einen Menschen — nicht weil das Modell nicht antworten könnte, sondern weil ein Kunde, den man bereits zweimal enttäuscht hat, der falsche Versuchsgegenstand ist. Retrieval: keine Quelle, kein Entwurf.

Zwei Vorschriften sollten Sie beim Namen kennen, statt sie später zu entdecken. Artikel 50 der KI-Verordnung verlangt, dass Menschen erfahren, wenn sie mit einem KI-System interagieren, sofern sich das nicht ohnehin aus dem Kontext ergibt; diese Transparenzpflichten gelten ab dem 2. August 2026. Artikel 22 DSGVO gibt Betroffenen das Recht, keiner ausschließlich automatisierten Entscheidung mit rechtlicher oder ähnlich erheblicher Wirkung unterworfen zu werden. „Wo ist meine Lieferung“ zu beantworten ist keine solche Entscheidung. Einen Kulanzantrag automatisch abzulehnen liegt nah genug an der Grenze, dass ich es auf der menschlichen Seite des Routers halten würde, statt die Diskussion im Nachhinein zu führen. Und genau das ist der Punkt: Routing-Regeln sind ein Nachweis — einer Aufsichtsbehörde können Sie keinen Confidence-Wert vorlegen.

Siezen ist leicht. Der Ton ist es nicht.

Die deutsche Anrede wird als Häkchen behandelt: Sie einstellen, fertig. Und Modelle halten das Siezen durchaus zuverlässig durch, wenn man es ihnen sagt und Beispiele zeigt — an der Grammatik scheitert das hier nicht. Es scheitert eine Ebene darüber, beim Register.

Denken Sie an einen Regionalversicherer. Eine Kundin schreibt am vierten Tag eines ungeklärten Leitungswasserschadens. Das Modell, geprägt von einem globalen Korpus unermüdlich gut gelaunter Servicetexte, produziert eine Antwort, die grammatisch einwandfrei ist, durchgehend siezt und tonal eine Katastrophe darstellt: gut gelaunt, in amerikanischer Betroffenheitsrhetorik entschuldigend, mit einem „Vielen Dank für Ihre Geduld!“, das jemandem im nassen Keller wie Hohn vorkommt. Die Grammatik wird niemand bemängeln. Den Ton bemerkt jeder. Und das ist exakt ein Fall, den eine Regel zur Dringlichkeit vor der Generierung hätte aussortieren müssen — das Eskalationsargument, aus einer zweiten Richtung.

Das zweite Erkennungsmerkmal ist die Herkunft. Wurde Ihr Prompt auf Englisch geschrieben und übersetzt das Modell seine eigene Absicht ins Deutsche, bekommen Sie Deutsch, das korrekt und fremd zugleich ist: Anglizismen, Satzrhythmen, die in deutscher Geschäftskorrespondenz nicht vorkommen, ein reflexhaftes „Wir entschuldigen uns für die Unannehmlichkeiten“ dort, wo ein deutscher Service schlicht sagen würde, was als Nächstes passiert und wann. Die Abhilfe ist unspektakulär: Schreiben Sie den Prompt auf Deutsch, und zeigen Sie dem Modell zehn Antworten, die Ihre beste Mitarbeiterin tatsächlich verschickt hat. Zehn echte Antworten bewegen den Ton weiter als jede Adjektivkette im System-Prompt.

Deflection ehrlich messen

Die Deflection-Rate — der Anteil der Dialoge, die ohne Menschen endeten — ist die Kennzahl, die jeder Anbieter berichtet, und sie ist konstruktionsbedingt verdorben, weil sie Aufgeben als Erfolg zählt. Eine Kundin, die zweimal fragt, nichts Brauchbares bekommt, den Chat schließt und beim Wettbewerber anruft, ist eine Deflection. Eine Kundin, der wirklich geholfen wurde, ebenfalls. Die Zahl kann beide nicht unterscheiden — hervorragend für eine Folie, unbrauchbar für eine Entscheidung.

Messen Sie stattdessen Lösung, über ein Zeitfenster: Wie viele der Tickets, die der Bot allein bearbeitet hat, wurden innerhalb von sieben Tagen von derselben Person wieder aufgemacht — neues Ticket, Anruf, Antwort im alten Vorgang? Das ist ein Abgleich zwischen Helpdesk und Telefonanlage, deutlich schwerer zu schönen, und es ergibt eine Zahl, die Ihr Team als wahr wiedererkennt.

Zwei weitere lohnen sich. Erstens die Qualität der Eskalation: Wenn ein Ticket doch bei einem Menschen landet, erbt er den Kontext, oder erklärt der Kunde alles noch einmal von vorne? Ein Bot, der gut deflektiert, aber jeden eskalierten Vorgang auf null zurücksetzt, verschiebt die Kosten leise auf Ihre wütendsten Kunden — also auf die Menschen mit dem größten Anlass, öffentlich über Sie zu reden. Zweitens der Ist-Wert, erhoben bevor irgendetwas gebaut wird: mediane Erstreaktion, mediane Lösungszeit, und welcher Anteil Ihres Volumens dieselben fünf Fragen sind. Der Kundenservice ist eine der wenigen Stellen, an denen sich KI verlässlich rechnet — aber nur, wenn Sie hinterher sagen können, um wie viel. „Der Bot antwortet in 30 Sekunden“ vergleicht sich mit nichts.

Wo Tippel ins Spiel kommt

Der größte Teil dieses Artikels handelt davon, was man lassen sollte — als Verkaufsargument merkwürdig. Deshalb klar zur Form der Arbeit: Ein Servicesystem, das etwas taugt, ist überwiegend Klempnerei. Entwürfe in das Werkzeug bringen, in dem Ihr Team ohnehin arbeitet. Den Router an Ihre echten Ticketkategorien hängen. Entscheiden, welche vierzig Dokumente der Korpus sind und wer sie verantwortet. Die Messung vor dem Bot bauen. Das Modell ist der einfache Teil und wird jedes Quartal einfacher. Der Rest nicht.

Der KI-Readiness-Check ist genau das, bezahlt und zeitlich begrenzt: Ihre echten Tickets, Ihre echten Dokumente und eine ehrliche Antwort darauf, welche Kategorien sich heute gut entwerfen ließen und welche Ihre Dokumentation noch nicht trägt. Am Ende steht ein Go/No-Go, die Gebühr wird bei Beauftragung voll angerechnet, und „Ihre Wissensbasis ist noch nicht so weit“ ist ein zulässiges Ergebnis. Wenn Sie es lieber erst besprechen möchten, nehmen Sie Kontakt auf.