Was tun, wenn der Verkaufsroboter sich irrt

Die ersten drei Minuten, nachdem der Fehler aufgefallen ist

Solange der Dialog in die falsche Richtung läuft, verschlimmert jede weitere Nachricht des Bots die Lage. Der erste Schritt ist, die automatische Antwort zu stoppen und den Deal an einen echten Mitarbeiter zu übergeben, und nicht, die Formulierung direkt im Chat zu reparieren. Das übernimmt dieselbe Mechanik wie die übliche Übergabe eines heißen Kunden: Der Verkaufsroboter kann den Dialog an einen Menschen übergeben, wenn er weiß, dass er ihn übergeben muss.

Der zweite Schritt ist, den Fehler festzuhalten: wem, in welchem Kanal und auf welche Frage die falsche Antwort kam. Ohne diese Notiz wird die Analyse zur Nacherzählung aus dem Gedächtnis, und die Ursache findet sich nur zufällig. Am einfachsten ist ein Screenshot oder ein Link zur Deal-Karte im CRM im Moment der Entdeckung, solange der Verlauf noch nicht nach unten gerutscht ist.

Der dritte Schritt: die Nachricht des Bots nachträglich weder löschen noch bearbeiten. Sie ist der einzige Beleg dafür, was genau schiefgelaufen ist, und ohne sie lässt sich kaum sagen, ob der Bot bei den Fakten, im Ton oder in der Logik der Übergabe an den Mitarbeiter geirrt hat. Eine Analyse ohne das gespeicherte Original beginnt meist von vorn.

Was man dem Kunden nach einem Fehler schreibt

Der Kunde muss nicht verstehen, wo genau der Bot durcheinandergekommen ist — für ihn zählt, was jetzt passiert. Die Formulierung „Entschuldigung, hier hat ein Bot geantwortet, und er hat sich geirrt, unser Mitarbeiter meldet sich gleich bei Ihnen“ wirkt besser als der Versuch, die technische Ursache zu erklären. Das Eingeständnis ohne Ausreden nimmt den Ärger schneller als eine lange Erklärung.

Danach ist es wichtig, einen konkreten nächsten Schritt zu nennen und den Kunden nicht unbestimmt warten zu lassen. „Ein Mitarbeiter meldet sich im Laufe des Tages“ klingt schlechter als „Maria schreibt Ihnen in zehn Minuten“ — wenn diese Zeit auch wirklich zu halten ist. Ein vages Versprechen nach einem bereits passierten Fehler gibt dem Kunden nur einen weiteren Grund zu zweifeln.

War der Fehler bei Zahlen — Preis, Frist, Verfügbarkeit —, sollte die Korrektur als eigene Nachricht kommen und nicht mit der Entschuldigung vermischt werden. Zwei kurze Nachrichten hintereinander liest sich leichter als ein Absatz, in dem Entschuldigung und neue Information in einem Block stehen. Besonders wichtig ist das beim Geld: Verwirrung kostet hier mehr als bei allen anderen Themen.

Wo die Ursache liegt: Prompt, Wissensbasis oder CRM-Anbindung

Fehler des Bots passieren fast immer an einer von drei Stellen, und sie werden unterschiedlich behoben. Die erste ist der Prompt, also die Anweisung, nach der der Bot die Frage versteht und die Antwort bildet: Hat er die Formulierung des Kunden anders verstanden, muss genau die Anweisung präzisiert werden und nicht die Daten drumherum.

Die zweite Stelle ist die Wissensbasis: ein veralteter Preis, eine aus dem Verkauf genommene Leistung, eine falsche Beschreibung der Konditionen. Hier liegt das Problem nicht in der Logik des Bots, sondern darin, dass die Quelle seiner Fakten nicht rechtzeitig aktualisiert wurde. Solche Fehler wiederholen sich bei verschiedenen Kunden gleich — das erste Zeichen dafür, dass es nicht am Prompt liegt.

