Chatbot-Workflow: So gestaltest du einen, der Tickets löst

Was ein Chatbot-Workflow eigentlich ist

Entkleidet man einen Chatbot, bleiben zwei Dinge übrig: eine Gesprächsoberfläche und die darunterliegende Logik, die entscheidet, was als Nächstes passiert. Diese Logik ist der Workflow, und sie ist der eigentliche Motor hinter jeder Kundenservice-KI. Tidio bringt es in seinem Leitfaden zu Gesprächs-Flussdiagrammen klar auf den Punkt: Chatbots seien "wenig mehr als Entscheidungsbaum-Diagramme mit einer Gesprächsoberfläche".

Das stimmt für die Form eines Workflows, aber das Interessante ist, was jeden Knoten füllt. Ein Workflow ist nicht nur "wenn der Nutzer auf A klickt, geh zu B". Ein guter Workflow muss eine Nachricht verstehen, die er noch nie gesehen hat, die richtige Antwort in einer Wissensdatenbank finden und den Unterschied kennen zwischen einer Frage, die er sicher abschließen kann, und einer, die er nie anfassen sollte. Die Karte ist der einfache Teil. Das Urteilsvermögen innerhalb jedes Schritts entscheidet über Erfolg oder Misserfolg eines Chatbot-Workflows.

Hier ist das Ganze auf einen Blick, danach gehe ich jede Stufe durch.

Die sechs Stufen eines Support-Chatbot-Workflows

Fast jeder Support-Chatbot-Workflow, ob regelbasiert oder KI-gestützt, durchläuft dieselben sechs Stufen. Sie zu benennen macht sofort klar, wo der eigene Workflow schwach ist.

1. Auslöser. Etwas setzt den Workflow in Gang: Ein Kunde öffnet die Chat-Blase, schickt eine E-Mail, schreibt über WhatsApp, oder ein neues Ticket landet im Helpdesk. Der Auslöser bringt auch Kontext mit, den man später braucht, etwa den Kanal, die Bestellhistorie des Kunden oder auf welcher Seite er war.
2. Absicht verstehen. Der Bot findet heraus, was die Person wirklich will. Ein regelbasierter Flow macht das über Buttons und Schlagworte; ein KI-Workflow liest den Freitext direkt, sodass "mein Paket ist immer noch nicht angekommen" und "wo ist meine Bestellung" auf dieselbe Absicht treffen, ohne dass eine der beiden Formulierungen eingeplant wurde.
3. Wissen abrufen. Der Bot sucht die Antwort in einem Hilfecenter, vergangenen Tickets, internen Dokumenten oder einem Live-System wie einer Bestelldatenbank. Das ist die Stufe, die die meisten Demos überspringen und an der die meisten echten Workflows scheitern oder bestehen: Ein Bot ohne Grundlage erfindet einfach etwas.
4. Entscheiden und verzweigen. Mit Absicht und Antwort in der Hand wählt der Workflow einen Pfad: direkt antworten, eine Rückfrage stellen, eine Aktion ausführen oder eskalieren. Das ist das Gehirn des Workflows, und hier gehört die Konfidenzprüfung hin.
5. Handeln. Bei einfachen Fragen ist die "Aktion" nur die Antwort. Für echte Lösungen bedeutet es, etwas zu tun: eine Bestellung nachschlagen, eine Rückerstattung ausstellen, ein Ticket taggen und weiterleiten, ein Feld aktualisieren. Ein Workflow, der nur reden, aber nie handeln kann, kommt maximal bis zur Ablenkung und erreicht nie eine Lösung.
6. Lösen oder eskalieren. Das Gespräch endet auf eine von zwei Arten: Der Bot löst es, oder er übergibt es sauber an einen Menschen, mit dem vollständigen Kontext im Gepäck. Eine Übergabe, die den Kunden in eine neue Warteschlange wirft, in der er alles neu erklären muss, ist keine Übergabe, sondern eine Strafe.

So sehen die Stufen 2 bis 6 in einem echten Produkt aus, nicht in einem Diagramm: Der Kunde fragt, der Agent antwortet aus verbundenem Wissen, und in dem Moment, in dem er nicht weiterhelfen kann, bietet er einen Menschen an.

