Kundenservice-Agenten brauchen Wissen, keine Skripte

Ein klassischer Support-Chatbot arbeitet mit einem Entscheidungsbaum: Wenn die Anfrage zu Kategorie A passt, folgt Antwort A. Passt sie zu keiner hinterlegten Kategorie, folgt die Weiterleitung an einen Menschen. Das funktioniert für die immer gleichen, einfachen Fälle und versagt zuverlässig bei allem, was leicht von der Norm abweicht – also bei einem großen Teil der Anfragen, die überhaupt den Weg zum Support finden.

Ein Agent auf Basis eines Sprachmodells arbeitet anders. Er liest die Anfrage, durchsucht die tatsächlich relevanten Quellen – Produktdaten, Bestellhistorie, interne Richtlinien, frühere vergleichbare Fälle – und formuliert eine Antwort oder führt eine Handlung aus: eine Rückerstattung veranlassen, einen Termin verschieben, eine Bestellung stornieren. Der entscheidende Unterschied ist nicht die bessere Sprache. Es ist der Zugriff auf echte, aktuelle Daten statt auf eine feste Liste vorformulierter Antworten. Ein Chatbot kann nur wiederholen, was jemand vorher hineingeschrieben hat. Ein Agent kann nachschauen.

Das Sprachmodell selbst ist mittlerweile Commodity. Die führenden Anbieter liegen in der Qualität für Support-Anwendungsfälle nah beieinander, und der Unterschied zwischen ihnen entscheidet selten darüber, ob ein Kunde zufrieden ist. Was entscheidet, ist, was der Agent sehen darf: die vollständige Bestellhistorie statt eines Auszugs, die aktuelle Rückgaberichtlinie statt einer veralteten PDF-Version, den tatsächlichen Vertragsstatus statt einer Annahme.

Unternehmen, die zuerst in das teuerste verfügbare Sprachmodell investieren und erst danach in den Datenzugriff, kaufen die falsche Priorität. Ein günstigeres Modell mit vollständigem, aktuellem Datenzugriff schlägt ein teures Modell ohne diesen Zugriff in praktisch jedem Fall.

Das gilt auch für den Wechsel zwischen Modellanbietern. Wenn die eigentliche Arbeit in der sauberen Anbindung an Bestellsystem, CRM und Wissensbasis steckt, lässt sich das darunterliegende Sprachmodell später austauschen, ohne die gesamte Lösung neu zu bauen. Wer die Architektur so aufbaut, bindet sich nicht an einen einzelnen Anbieter.

Die meisten Support-Organisationen unterschätzen, wie viel ihres tatsächlichen Wissens nirgends dokumentiert ist. Es steckt in den Köpfen erfahrener Mitarbeitender, die seit Jahren die Ausnahmefälle kennen, aber nie aufgeschrieben haben, wie sie entschieden werden. Parallel dazu existieren oft mehrere, widersprüchliche Versionen derselben Richtlinie in unterschiedlichen Ablagen, weil niemand die alte Version entfernt hat, als die neue entstand.

Diese Lücken vor dem Start eines Agenten zu schließen, ist keine bürokratische Vorübung. Es ist die eigentliche Arbeit. Ein Agent, der auf eine veraltete oder widersprüchliche Wissensbasis zugreift, produziert selbstbewusst falsche Antworten – und das schneller und in größerem Umfang, als ein einzelner Mitarbeiter es je könnte.

In der Praxis lohnt sich deshalb ein bewusster Zwischenschritt: die relevanten Dokumente für die geplante erste Kategorie gemeinsam mit den erfahrensten Support-Mitarbeitenden durchzugehen, bevor der Agent auch nur ein einziges Mal live geschaltet wird. Diese Sitzungen dauern selten länger als wenige Tage, decken aber zuverlässig die Widersprüche und Lücken auf, die sonst erst durch falsche Antworten beim Kunden sichtbar würden.

Der Reflex, den Agenten zuerst auf die schwierigste, teuerste Anfragekategorie anzusetzen, ist verständlich – dort scheint der größte Hebel zu liegen. In der Praxis ist das der falsche Startpunkt. Schwierige Kategorien haben meist auch die unvollständigste Dokumentation und die meisten Ausnahmen. Der Agent scheitert früh, das Vertrauen im Team sinkt, und die Einführung insgesamt gerät in Verruf.

Der bessere Startpunkt ist eine Kategorie mit hohem Volumen und guter Dokumentation: Bestellstatus, Rückgabebedingungen, einfache Vertragsänderungen. Dort lässt sich in kurzer Zeit zeigen, dass der Agent zuverlässig funktioniert. Diese frühe, sichtbare Zuverlässigkeit ist die Grundlage dafür, den Umfang schrittweise auf komplexere Fälle auszuweiten.

