Warum die meisten Unternehmens-Chatbots enttäuschen — und was man stattdessen bauen sollte

Ein Unternehmen kauft einen Chatbot

Ein Unternehmen erwirbt einen Chatbot, der auf der Website oder im internen Hilfsportal eingesetzt wird. Für zwei Wochen versuchen es die Mitarbeiter damit. Bis zum dritten Monat nutzen nur noch ein paar neugierige Mitarbeiter und gelegentlich Kunden, die die Telefonnummer nicht finden können, den Chatbot.

Dieses Phänomen tritt häufig genug auf, dass man die Ursache benennen sollte. Es liegt nicht am Modell. Die heute verfügbaren Modelle sind viel besser als die darauf basierenden Implementierungen. Der Fehler liegt in der Form des Chatbots.

Ein Chatbot antwortet; ein Unternehmen schließt

Wenn man fragt, wofür der Chatbot da ist, bekommt man meist Antworten wie: "Er beantwortet Fragen zu unseren Produkten" oder "Er hilft Mitarbeitern bei der Suche nach Richtlinien." Das klingt nützlich. Es ist es aber nicht wirklich.

Niemand hat die Aufgabe, eine Antwort zu erhalten. Jemand ist dafür verantwortlich, eine Rückerstattung zu gewähren, einen Kaufauftrag zu genehmigen, eine Installation neu zu planen, einen Garantiefall zu bestätigen oder einen Vertrag an den Rechtsbereich weiterzuleiten. Eine Antwort ist der Mittelpunkt dieser Aufgabe. Ein System, das sich nach der Antwort aufgibt, gibt die Arbeit an die Person zurück, die sie ursprünglich abgeben wollte.

So verläuft die Interaktion: Der Kunde fragt nach seiner verzögerten Bestellung, der Bot erklärt die Versandrichtlinie, und der Kunde bittet um einen menschlichen Ansprechpartner, weil die Richtlinie nie das Problem war. Der Bot hat seine Aufgabe erfüllt und ist dennoch gescheitert.

Die drei Arten des Scheiterns

Die meisten enttäuschenden Implementierungen weisen einige Gemeinsamkeiten auf:

Kein Zugriff auf Live-Systeme. Der Bot wurde mit Dokumenten trainiert. Die Frage des Kunden bezieht sich auf seine Bestellung, seine Rechnung oder sein Konto. Ein Bot, der keinen Zugriff auf das Bestellsystem hat, kann nur allgemeine Aussagen treffen, und diese sind bereits auf der FAQ-Seite gemacht worden.
Keine Handlungsfähigkeit. Selbst wenn er die Antwort kennt, kann er die Aufgabe nicht ausführen. Jede Konversation endet in einer Weiterleitung, sodass er einen Schritt hinzufügt, anstatt ihn zu entfernen.
Keine Definition von "erledigt". Niemand hat im Voraus vereinbart, was ein gutes Ergebnis ausmacht, also kann niemand sagen, ob es funktioniert. Die Nutzungszahlen steigen, der Kontaktzentrum-Volumen sinkt nicht, und das Projekt wird stillschweigend nicht mehr diskutiert.

Hinter all dem steckt eine Entscheidung: Das Projekt wurde als Kanal definiert - ein neuer Ort, um mit dem Unternehmen zu sprechen - anstatt als Kapazität, um mithilfe derselben Personen mehr Arbeit zu erledigen.

Einen Aufgaben-Erfüller bauen

Der Alternativansatz ist nicht komplexer. Er ist enger und tiefer.

Wähle eine hochvolumige Aufgabe aus. Nicht ein Thema, sondern eine Aufgabe - "eine Lieferung neu planen", nicht "Logistikfragen". Etwas, das monatlich hunderten Male passiert und einem bekannten Ablauf folgt.

Gib dem System die beiden Dinge, die es braucht, um diese Aufgabe tatsächlich zu erledigen: Lesezugriff auf die Systeme mit der Wahrheit und Schreibzugriff auf eine oder zwei Aktionen, die für die Aufgabe erforderlich sind. Wenn es die Lieferung nachschlagen, echte Zeitfenster anbieten und die Buchung ändern kann, hat es einen Anruf ersetzt. Wenn es nur die Reschedulierungsrichtlinie beschreiben kann, hat es nichts ersetzt.

Dann entscheide, was es tut, wenn es die Aufgabe nicht erledigen kann. Dies ist der Teil, den die meisten Projekte auslassen, und er tut mehr für das Vertrauen als jede Menge Modellabstimmung. Definiere die Bedingungen, unter denen es aufgibt und an einen Menschen weiterleitet - niedrige Zuverlässigkeit, ungewöhnlicher Kontozustand, alles rund um Geld über einem Schwellenwert - und mache die Weiterleitung den vollen Kontext mit, damit der Kunde sich nicht wiederholen muss. Ein System, das 60% der Fälle sauber abschließt und die restlichen 40% mit einer prägnanten Zusammenfassung an einen Menschen weiterleitet, schlägt eines, das 100% versucht und davon ein Fünftel falsch macht.

Schließlich vereinbare vor dem Bau eine Zahl oder zwei. Prozentsatz der Reschedulierungsanfragen, die ohne menschliche Hilfe abgeschlossen werden; durchschnittliche Bearbeitungszeit für diejenigen, die es nicht schaffen; Rückrufquote innerhalb von 48 Stunden. Eine oder zwei Zahlen, gemessen im Vergleich zum Monat vor der Einführung. Wenn sie sich nicht verbessern, hast du etwas Günstiges und Frühes gelernt.

Was dies mit dem Plan ändert

Auf diese Weise zu definieren macht das Projekt kleiner und die Integrationsarbeit größer, was für jeden unangenehm ist, der einen Chatbot erwartet hat, der sich in zwei Wochen konfigurieren lässt. Die konversatorische Schicht ist jetzt die einfache. Die Arbeit liegt in Berechtigungen, Systemzugriff, Audit-Pfad und Eskalationsweg - das unglamourige Plomberiewerk, das entscheidet, ob das Ding irgendwelche Lasten tragen kann.

Das ist auch der Grund, warum eng besser als breit ist. Eine Aufgabe vollständig erledigt, verdient das Recht, die zweite hinzuzufügen. Ein System, das vierzig Themen flach abdeckt, verdient nichts, weil es keine einzelne Aufgabe gibt, auf die jemand verweisen und sagen kann: Das hat früher vier Minuten gedauert, und jetzt nicht mehr.

Wir bauen den zweiten Typen. Der erste Typ ist leichter zu starten und viel schwieriger zu warten.