Was mich ein gescheiterter Chatbot-Rollout gelehrt hat

Vor einigen Jahren war ich an einem Virtual-Agent-Rollout beteiligt, der gescheitert ist. Nicht auf die dramatische Art, mit Eskalationen und Schuldzuweisungen. Der Bot funktionierte, die Topics waren solide gebaut, die Integration sauber. Er scheiterte leise: Die Nutzung erreichte in Woche zwei ihren Höhepunkt und blutete dann aus, bis das Dashboard so aussah, dass man es im Lenkungskreis lieber nicht mehr zeigen wollte.

Ich habe seither viel über dieses Projekt nachgedacht, denn die Technik war zu keinem Zeitpunkt das Problem. Drei Dinge waren es, und alle drei wären vermeidbar gewesen.

Fehler 1: Wir starteten mit einer Ankündigung statt mit einer Gewohnheit

Zum Go-live gab es das volle Programm: ein großer Intranet-Artikel, ein Banner im Portal, sogar Poster in den Büroküchen. Was es nicht gab: irgendeine Veränderung an den bestehenden Kanälen. Die Telefonnummer funktionierte weiter wie immer, das Mail-Postfach auch, und beide waren das, was die Mitarbeiter seit einem Jahrzehnt benutzten.

Gewohnheiten schlagen Ankündigungen, jedes Mal. Ein Plakat erzeugt vielleicht einen Erstversuch, aber der zwanzigste Passwort-Reset läuft über den Kanal, den die Hand von allein wählt. In späteren Projekten haben wir das anders gemacht, zum Beispiel so: Der Service Desk beantwortete niedrig priorisierte Mail-Tickets mit einer freundlichen Notiz, die zeigte, wie der Bot dasselbe Anliegen sofort gelöst hätte, inklusive Link. Langsamer, unglamouröser, aber es hat Verhalten verändert statt nur Aufmerksamkeit erzeugt. Nach drei Monaten kamen messbar mehr Anliegen über den Bot als über die beworbene Portal-Kachel.

Fehler 2: Der Bot war höflich, aber im Long Tail nutzlos

Unsere Top-Topics deckten vielleicht sechzig Prozent der Anliegen ab, und für diese sechzig Prozent war der Bot wirklich gut. Für alles andere entschuldigte er sich freundlich und bot an, ein Ticket zu erstellen.

Aus Nutzersicht hieß das: Münzwurf. Entweder das Ding hilft mir sofort, oder es verschwendet dreißig Sekunden, bevor es das tut, was ich auch selbst gekonnt hätte. Bei diesen Quoten erodiert Vertrauen schnell, und zwar auch bei den Anliegen, die der Bot beherrscht hätte, denn wer zweimal abgewimmelt wurde, fragt kein drittes Mal.

Heute würde ich den Scope anders kommunizieren und anders schneiden. Lieber weniger Einstiegspunkte und eine klare Ansage, was der Bot kann, als die Fassade eines Assistenten, der scheinbar alles versteht und vieles nicht lösen kann. Ehrlichkeit über Grenzen ist beim Bot keine Schwäche, sondern Erwartungsmanagement, und enttäuschte Erwartungen sind teurer als bescheidene.

Fehler 3: Nach dem Go-live gehörte der Bot niemandem

Das Projektteam zog weiter, so sind Projekte nun einmal. Und das Protokoll der nicht erkannten Anfragen, das pure Gold für die Weiterentwicklung eines Bots ist, weil dort wortwörtlich steht, was Nutzer wollten und nicht bekamen, blieb monatelang ungelesen.

Ein Bot ist kein Liefergegenstand, er ist ein Produkt. Produkte brauchen einen Besitzer mit Zeitbudget, einer Routine und der Befugnis, Änderungen umzusetzen. Eine Stunde pro Woche hätte in diesem Fall gereicht, um die fünf häufigsten unerkannten Anliegen zu finden und nachzubauen. Es gab nur niemanden, dessen Aufgabe das gewesen wäre.

Der zweite Anlauf

Das Bittere an dieser Geschichte: Jeder einzelne Fehler war bekannt vermeidbar, und keiner davon hatte mit Software zu tun. Das Ermutigende: Der zweite Anlauf beim selben Unternehmen, zwei Jahre später und mit genau diesen Lektionen, wurde eine der besseren Adoption-Geschichten, die ich begleitet habe. Gleiche Plattform, ähnliche Topics, anderes Vorgehen: Kanal-Steuerung von Tag eins, enger kommunizierter Scope, benannter Product Owner mit fester Pflege-Routine.

Der Unterschied lag nicht im Werkzeug, sondern im Betrieb drumherum. Das ist, glaube ich, die übertragbare Erkenntnis für jedes Self-Service-Vorhaben: Misserfolge sind nur dann teuer, wenn man sich weigert, die Lektion einzusammeln. Und die Lektionen stehen fast nie im Code.