KI im Kundenservice: Was passiert, wenn der Bot Arbeit erzeugt statt sie zu lösen

63 Prozent der deutschen Contact Center befinden sich aktuell in der Umsetzung oder im Vollbetrieb von KI-Lösungen im Kundenservice. 37 Prozent testen, 26 Prozent sind produktiv. Die Dynamik ist real. Was bisher weniger Aufmerksamkeit bekommt: Was passiert mit den Anfragen, die die KI nicht löst? Und was passiert mit den Anfragen, die sie verschlimmert?

Jede Organisation, die einen Chatbot oder Voice Bot einsetzt, misst die Autonomous Handle Rate oder eine vergleichbare Kennzahl: den Anteil der Anfragen, die der Bot eigenständig abschließt, ohne dass ein Mensch eingreifen muss. 60 Prozent, 65 Prozent, manchmal 70. Die Zahl steht im Dashboard, sie wird in Quartalspräsentationen gezeigt, und sie erzeugt bei Entscheidungsträger:innen den Eindruck, dass Automatisierung funktioniert.

Was die Zahl nicht zeigt: Was mit den übrigen 30 bis 40 Prozent passiert. In vielen Organisationen werden diese Fälle als "Eskalation" verbucht und an den menschlichen Service übergeben. Die Übergabe ist der Punkt, an dem Automatisierung auf operative Realität trifft. Und genau an diesem Punkt entstehen Kosten, die in den meisten Dashboards nicht auftauchen.

AI Failure Demand beschreibt Kontaktvolumen, das durch die KI selbst erzeugt oder verschlimmert wird. Die Kundin hat versucht, ihr Anliegen über den Bot zu klären. Der Bot hat das Anliegen nicht verstanden, hat eine falsche Auskunft gegeben, hat sich in einer Schleife verfangen, oder hat eine Zusage gemacht, die das Unternehmen nicht einhalten kann.

Jetzt ruft die Kundin an. Sie ist bei Ankunft bereits frustriert. Oft wütend. Die Servicemitarbeiterin muss zunächst den Bot-Fehler aufklären ("Der Bot hat Ihnen leider eine falsche Information gegeben"), dann das Vertrauen wiederherstellen, und erst danach das eigentliche Problem lösen.

Die Erfahrung aus mehreren Organisationen, in denen ich das gemessen habe: Die Recovery-AHT nach einem gescheiterten Bot-Kontakt liegt beim zwei- bis dreifachen eines normalen Kontakts. Das heißt: Ein Kontakt, der ohne Bot sechs Minuten gedauert hätte, dauert nach Bot-Versagen zwölf bis achtzehn Minuten. Die Kundenzufriedenheit ist niedriger, die Belastung für die Mitarbeiterin höher, und die Kosten pro Kontakt steigen statt zu sinken.

Containment Rate (auch Autonomous Handle Rate) misst, ob die Kundin den Bot verlassen hat oder nicht. Sie sagt: "Die Kundin ist im Bot geblieben." Was sie nicht sagt: "Die Kundin hat eine Lösung bekommen." Und was sie erst recht nicht sagt: "Die Kundin musste danach nicht noch beim Menschen anrufen."

Es gibt Szenarien, in denen die Containment Rate hoch ist und die Servicequalität trotzdem leidet. Etwa wenn der Bot die Kundin in eine Self-Service-Strecke leitet, die ihr Problem nicht löst, sie aber auch nicht aktiv zum menschlichen Service weiterleitet. Die Kundin bricht ab, das Ticket bleibt offen, und der nächste Kontakt wird aufwändiger. In der Containment-Statistik ist der Fall ein Erfolg. In der operativen Realität ist er ein Fehler mit Folgekosten.

Was belastbarer wäre: Eine Kombination aus Containment und Repeat-Contact-Rate. Wenn die Kundin den Bot nutzt und innerhalb von 7 Tagen zum gleichen Thema einen menschlichen Kontakt aufnimmt, war die Bot-Interaktion nicht erfolgreich, egal was das Dashboard sagt. Diese Kopplung erfordert technisch eine Verknüpfung zwischen Bot-Session und CRM-Ticket, die in vielen Architekturen noch nicht vorhanden ist. Aber ohne sie bleibt Containment eine Vanity Metric.

Die MUUUH! Voice Studie 2026 zeigt, dass 44 Prozent der Deutschen die Weitervermittlung an einen menschlichen Mitarbeiter als wichtigste Eigenschaft eines Voice Agent sehen. Auf Rang zwei folgt der Informationsaustausch zwischen KI und Mensch. Die beiden grundlegendsten Funktionen - Übergabe und Kontextübergabe - scheitern in der Praxis am häufigsten.

Was das konkret heißt: Die Kundin hat dem Bot ihr Problem geschildert, sich identifiziert, vielleicht sogar Vertragsdaten genannt. Dann wird sie an den menschlichen Service übergeben. Und fängt von vorne an. Name, Kundennummer, Problem, alles nochmal.

