Deflection Rate beim Chatbot: die meistgemessene falsche Zahl
Wenn ein Chatbot-Projekt seinen Erfolg nachweisen soll, fällt fast immer dasselbe Wort: Deflection Rate. Wie viele Anfragen hat der Bot abgefangen, die sonst beim Service Desk gelandet wären? Die Zahl wandert auf das Management-Dashboard, sie sieht meistens gut aus, und alle sind zufrieden.
Klingt vernünftig. Hat nur einen Haken: Die Zahl lässt sich wunderbar schönrechnen, und sie wird es auch regelmäßig, oft ohne böse Absicht.
Wie die Zahl lügt
Das klassische Messverfahren: Jede Bot-Konversation, die nicht in einem Ticket endet, zählt als Deflection. Die Logik dahinter klingt erst einmal plausibel, kein Ticket gleich vermiedener Aufwand.
Aber war das wirklich ein vermiedenes Ticket? Vielleicht hat der Nutzer entnervt aufgegeben und es zehn Minuten später per Telefon versucht, dann taucht derselbe Vorgang doppelt auf, einmal als Erfolg des Bots und einmal als Anruf. Vielleicht hätte er sowieso nie ein Ticket eröffnet, weil die Frage trivial war und er nur neugierig auf das neue Spielzeug. Vielleicht hat er die Antwort bekommen, sie war aber falsch, und das echte Problem schlägt eine Woche später größer auf.
Aus Sicht der Statistik sehen all diese Fälle gleich aus: Konversation beendet, kein Ticket, Deflection. Ein Bot, der Nutzer erfolgreich vergrault, hat eine fantastische Deflection Rate. Das ist keine theoretische Spitzfindigkeit, ich habe Dashboards gesehen, die monatelang Erfolge meldeten, während die Anrufzahlen unverändert blieben.
Die Kennzahlen, die ich stattdessen anschaue
Kein einzelner Wert erzählt die ganze Geschichte, deshalb arbeite ich mit einer Kombination aus vier Blickwinkeln.
Lösungsquote auf Topic-Ebene. Hat der Dialog sein definiertes Ziel erreicht, also Passwort tatsächlich zurückgesetzt, Bestellung tatsächlich ausgelöst, Status tatsächlich geliefert? Das ist pro Topic sauber und automatisch messbar, weil das Ziel ein technisches Ereignis ist. Diese Sicht zeigt außerdem sofort, welche Topics funktionieren und welche nur Verkehr erzeugen, und steuert damit direkt die Weiterentwicklung der Topics.
Wiederkehrende Nutzer. Kommen Leute freiwillig zum zweiten und dritten Mal? Niemand nutzt zweimal einen Bot, der beim ersten Mal nichts gelöst hat. Für mich die ehrlichste Einzelzahl überhaupt, weil sie sich nicht schönreden lässt: Wiederkehr ist gelebtes Vertrauen, und ihr Ausbleiben ist ein Urteil.
Eskalationen mit Kontext. Wenn der Bot an einen Menschen übergibt, kommt der Fall dann mit allen bereits gesammelten Informationen an, oder fängt der Agent von vorn an zu fragen? Eine saubere Übergabe spart dem Service Desk echte Zeit und dem Nutzer echte Nerven, sie ist ein Erfolg. In der reinen Deflection-Logik taucht sie aber als Misserfolg auf, und genau diese Fehlbewertung führt dazu, dass Teams die Übergabequalität vernachlässigen.
Gesamtvolumen je Kanal über die Zeit. Die Schlussrechnung: Am Ende muss sich die Entlastung im Ticketaufkommen und in den Telefonzahlen zeigen, über Monate und um Saisoneffekte bereinigt. Wandern die Anliegen wirklich in den digitalen Kanal, oder verteilen sie sich nur um? Wenn die schönste Bot-Statistik nicht irgendwann in dieser Gesamtsicht ankommt, misst sie etwas anderes als Erfolg.
Die Baseline nicht vergessen
Ein praktischer Hinweis, der in der Projekthektik gern untergeht: All diese Kennzahlen brauchen einen Vorher-Wert. Wie viele Anrufe, Tickets und Bearbeitungsminuten gab es vor dem Bot? Wer die Baseline nicht vor dem Go-live erhebt, kann hinterher nur noch glauben statt wissen. Zwei Wochen Messung vor dem Start ersparen ein Jahr Diskussionen danach.
Deflection als Richtgröße, nicht als Wahrheit
Ich will die Deflection Rate nicht verteufeln. Als grobe Richtgröße im Zeitverlauf, immer gleich gemessen, hat sie ihren Platz. Gefährlich wird sie als alleinige Erfolgsdefinition, denn dann optimiert die Organisation früher oder später genau darauf: Konversationen so zu beenden, dass kein Ticket entsteht. Das ist etwas anderes, als Menschen zu helfen, und der Unterschied fällt irgendwann auf, spätestens wenn die Anrufzahlen nicht sinken wollen.
Miss, ob Anliegen gelöst werden. Miss, ob Menschen wiederkommen. Der Rest ist Dekoration.
Über den Autor
Abbes Ghaddar
Abbes Ghaddar ist ServiceNow Certified Technical Architect (CTA) und schreibt hier über die Now Platform, Conversational AI und den verantwortungsvollen Einsatz generativer KI im Unternehmen.
Ähnliche Beiträge
Was mich ein gescheiterter Chatbot-Rollout gelehrt hat
Die Geschichte eines technisch einwandfreien Virtual Agent, den niemand nutzte: drei vermeidbare Fehler bei Einführung, Scope und Betrieb, und was beim zweiten Anlauf anders lief.
ServiceNow Virtual Agent: Topics bauen, die wirklich genutzt werden
Viele Chatbots beantworten Fragen, die niemand stellt. Wie man die richtigen Virtual-Agent-Topics aus den eigenen Ticketdaten ableitet und in welcher Reihenfolge man sie baut.
Virtual Agent vs. AI Agents: was brauchst du wirklich?
ServiceNow bietet zwei Ansätze für Conversational Automation: geskriptete Virtual-Agent-Topics und autonome AI Agents. Ein Praxisleitfaden für die richtige Wahl und Kombination.