Die dritte Stelle ist der Werkzeugaufruf im CRM: Der Bot hat aktuelle Daten zum Deal angefragt und keine oder die falschen bekommen. Das ist eine Frage der Integration, nicht des Textes, und zu beheben auf der Ebene der Kanal- und Feldanbindung — beschrieben ist das im Abschnitt über die CRM-Einführung. Diese drei Ursachen in einer Analyse zu vermischen, ist der häufigste Grund dafür, dass der Fehler einen Monat später in anderer Form wiederkommt.

Was mit dem Deal tun, wenn der Kunde sich schon auf den falschen Preis beruft

Zeigt der Kunde den Chatverlauf und sagt „Ihr Bot hat einen Rabatt versprochen“, entscheidet weder Bot noch Skript, sondern ein Mensch mit Befugnis. Es gibt drei Wege: das als einmalige Ausnahme für diesen Deal festhalten, die Differenz teilweise ausgleichen oder mit der Erklärung ablehnen, dass die Information falsch war. Eine universell richtige Variante gibt es nicht — es gibt nur die Frage, was teurer kommt: das einmalige Entgegenkommen oder die beschädigte Beziehung zum Kunden.

Sinnvoll ist, vorab festzulegen, welche Abweichung der Mitarbeiter selbst entscheidet und welche eine Freigabe von oben braucht. Ohne diese Schwelle wird jeder Fall zu einer eigenen Besprechung, während der Kunde auf Antwort wartet. Eine klare Grenze spart Zeit — dem Inhaber wie dem Mitarbeiter.

Mit dem Team sollte man ausdrücklich klären, dass ein bestätigter Fehler des Bots kein Grund ist, dem Mitarbeiter die Schuld zu geben, der den Deal weitergeführt hat. Sonst wird aus der Fehleranalyse eine Schuldsuche statt einer Prozesskorrektur — und beim nächsten Mal wird der Ausfall einfach nicht gemeldet.

Wie solche Fälle nicht verloren gehen und den Bot besser machen

Jeden Fehlerfall sollte man im CRM mit einem eigenen Status oder Tag markieren — etwa „Assistenzfehler“ — direkt auf der Deal-Karte und nicht in einer getrennten Datei, die in einer Woche niemand öffnet. Nach einem Monat lässt sich dann sehen, wie viele solcher Fälle es gab und ob sie sich beim gleichen Thema häufen.

Nützlich ist, den Gesprächsausschnitt selbst an die Karte zu hängen und nicht eine Nacherzählung in eigenen Worten. Die Nacherzählung verliert genau die Details, die man braucht, um zu erkennen, ob Prompt, Wissensbasis oder Integration versagt hat. Eine Analyse aus dem Gedächtnis zwei Wochen später ist fast immer ungenau.

Die gesammelten Fälle sind eine fertige Liste dessen, was beim nächsten Feinschliff in der Wissensbasis oder in der Logik des Bots zu korrigieren ist. Ohne Markierung verteilen sie sich über verschiedene Chats und Mitarbeiter, und aktualisiert wird erst, wenn derselbe Fehler genug Beschwerden auslöst, um aufzufallen.

Was messen, um das Problem vor den Beschwerden zu sehen

Für einen Bot, der Verkauf führt und nicht nur Fragen beantwortet, zählen keine allgemeinen Zufriedenheitswerte, sondern konkrete Zähler. Der Anteil der Dialoge, die als Eskalation an einen Menschen gehen, zeigt, wie oft der Bot selbst merkt, dass er nicht weiterkommt. Ein zu niedriger Anteil ist ein ebenso schlechtes Zeichen wie ein zu hoher: Dann antwortet der Bot entweder aufs Geratewohl, wo er übergeben müsste, oder er belastet die Mitarbeiter mit dem, was er selbst schließen könnte.

Der zweite Zähler ist der Anteil fehlerhafter Antworten in der Stichprobenprüfung der Chats: wie viele zufällig gewählte Dialoge sich bei der Durchsicht als sachlich ungenau erweisen. Das ist keine einmalige Prüfung, sondern eine regelmäßige Stichprobe, sonst veraltet die Zahl schnell. Der dritte ist die Reaktionszeit des Mitarbeiters, nachdem der Bot den Deal übergeben hat: Vergeht zwischen Eskalation und erster menschlicher Antwort zu viel Zeit, geht ein Teil des Sinns der Bot-Geschwindigkeit verloren.