Das Handover-Paket, also die Informationen, die der Bot bei der Übergabe an den Menschen mitgibt, ist in vielen Organisationen entweder nicht definiert oder unvollständig. Was ein gutes Handover-Paket enthalten sollte: den bisherigen Dialogverlauf (zusammengefasst, nicht als Rohdaten), ein Topic-Tag, das den Grund der Übergabe klassifiziert, einen Hinweis auf den Frustlevel der Kundin (wenn die KI Sentiment-Analyse einsetzt), eine Auflistung der bisherigen Lösungsversuche, die Session-ID zur Nachverfolgung, den Authentifizierungsstatus und einen Eskalationsgrund-Code.

Das klingt nach viel. Ist es auch. Aber jedes fehlende Feld erzeugt Nacharbeit beim menschlichen Service. Und jede Nacharbeit kostet Zeit, Geld und Kundenzufriedenheit.

Die Frage, die in vielen Organisationen nicht beantwortet ist: Was passiert, wenn der Bot systematisch falsche Zusagen macht? Wer bemerkt es? Wer darf ihn stoppen?

In einer Organisation, die ich beraten habe, hatte das Serviceteam über Wochen beobachtet, dass der Bot bei einem bestimmten Vertragsthema falsche Informationen gibt. Es war gemeldet worden. Es lag im Backlog des KI-Teams. Drei Wochen lang hat der Bot weiter falsche Zusagen gemacht, die das Serviceteam anschließend manuell korrigieren musste.

Was fehlte, war eine Eskalationsarchitektur mit klaren Befugnissen. Ein Stufenmodell, das regelt, wer bei welchem Schweregrad was tun darf:

Stufe 1 - Unsicherheitserkennung: Der Bot erkennt, dass er sich unsicher ist, und leitet proaktiv an den Menschen weiter. Das ist eine Konfigurationsfrage, kein menschlicher Eingriff.

Stufe 2 - Schleifenerkennung: Der Bot erkennt, dass er sich wiederholt, und bricht die Interaktion ab mit einer Übergabe an den Service. Auch das ist konfigurierbar.

Stufe 3 - Teamlead-Override: Die Teamleitung im Service kann einen einzelnen Use Case vorübergehend deaktivieren und das KI-Team wird automatisch informiert. Dafür braucht es eine Befugnis und ein technisches Interface, beides muss vorher definiert sein.

Stufe 4 - Kill Switch: Bei schwerwiegenden Fehlern (falsche Zusagen mit Haftungsrelevanz, Massenvorfall, Datenschutzverstoß) wird der Bot komplett abgeschaltet und alle laufenden Gespräche werden an Menschen übergeben. Wer diesen Schalter umlegen darf, muss namentlich dokumentiert sein.

Nicht jeder Bot-Use-Case braucht die gleiche Freiheit. Eine Kontostands-Auskunft hat ein anderes Risikoprofil als eine Vertragsänderung. Ein FAQ-Bot, der Öffnungszeiten nennt, arbeitet in einer anderen Risikoklasse als ein Bot, der Gutschriften auslöst oder Vertragslaufzeiten verkürzt.

Was sich in der Praxis bewährt: Ein Tiering-Modell, das Bot-Aktionen nach Risiko klassifiziert und die Autonomie entsprechend begrenzt.

In Tier 1 (Information Only) darf der Bot Informationen ausgeben, aber keine Aktionen auslösen. Kontostand, Lieferstatus, FAQ. Hier ist das Fehlerrisiko gering und die Autonomie hoch.

In Tier 2 (Guided Action) darf der Bot einfache Standardaktionen auslösen, etwa eine Adressänderung oder die Zusendung eines Dokuments. Die Aktion wird ausgeführt und die Kundin erhält eine Bestätigung. Bei Unsicherheit leitet der Bot an den Menschen weiter.

In Tier 3 (Human Approval Required) darf der Bot eine Empfehlung vorbereiten, aber die Ausführung erfordert eine menschliche Freigabe. Vertragsänderungen, Gutschriften über einem Schwellenwert, Kündigungen. Der Bot macht den Vorschlag, die Servicemitarbeiterin entscheidet.

In Tier 4 (Human Only) darf der Bot nur weiterleiten. Haftungsrelevante Themen, Beschwerden, alles, was eine individuelle Bewertung erfordert. Der Bot sammelt den Kontext und übergibt sauber.

Die Standardmetriken (Containment, AHT, CSAT) reichen für die KI-Steuerung nicht aus. Was zusätzlich gemessen werden sollte:

AI-Failure-Demand-Anteil: Wie viel des menschlichen Kontaktvolumens wird durch den Bot erzeugt oder verschlimmert? Das erfordert eine Markierung im Ticketsystem, ähnlich wie bei klassischem Failure Demand: Wurde der menschliche Kontakt durch einen vorausgegangenen Bot-Kontakt verursacht? Wenn ja, warum? (Bot hat falsch geantwortet, Bot hat nicht verstanden, Bot hat keine Übergabe angeboten, Kundin hat bewusst eskaliert.)

