Vor ein paar Jahren hatten wir einen Support-Chatbot. Er war teuer, ein spezialisierter Anbieter hatte ihn gebaut, und am Launch-Tag hat er gut funktioniert. Ein Jahr später haben die Leute einen Bogen um ihn gemacht.
Technisch war nichts kaputt. Der Bot hat weiterhin jede Frage beantwortet, schnell und höflich. Das Problem war, dass immer mehr Antworten falsch waren. Die Produkte hatten sich verändert, die Prozesse hatten sich verändert, die Dokumentation war weitergezogen. Der Bot nicht.
Diese Erfahrung ist der Maßstab für jeden Chatbot, den wir seitdem gebaut haben. Und sie hat mir das Wichtigste beigebracht, was ich über Chatbots weiß: Ein Chatbot ist kein Technologieprojekt. Er ist ein Content-Pflegeproblem, das sich als Technologieprojekt verkleidet.
Wie Bots verrotten
Klassische Chatbots bestehen aus vorgeschriebenen Antworten. Jemand schreibt eine Liste mit Fragen und den passenden Antworten, der Anbieter trainiert ein Modell darauf, die Fragen zu erkennen, und los geht’s.
Ab diesem Tag erzeugt jede Veränderung in deinem Unternehmen eine kleine Lücke. Eine neue Produktversion. Ein neuer Rückgabeprozess. Eine Preisänderung. Eine Funktion, die umbenannt wurde. Jede Lücke ist winzig. Niemand ist dafür zuständig, sie zu schließen, denn der Bot war ein Projekt, und das Projekt ist abgeschlossen.
Sechs Monate später erzählt der Bot Kunden selbstbewusst Dinge, die im letzten Frühjahr gestimmt haben. Die Kunden merken es vor dir.
Was sich mit LLMs ändert und was nicht
Moderne Sprachmodelle verändern eine Sache grundlegend: Du musst keine Antworten mehr vorschreiben. Du kannst den Bot auf deine Dokumentation ansetzen, und er antwortet von dort. Ändert sich die Dokumentation, ändern sich auch die Antworten.
Klingt, als wäre das Problem mit dem Verrotten gelöst. Es hat sich nur verschoben.
Der Bot ist jetzt genau so gut wie die Dokumentation, die er liest. Ist die Doku veraltet, lückenhaft oder in Worten geschrieben, die deine Kunden nicht verwenden, ist es der Bot auch, nur eloquenter. Wie aktuell deine Wissensdatenbank ist, wird zur eigentlichen KPI deines Chatbots.
Was wir diesmal anders machen
Als wir dieses Jahr den alten Anbieter-Bot durch einen Assistenten auf Basis eines Sprachmodells ersetzt haben, haben wir uns ein paar Regeln gegeben.
Mensch zuerst. Ist jemand aus dem Team online, bekommt der Kunde einen Menschen. Der Bot antwortet nur, wenn niemand verfügbar ist, etwa nachts oder am Wochenende. Er ist ein Sicherheitsnetz, kein Türsteher. Einen Support-Kanal haben wir sogar bewusst ganz ohne KI gestartet, weil die Leute, die ihn nutzen, eher einen Menschen brauchten als eine sofortige Antwort.
Ein Bot, eine Aufgabe. Ein Bot, der Leuten hilft, das Produkt kennenzulernen, und ein Bot, der Fragen vor dem Kauf beantwortet, brauchen unterschiedliche Quellen, eine unterschiedliche Tonalität und unterschiedliche Grenzen. Wir halten sie getrennt und geben jedem einen eigenen Namen, damit Kunden und Team wissen, mit welchem sie gerade sprechen.
Ablehnen statt raten. Vor dem Go-live haben wir den Dokumentations-Bot mit 200 echten Support-Fragen getestet. Die meisten Antworten waren teilweise richtig, ein paar waren falsch, und eine war eine echte Halluzination. Deshalb hat der Bot jetzt eine Konfidenzschwelle: Deckt die Dokumentation eine Frage nicht eindeutig ab, sagt er das und übergibt. Mehr dazu habe ich in Mach deine KI widersprechbar geschrieben.
Sprich die Sprache der Kunden. Kunden beschreiben Symptome, Dokumentation beschreibt Funktionen. Als wir jeder Suche das Vokabular der Dokumentation selbst hinzugefügt haben, hat sich die Zahl der Kundenformulierungen, die der Bot beantworten konnte, in unseren Tests ungefähr verdoppelt. Das ist keine Verbesserung am Modell. Es ist eine Verbesserung am Content.
Jede Antwort kann bewertet werden. Daumen hoch, Daumen runter, mit Begründung. Die Bewertungen verbessern nicht nur den Bot, sie zeigen auch auf die Artikel, die Arbeit brauchen.
Der Fehler, mit dem niemand rechnet
Noch eine Geschichte, weil man so etwas nur lernt, wenn man einen Bot im Echtbetrieb laufen lässt.
An einem seiner ersten Tage hat unser Bot plötzlich innerhalb von Sekunden Hunderte Anfragen an das Chat-System geschickt. Die Ursache war ein einziges Konfigurationsdetail: Die Antwort „Da kann ich nicht helfen, ich leite dich weiter“ saß an einer Stelle, an der das Chat-System sie als neue Frage behandelte. Der Bot hat auf seine eigene Weiterleitungsnachricht geantwortet, was eine weitere Weiterleitungsnachricht ausgelöst hat, und so weiter.
Für die Kunden ist nichts Schlimmes passiert, und die Lösung war eine Zeile. Aber es ist eine gute Erinnerung: Ein Bot ist ein System, das mit anderen Systemen spricht, und diese Systeme haben ihre eigene Logik. Schau in den ersten Wochen genau hin.
Wem gehört der Bot?
Das ist die Frage, die entscheidet, ob ein Bot verrottet.
Die falsche Antwort lautet: „Der Person, die ihn gebaut hat.“ Diese Person wechselt zum nächsten Projekt, und der Bot wird zum Waisenkind.
Die richtige Antwort lautet: „Dem Team, dessen Wissen er weitergibt.“ Bei uns sind das die Leute, die die Dokumentation schreiben und pflegen, gemeinsam mit dem Support. Sie sehen die Daumen runter. Sie sehen, welche Fragen der Bot abgelehnt hat. Sie verbessern die Artikel, und der Bot wird besser, ohne dass jemand den Bot selbst anfasst.
Eine Checkliste, bevor du einen Bot startest
- Wer hält das Wissen aktuell? Nenn ein Team, keine Person.
- Mensch zuerst oder Bot zuerst? Entscheide das bewusst, pro Kanal.
- Eine Aufgabe pro Bot. Getrennte Bots für getrennte Zwecke.
- Eine Konfidenzschwelle. Ablehnen statt raten.
- Bewertungen mit Begründung, weitergeleitet an die Leute, denen der Content gehört.
- Schau in den ersten Wochen genau hin. Bots, die mit Systemen sprechen, machen überraschende Dinge.
Ein Chatbot verrottet nicht, weil die Technologie schlechter wird. Er verrottet, weil sich niemand dafür verantwortlich fühlt, was er weiß. Löst du das, ist die Technologie der einfache Teil.