Im laufenden Projekt GetGate war die Antwort des Assistenten im Blindvergleich in 80% der Fälle nicht schlechter als die eines Menschen — das ist ein Anhaltspunkt für eine ähnliche Aufgabe, keine Garantie für jedes Geschäft. Genau diese Prüfung — der Vergleich von Bot- und Menschenantworten an echter Korrespondenz — gehört regelmäßig gemacht und nicht einmalig zum Start. Mehr dazu, wie das im laufenden Betrieb aussieht, im Abschnitt über Qualitätskontrolle.

Wie das in der Praxis aussieht, wenn die Regeln unscharf sind

Häufige Fehlerursache ist kein Ausfall des Bots, sondern eine unscharfe Regel am Eingang. Ist mit der Leitung vereinbart, dass der Bot alle Deals außer den großen und den VIP-Kunden bearbeitet, diese Ausnahmen aber nicht als eigene Regel im CRM stehen, nimmt der Bot früher oder später genau den Deal an, den ein bestimmter Mitarbeiter führen sollte. Der Satz „die bearbeitet vorerst nur ein Kollege“ klingt im Gespräch verständlich, muss aber als Bedingung festgehalten werden und nicht als mündliche Absprache.

Ähnlich ist es beim Wechsel des Kommunikationskanals. Wurde der Kontakt im CRM aktualisiert und schreibt der Kunde jetzt nicht mehr über WhatsApp, sondern über einen anderen Kanal, während die Deal-Karte das nicht abbildet, kann der Bot weiter der Logik des alten Kanals folgen oder den Verlauf verlieren. Solche Wechsel gehören sofort in die Karte und nicht in den Kopf eines einzelnen Mitarbeiters.

Das dritte typische Signal ist die Frage „warum antwortet der Bot gar nicht?“, die meist keinen Fehler im Antworttext bedeutet, sondern eine Störung bei der Kanalanbindung oder der Integration. Sie gehört in dasselbe Störungsprotokoll wie inhaltliche Fehler, denn die Ursache findet man auf demselben Weg: nachsehen, wo genau die Kette gerissen ist — im Kanal, im CRM oder im Bot selbst.

Wie der Prozess aussieht, damit Fehler sich nicht stumm häufen

Die einmalige Korrektur eines Dialogs löst die Aufgabe nicht — einen Monat später taucht ein ähnlicher Fehler in einem anderen Kanal oder bei einem anderen Mitarbeiter auf. Ein stabiler Prozess steht auf drei Dingen: einer klaren Eskalationsregel, der regelmäßigen Stichprobenprüfung der Chats und der Ursachensuche an den drei Stellen — Prompt, Wissensbasis, Integration — statt aufs Geratewohl. Ohne diese Routine hängt die Fehleranalyse an einem aufmerksamen Mitarbeiter und nicht an einem Prozess.

Im Projekt GetGate kommen 27% der Anfragen abends und am Wochenende, wo der Kunde früher bis zum Morgen wartete — genau in diesen Stunden gibt es am wenigsten menschliche Kontrolle, während der Bot ohne Pause arbeitet. Genau dann sind die Eskalationsregel und ein geschriebenes Störungsprotokoll am wichtigsten: Vor Ort fängt niemand den Ausfall ab, wenn er nicht automatisch festgehalten wird.

Die beim Mitarbeiter frei gewordene Zeit — im selben Projekt rund eine Stunde am Tag — sollte nicht darin aufgehen, immer wieder dieselben Fehler des Bots zu zerlegen, sondern in die Durchsicht neuer Fälle und das Feintuning der Regeln. Dann wird Qualitätskontrolle Teil der normalen Arbeit der Abteilung und kein eigener Brand. Muss der Prozess der Fehleranalyse von Grund auf entstehen, ist das eher eine Aufgabe des Vertriebsaufbaus als eine punktuelle Korrektur eines einzelnen Dialogs.