Recovery-AHT: Wie lange dauern Kontakte, die nach einem gescheiterten Bot-Kontakt beim Menschen landen, im Vergleich zu Kontakten ohne Bot-Vorlauf? Wenn die Recovery-AHT das Doppelte oder Dreifache beträgt, erzeugt der Bot verdeckte Kosten, die in der Containment-Rechnung nicht auftauchen.

Handover-Qualitäts-Score: Kommt die Kundin beim Menschen an mit Kontext oder ohne? Eine einfache binäre Messung (Handover-Paket vollständig ja/nein) reicht für den Anfang. Mittelfristig kann daraus ein Score werden, der die Qualität der Übergabe bewertet.

Diese drei Metriken ergänzen die Containment Rate und bilden zusammen ein belastbareres Bild davon, ob die KI dem Service hilft oder ob sie neue Arbeit erzeugt.

Zwei Besonderheiten im DACH-Raum sind bei der KI-Governance im Kundenservice relevant:

Die EU-KI-Verordnung (EU AI Act) verpflichtet Betreiber von KI-Systemen seit Februar 2025 zur Sicherstellung von KI-Kompetenz (Artikel 4). Das bedeutet: Wer einen Bot im Kundenkontakt einsetzt, muss dokumentieren können, dass die Mitarbeitenden, die mit dem Bot arbeiten, dessen Funktionsweise, Grenzen und Eskalationslogik verstehen. Die Bundesnetzagentur hat dazu ein Hinweispapier veröffentlicht, das Format und Umfang als kontextabhängig beschreibt, aber eine Dokumentationspflicht betont.

Betriebsvereinbarungen sind bei KI-Einsätzen, die das Verhalten der Mitarbeitenden beobachten oder steuern (z.B. Agent Assist, automatische QA, Sentiment-Analyse in Gesprächen), nach §87 BetrVG mitbestimmungspflichtig. In der Praxis heißt das: Bevor ein Bot-Pilot startet, sollte eine Betriebsvereinbarung stehen, die Dashboards, QA-Aufzeichnungen und Monitoring-Grenzen regelt. Organisationen, die das als Bremse betrachten, machen die Erfahrung, dass ein nachgeholter Betriebsratsprozess den Pilot um Monate verzögert. Wer die Betriebsvereinbarung als Designelement begreift und den Betriebsrat früh einbindet, beschleunigt den Prozess statt ihn zu blockieren.

Für Organisationen, die bereits einen Bot im Einsatz haben, sind drei Schritte sofort umsetzbar:

Erstens: Markierung einführen. Bei jedem menschlichen Kontakt, dem ein Bot-Kontakt vorausging, wird im Ticketsystem vermerkt, ob der Bot-Kontakt die Ursache war. Das erzeugt innerhalb von vier Wochen eine erste belastbare Zahl zum AI-Failure-Demand-Anteil.

Zweitens: Recovery-AHT messen. Die AHT für Kontakte mit Bot-Vorlauf getrennt ausweisen und mit der AHT ohne Bot-Vorlauf vergleichen. Die Differenz ist der verdeckte Kostenfaktor.

Drittens: Eskalationsbefugnis klären. Wer darf den Bot für einen einzelnen Use Case stoppen? Ist die Befugnis dokumentiert? Gibt es ein technisches Interface dafür? Wenn die Antwort auf eine dieser Fragen "nein" lautet, ist das die erste Baustelle.

Alles weitere - Handover-Paket standardisieren, Permission Tiers definieren, Handover-Qualitäts-Score einführen - baut darauf auf und kann in den folgenden Wochen und Monaten schrittweise umgesetzt werden.

KI im Kundenservice ist kein Technologiethema. Es ist ein Operations-Thema. Die Frage, ob ein Bot hilft, lässt sich nicht am Containment-Dashboard beantworten, sondern nur am Service-Desk: Wie viel Arbeit erzeugt der Bot, die vorher nicht da war? Wie lange brauchen die Servicemitarbeiter:innen, um Bot-Fehler zu reparieren? Wie gut vorbereitet kommt die Kundin beim Menschen an?

Wer diese Fragen beantworten kann, steuert KI. Wer nur Containment misst, hofft.

Aleksander Grosz ist Interim Manager und Berater für CX, Contact Center und Telesales in Berlin. Mehr unter agrosz.de.

Quellen:

_{Sie erhalten diesen Newsletter, weil Sie sich über newsletter.agrosz.de angemeldet haben.}

_{Verantwortlich für Angebot und Inhalt: Aleksander Grosz, Edmonton-Platz 16, 14513 Teltow, Deutschland | E-Mail: [email protected]}

_{Impressum: https://agrosz.de/impressum | Datenschutz: https://agrosz.de/datenschutz | Nutzungsbedingungen: https://agrosz.de/nutzungsbedingungen}