Ich habe genau diesen Ablauf kürzlich im Live-Chat der Website eines SEO-Tools beobachtet: Der Bot beantwortete zwei Anleitungsfragen aus der Dokumentation, und in dem Moment, in dem der Nutzer "kann ich mit einem Menschen sprechen?" eintippte, übergab er ohne Zögern. Diese saubere Kombination aus Ablenkung und Übergabe zeigt, wie ein gesunder Workflow in freier Wildbahn aussieht, und ist das Muster, auf das man hinarbeiten sollte.

Regelbasierte vs. KI-Agenten-Workflows

Die wichtigste Entscheidung, die man trifft, ist keine Stufe, sondern welche Art von Workflow man baut. Beide sehen auf einem Whiteboard ähnlich aus und verhalten sich im Produktivbetrieb völlig unterschiedlich.

Ein regelbasierter Workflow ist ein Entscheidungsbaum, den man von Hand zeichnet. Er ist vorhersehbar und einfach zu durchdenken, und für einen engen, hochvolumigen Flow ("meinen Bestellstatus prüfen" hinter drei Buttons) ist er wirklich in Ordnung. Die Falle ist alles außerhalb des Skripts, und die Mathematik dahinter ist brutal: Tidio weist darauf hin, dass ein "einfacher" Baum aus nur sieben Ja/Nein-Fragen bereits in 128 mögliche Szenarien verzweigt, weshalb ihre eigene Regel lautet: "ein Entscheidungsbot, ein Thema". Geht man darüber hinaus, tippt der Kunde etwas, das man nicht vorhergesehen hat, und der Bot hat nirgendwo hin, ihn zu schicken, die klassische Sackgasse im Flussdiagramm. Man landet dabei, einen ständig wachsenden Baum zu pflegen und jedes Mal einen neuen Zweig hinzuzufügen, wenn eine neue Formulierung auftaucht, und trotzdem hält er nicht Schritt mit dem, wie Menschen tatsächlich schreiben.

Ein KI-Agenten-Workflow kehrt den Aufwand um. Statt jeden Pfad selbst aufzuzählen, liest der Agent die Absicht aus Freitext, ruft die Antwort aus dem eigenen Wissen ab und entscheidet, was zu tun ist, einschließlich zu erkennen, wann er an seine Grenzen stößt. Man zeichnet keine Zweige mehr, sondern setzt Leitplanken.

Das ist kein "Regeln sind tot"-Argument. Viele gute Workflows nutzen Regeln für die deterministischen Teile (Geschäftszeiten, eine erforderliche Bestellnummer) und überlassen das unscharfe Sprachverständnis der KI. Aber wer einen Support-Workflow baut und erwartet, das gesamte Spektrum dessen abzudecken, was Kunden schreiben, wird mit einem reinen Entscheidungsbaum ewig kämpfen. Aus demselben Grund wechseln Teams mit steigendem Volumen von skriptierten Bots zu einem echten KI-Agenten.

Die zwei Entscheidungspunkte, die wirklich zählen

Sobald eine KI das Sprachverständnis übernimmt, reduziert sich die eigene Gestaltungsarbeit auf zwei Fragen: Wann sollte der Bot eigenständig handeln, und wann sollte er sich zurückziehen? Trifft man das richtig, kümmert sich der Rest des Workflows fast von selbst.

Nach Konfidenz routen, nicht nach Schlagworten

Die am häufigsten gewünschte Kontrolle, die ich von Support-Teams höre, ist konfidenzbasiertes Routing: den Bot nur das bearbeiten lassen, dessen er sich sicher ist, und den Rest in Ruhe lassen. Eine CX-Leiterin bei einer DTC-Nahrungsergänzungsmarke, die bei Gorgias rund 7.000 Tickets pro Monat abwickelt, brachte die Sorge besser auf den Punkt, als ich es könnte. Die KI werde nie 100 % der Fragen beantworten, sagte sie mir, und wenn sie einfach nur "sorry, das weiß ich nicht" antworte, könne sie nicht 7.000 Tickets zurückverfolgen, um zu sehen, ob es wirklich geholfen hat. Was sie wollte, war eine KI, die "nur die Tickets bearbeitet, bei denen sie sich sicher ist, und alle anderen in Ruhe lässt".