Die Ausweitung selbst sollte nach demselben Muster erfolgen wie der Start: eine weitere Kategorie, nicht alle verbleibenden auf einmal. Jede neue Kategorie bringt eigene Ausnahmen und eigene Lücken in der Dokumentation mit sich. Wer mehrere Kategorien gleichzeitig hinzufügt, verliert den Überblick darüber, welche Änderung welchen Effekt hatte, wenn die Qualität in einer Kategorie plötzlich absinkt.

Ein produktiver Kundenservice-Agent braucht klare Eskalationsregeln: ab welcher Unsicherheit des Modells, bei welchen Themen und bei welchem Auftragswert ein Mensch entscheidet. Diese Regeln zu definieren ist Aufgabe der erfahrensten Personen im Team, nicht der IT – sie kennen die Grenzfälle, die im Handbuch nie standen.

Damit verschiebt sich auch die Rolle des Support-Teams. Weniger Zeit für die immer gleichen Standardanfragen, mehr Zeit für die Pflege der Wissensbasis, die Prüfung von Eskalationen und die komplexeren Fälle, die tatsächlich menschliches Urteilsvermögen brauchen. Das ist selten eine Reduktion der Teamgröße von heute auf morgen – es ist eine Verschiebung der Arbeit hin zu dem, was einen Menschen tatsächlich braucht.

Diese Verschiebung braucht Führung, nicht nur Technik. Mitarbeitende, die jahrelang nach Anzahl bearbeiteter Tickets bewertet wurden, brauchen eine neue, ebenso klare Definition davon, woran gute Arbeit jetzt gemessen wird. Wird diese Frage nicht beantwortet, entsteht Unsicherheit, die die Einführung insgesamt verlangsamt – unabhängig davon, wie gut der Agent technisch funktioniert. Wer diese neue Definition frühzeitig und offen kommuniziert, nimmt dem Projekt einen Großteil des internen Widerstands, bevor er überhaupt entsteht.

Die Selbstlösungsquote allein ist eine schwache Metrik – sie steigt auch, wenn der Agent Kunden mit unvollständigen Antworten abspeist, die später erneut anfragen. Aussagekräftiger sind die Erstlösungsquote über beide Kanäle hinweg, die Kosten pro Kontakt, und die Veränderung der Kundenzufriedenheit für die Kategorien, in denen der Agent aktiv ist.

Wer Personalentscheidungen an den Agenten koppelt, sollte das erst tun, nachdem diese Metriken über einen belastbaren Zeitraum stabil geblieben sind – nicht auf Basis der ersten vielversprechenden Wochen nach dem Start. Die ersten Wochen zeigen vor allem, ob der Agent grundsätzlich funktioniert, nicht, ob er das bei saisonalen Spitzen oder ungewöhnlichen Anfragen auch weiterhin tut.

Ein Agent, der auf Bestell- und Vertragsdaten zugreift, verarbeitet in der Regel personenbezogene Daten im Sinne der DSGVO. Das ist kein Grund, auf den Zugriff zu verzichten – ohne ihn bleibt der Agent wirkungslos –, aber ein Grund, Protokollierung von Anfang an mitzubauen: welche Daten wurden abgerufen, welche Entscheidung wurde getroffen, wer kann das im Nachhinein prüfen. Diese Protokollierung nachträglich einzuziehen ist deutlich aufwendiger, als sie von Beginn an vorzusehen.

Dieselbe Protokollierung zahlt doppelt: Sie erfüllt die Nachweispflicht gegenüber Datenschutzbeauftragten und liefert gleichzeitig die Datengrundlage, um zu verstehen, warum der Agent in einem konkreten Fall falsch entschieden hat. Ohne sie bleibt jede Fehleranalyse eine Vermutung.

Ein verbreitetes Muster bei schnell eingeführten Lösungen ist der Agent, der Anfragen zwar klassifiziert, aber kaum selbst löst – ein aufwendig gebauter Router statt eines Bearbeiters. Er wirkt in der Demo beeindruckend, entlastet das Team im Alltag aber kaum, weil die eigentliche Arbeit weiterhin bei Menschen liegt.

Der Wert eines Agenten liegt in der Lösung, nicht in der Kategorisierung. Eine nützliche Prüffrage vor jedem Rollout: Wie viele Anfragen verlassen den Agenten mit einer abgeschlossenen Handlung, nicht nur mit einer Weiterleitung?

Dieses Muster entsteht meist aus Vorsicht: Wer dem Agenten keine Handlungsrechte gibt, kann auch keine falschen Handlungen auslösen. Das ist eine verständliche erste Stufe, aber keine, in der ein Unternehmen dauerhaft bleiben sollte. Die richtige Antwort auf die Vorsicht ist, die Handlungen des Agenten eng zu begrenzen und mit Eskalationsregeln abzusichern, bis Vertrauen in einem größeren Umfang entstanden ist. Ein Agent, der eine Rückerstattung bis zu einem festgelegten Betrag selbstständig auslösen darf und darüber hinaus eskaliert, ist ein guter Zwischenschritt zwischen reinem Router und vollständiger Autonomie.