Das ist das gesamte Argument dafür, in der Entscheidungs- und Verzweigungsstufe die Konfidenz zu bewerten. Ein Workflow, der alles beantwortet, ist ein Workflow, der selbstsicher Fehler macht. Ein Workflow, der die eigene Sicherheit bewertet, kann einfache Tickets automatisch lösen, bei mittleren Fällen einen Antwortentwurf für einen Menschen erstellen und die Fälle, die er nicht versteht, nie anfassen.

Das ist auch die beste Verteidigung gegen Halluzinationen. Statt darauf zu hoffen, dass sich das Modell richtig verhält, setzt man eine Untergrenze: Unterhalb eines Schwellenwerts entwirft der Bot statt zu senden, oder eskaliert statt zu raten. Der Intent-Konfidenz-Schwellenwert ist in ausgereiften Tools ein echter Regler, keine Abstraktion.

Die Eskalation gestalten, nicht nachträglich anflicken

Der andere Entscheidungspunkt ist die Übergabe an einen Menschen, und sie verdient genauso viel Gestaltung wie der Idealpfad. Ich höre das Ziel in Verkaufsgesprächen fast immer identisch formuliert: Ein Support-Manager bei einem Bus-Tracking-Dienst, der monatlich 200 bis 250 Zendesk-Tickets bearbeitet, wollte einen Agenten, der "60 % der eingehenden Zendesk-Tickets bearbeitet und weiß, wann eine echte Person für eine bessere Analyse und Lösung hinzugezogen werden muss". Die Hälfte mit "wissen, wann eine echte Person hinzugezogen werden muss" ist die wichtige Hälfte.

Eine gute Eskalation trägt das gesamte Gespräch, den Kontext des Kunden und die beste Vermutung des Bots zum Problem direkt zum richtigen Menschen oder zur richtigen Warteschlange, sodass niemand irgendetwas neu erklären muss. Deshalb behandeln ausgereifte Anbieter die Übergabe als einen finalen Schritt mit echter Nutzlast: Im Zendesk-KI-Agenten-Builder ist "an Agent übergeben" ein Endschritt, der still ein Ticket mit dem gesamten Gesprächsverlauf erstellt, das der Kunde nie sieht. eesel macht dasselbe, indem es je nach Einrichtung eine entworfene Antwort und den Kontext als interne Notiz hinterlässt oder an den Helpdesk übergibt.

Man will auch Kontrolle darüber, was der Bot anfassen darf. Echte Teams verlangen das ständig ("es gibt bestimmte Tickets, die ich nicht durch die KI laufen lassen will"), und ein Workflow, der einen Ticket-Typ nicht ausschließen kann oder nur bei expliziter Aufforderung handelt, ist nicht bereit für eine Live-Warteschlange. Eskalation ist kein Fallback, sondern ein vollwertiger Zweig. Unsere ausführliche Betrachtung zu KI-Agenten-Eskalationen geht tiefer auf die Mechanik ein.

Häufige Fehler bei Chatbot-Workflows

Kunden können einen kaputten Workflow besser beschreiben als jede Spezifikation. Ein r/automation-Thread traf die Symptome genau:

"the tells: loop you back to FAQ, ask you to rephrase (3 times), refuse to escalate. the fix isn't a smarter chatbot. it's a chatbot that knows when to hand off."

Die meisten kaputten Workflows scheitern auf dieselbe Handvoll Arten. Achte auf Folgendes:

• Sackgassen. Der klassische regelbasierte Fehler. Jeder Pfad sollte irgendwohin führen, auch wenn "irgendwohin" ein Mensch ist. Wenn ein Zweig einen Kunden ohne Weg nach vorn festhalten kann, ist das ein Bug.
• Übermäßige Automatisierung. Den Bot alles beantworten zu lassen, um eine Ablenkungszahl zu jagen. So entstehen selbstsichere Falschantworten in großem Maßstab. Beschränke den Bot auf das, wessen er sich sicher ist.
• Keine Wissensgrundlage. Ein Workflow mit einem tollen Entscheidungsbaum, aber ohne etwas, woraus er abrufen kann, wird improvisieren, und improvisierte Support-Antworten sind der Weg zu einem Screenshot in den sozialen Medien. Verankere jede Antwort in echten Dokumenten und vergangenen Tickets.
• Eskalation als nachträglicher Einfall. Übergabe an eine kalte Warteschlange, in der der Kunde alles neu erklären muss. Trage den Kontext mit.
• Blind ausrollen. Einen Workflow bei echten Kunden loslassen, ohne ihn je an den Nachrichten getestet zu haben, die er tatsächlich erhalten wird. Das führt uns zum letzten und am häufigsten übersprungenen Schritt.

Den Workflow testen, bevor er live geht

Hier ist der Teil, den fast niemand macht, und der Grund, warum ich ihn in jeden Rollout einbaue: den Workflow an echten historischen Tickets laufen lassen, bevor er mit einem Kunden spricht. Ich habe das auf die harte Tour gelernt, als ich zusah, wie ein selbstsicher klingender Bot leise falsche Antworten gab, deshalb macht jeder neue Agent jetzt zuerst eine Simulation über vergangene Tickets, kein Live-Gespräch.

Eine Simulation spielt Tausende deiner abgeschlossenen Tickets durch den Workflow ab und zeigt genau, was er gesagt hätte, welchen Prozentsatz er gelöst hätte und bei welchen Themen er schwach ist, alles bevor er live geht. Man findet die Lücken, fügt die fehlenden Dokumente hinzu, passt den Konfidenz-Schwellenwert an und lässt es erneut laufen. Das macht aus "wir hoffen, dass es funktioniert" eine Zahl, auf die man zeigen kann, was ungefähr dem Unterschied zwischen einem Workflow entspricht, dem man vertraut, und einem, bei dem man jeden Morgen nervös ist.

Die Auszahlung eines getesteten Workflows zeigt sich schnell. Bei Gridwise löste eesel im ersten Monat 73 % der Tier-1-Anfragen, mit sichtbaren Ergebnissen bereits während einer 7-tägigen Testphase. Smava betreibt einen vollständig automatisierten Agenten über mehr als 100.000 deutsche Tickets pro Monat. Keine dieser Zahlen stammt aus einem glücklichen Prompt; sie stammen aus einem Workflow, der vor dem Livegang an echten Tickets getestet wurde.

eesel für deinen Chatbot-Workflow ausprobieren

Wenn du bis hierhin gelesen hast, siehst du die Arbeit, die ein Chatbot-Workflow verlangt: Stufen abbilden, Antworten verankern, Konfidenz feinjustieren, Eskalation gestalten, alles testen. eesel erledigt diese Arbeit für dich. Du verbindest deinen Helpdesk und deine Dokumente, es baut den Workflow ab Tag eins aus deinen vergangenen Tickets und deinem Wissen auf, du legst in einfacher Sprache fest, wann er eingreift und wie er übergibt, und du simulierst das Ganze an historischen Tickets, bevor ein einziger Kunde es sieht.

Es lässt sich mit Zendesk, Freshdesk, Gorgias, Slack, Shopify, Confluence und über 100 weiteren Tools verbinden, funktioniert von Haus aus in über 80 Sprachen und ist nutzungsbasiert zu 0,40 $ pro Ticket, ganz ohne Gebühr pro Sitzplatz. Dieses Modell fällt tendenziell günstiger aus als Personalkosten, sobald man die Zahlen durchrechnet. Du kannst einen Workflow live in deinem Helpdesk laufen sehen:

Der schnellste Weg herauszufinden, ob ein Chatbot-Workflow zu deiner Warteschlange passt, ist, einen an den eigenen Tickets laufen zu lassen. Das ist eine kostenlose Testversion, ohne Kreditkarte, und die Simulation nennt dir deine echte Lösungsquote, bevor du dich auf irgendetwas festlegst.