Regelbasierte vs. LLM-Chatbots für die Automatisierung des Kundensupports

Welches Problem lösen wir im Kundensupport?

Die Automatisierung im Kundensupport hat ein praktisches Ziel: mehr Kunden richtig und schneller beantworten, ohne Ihr Team auszubrennen. Das bedeutet, zu entscheiden, welche Anfragen die Software sicher bearbeiten kann und welche an einen Menschen weitergegeben werden müssen.

Chatbots funktionieren am besten, wenn das Kundenziel klar ist und die Schritte standardisiert sind: Bestellstatus, Öffnungszeiten, Passwortzurücksetzungen, Änderung einer Lieferadresse vor dem Versand oder das Erklären von Rückgaberegeln. Das sind häufige, wiederkehrende Gespräche, bei denen Geschwindigkeit wichtiger ist als eine einzigartige, menschliche Note.

Probleme entstehen, wenn der Kunde einen Randfall hat, Richtlinien Ausnahmen zulassen oder wenn die Situation Urteilskraft erfordert. Ein Bot, der selbstbewusst falsche Antworten gibt, kann Geld kosten (Rückerstattungen, Rückbuchungen), Vertrauen zerstören (öffentliche Beschwerden) und Zeit fressen (Agenten, die das aufräumen). Deshalb ist die Debatte um regelbasierte vs. LLM-Chatbots wichtig: es geht um vorhersehbare Ergebnisse, nicht um schicke Formulierungen.

Konsistenz ist wichtiger als clevere Antworten, weil Support Teil Ihres Produkts ist. Kunden wollen dieselbe Antwort, egal mit wem sie sprechen, und Agenten brauchen, dass der Bot die gleichen Regeln befolgt wie sie. Eine „hilfreiche“ Antwort, die gegen die Richtlinie verstößt, ist nicht hilfreich.

Eine praktische Einordnung: entscheiden Sie, was der Bot täglich tun soll. Für die meisten Teams ist das eine Mischung aus: die häufigsten, repetitiven Anfragen vollständig lösen, vor der Übergabe die richtigen Details sammeln, Wartezeiten reduzieren ohne Qualitätsverlust und dabei im Einklang mit Richtlinien und aktuellen Produktinfos bleiben.

Behandeln Sie den Chatbot als einen Schritt im Supportprozess, nicht als den gesamten Prozess. Das gewünschte Ergebnis sind weniger Tickets und weniger Fehler, nicht mehr Unterhaltungen.

Regelbasierte und LLM-Chatbots einfach erklärt

Wenn Leute regelbasierte vs. LLM-Chatbots vergleichen, vergleichen sie zwei verschiedene Arten zu entscheiden, was gesagt wird.

Ein regelbasierter Chatbot folgt einem Skript. Sie definieren Intents (was der Kunde will, z. B. „Passwort zurücksetzen“ oder „Rückerstattungsstatus“), und ordnen jedem Intent einen Entscheidungsbaum zu. Der Bot stellt Fragen, prüft Antworten und geht zum nächsten Schritt. Er ist vorhersehbar, weil er nur sagt, was Sie geschrieben haben.

Ein LLM-Chatbot arbeitet eher wie ein flexibler Texter. Er liest die Kundenmeldung, nutzt den Gesprächskontext und generiert eine Antwort in natürlicher Sprache. Er kann unklare Formulierungen und Mehrfachfragen besser handhaben, kann aber auch raten, zu viel erklären oder von der Richtlinie abweichen, wenn Sie ihn nicht einschränken.

Hybride Setups sind üblich, weil Support sowohl Sicherheit als auch natürliche Sprache braucht. Eine nützliche Aufteilung ist:

• Regeln entscheiden, was erlaubt ist (Anspruchsberechtigung, Rückerstattungen, Verifizierungsschritte, erforderliche Formulierungen).
• Ein LLM hilft dabei, wie es gesagt wird (Ton, kurze Erklärungen, Fallzusammenfassungen vor der Übergabe).

Beispiel: Regeln bestätigen, dass eine Bestellung innerhalb des Rückgabezeitraums liegt, dann erstellt das LLM eine freundliche Nachricht, die zur Markenstimme passt.

Eine schnelle Entscheidungsregel:

• Vorwiegend Regeln, wenn Richtlinien streng sind, Fehler teuer sind und Fragen repetitiv sind.
• Vorwiegend LLM, wenn Fragen vielfältig sind, Kunden unvorhersehbare Sprache nutzen und Eskalationen klar sind.
• Beides, wenn Sie konsistente Richtlinienantworten brauchen und gleichzeitig natürlicheres Gespräch wünschen.

Genauigkeit: was schiefgeht und wie es sich zeigt

Im Support bedeutet „Genauigkeit“ mehr als nur eine Tatsache richtig zu haben. Es heißt dreierlei: die Antwort ist korrekt, sie deckt ab, was der Kunde wirklich braucht (nicht nur halb), und sie bleibt innerhalb der Richtlinie (Rückerstattungsregeln, Sicherheitsgrenzen, Compliance).

Regelbasierte und LLM-Chatbots versagen auf unterschiedliche, vorhersehbare Weise.

Regelbasierte Bots brechen meist zusammen, wenn die Realität nicht zum Entscheidungsbaum passt. Es taucht eine neue Frage auf ohne passenden Zweig, der Kunde benutzt unerwartete Formulierungen oder der Bot wählt den falschen Intent. Die Erfahrung sieht aus wie irrelevante vorgefertigte Antworten, Schleifen oder „Bitte wählen Sie eine der Optionen“, obwohl der Kunde das Problem bereits erklärt hat.

LLM-Bots scheitern oft an zu hoher Selbstsicherheit. Sie könnten eine Richtlinie raten, Schritte erfinden oder Produktdetails durcheinanderbringen. Die Erfahrung ist schlechter, weil es hilfreich klingt, aber falsch ist. Ein weiteres Problem ist Richtlinienabweichung: der Bot antwortet von einem Chat zum nächsten anders, besonders wenn er versucht, „nett“ zu sein und Regeln zu dehnen (z. B. Rückerstattungen außerhalb des festgelegten Zeitraums anzubieten).

Um Genauigkeit zu messen, verwenden Sie echte vergangene Tickets und bewerten Sie die Ergebnisse, nicht nur den Eindruck. Labeln Sie eine Stichprobe von Chats und verfolgen Sie:

• Korrekte Lösung (wurde das Kundenproblem gelöst?)
• Richtlinientreue (hat der Bot etwas versprochen, was nicht erlaubt ist?)
• Eskalationsrate (hat er weitergegeben, wenn nötig?)
• Wiederkontakt-Rate innerhalb von 24 bis 72 Stunden (kam der Kunde zurück?)

Manchmal ist die genaueste Antwort ein sicheres „Das weiß ich nicht.“ Wenn die Frage Kontozugriff, Abrechnungs-Ausnahmen oder etwas, das verifiziert werden muss, betrifft, ist eine klare Übergabe besser als ein riskantes Raten. Ein guter Bot gewinnt Vertrauen, indem er seine Grenzen kennt und den Kunden mit vollem Kontext an den richtigen Menschen weiterleitet.

Wartungskosten: Aufbauzeit vs. laufender Aufwand

Der größte Kostenunterschied zwischen regelbasierten und LLM-Chatbots zeigt sich nicht beim ersten Aufbau, sondern danach, wenn Produkt, Preise und Richtlinien sich ändern.

Regelbasierte Bots kosten anfangs mehr, weil Sie die Abläufe kartieren müssen: Intents, Entscheidungsbäume, Randfälle und genau die Auslöser, die ein Gespräch auf einen bestimmten Pfad lenken. Das ist sorgfältige Arbeit, liefert aber vorhersehbares Verhalten.

LLM-Bots erscheinen oft schneller startklar, weil Sie sie auf ein Helpcenter oder interne Docs verweisen und Anweisungen schreiben können, dann aus echten Chats verfeinern. Der Kompromiss ist die fortlaufende Kontrolle.

Im Zeitverlauf verschiebt sich die Arbeit:

• Regelbasierte Bots brauchen Änderungen, wenn sich irgendetwas ändert (neue Versandstufe, umbenannter Plan, neue Ausnahme in der Rückerstattungsrichtlinie).
• LLM-Bots brauchen gepflegte Quellen (Docs, Makros, Produktnotizen) und Einschränkungen (Anweisungen, Schutzmaßnahmen) sowie regelmäßige Prüfungen, ob die Antworten noch der Richtlinie entsprechen.

Wer die Wartung übernimmt, ist wichtig. Regel-Systeme zwingen normalerweise Support-Ops und Produkt, sich auf exakte Regeln zu einigen, die dann implementiert und getestet werden. LLM-Systeme können stärker von Support-Ops aktualisiert werden, wenn die Wissensbasis gut verwaltet ist, aber für sichere Retrieval-Mechanismen, Logging und Eskalationshandling bleibt Engineering nötig.

Kosten, die Teams oft übersehen, bis sie live gehen, sind Regressionstests nach Richtlinienänderungen, Monitoring auf riskante Antworten, Gesprächsprüfungen hinsichtlich Ton und Compliance und das Aktualisieren von Quellen, wenn neue Lücken auftauchen.

Wie häufig sich Dinge ändern, bestimmt die Gesamtkosten. Ändern sich Richtlinien wöchentlich, wird ein starrer Regelbaum schnell teuer. Ändern sich Richtlinien selten, aber müssen exakt sein (z. B. Garantiebedingungen), kann ein regelbasierter Bot auf lange Sicht günstiger sein.

Antworten mit Richtlinien in Einklang halten

Ein Support-Bot ist nur „gut“, wenn er die gleichen Regeln befolgt wie Ihre Agenten. Der schnellste Weg, Vertrauen zu verlieren, ist, wenn der Bot eine Rückerstattung verspricht, eine Adresse ändert oder Kontodaten auf eine Weise teilt, die Ihre Richtlinie nicht erlaubt.

Beginnen Sie damit, aufzuschreiben, was der Bot ohne menschliches Eingreifen tun darf. Konzentrieren Sie sich auf Aktionen, nicht auf Themen. „Kann erklären, wie Rückerstattungen funktionieren“ ist etwas anderes als „kann eine Rückerstattung ausstellen“ oder „kann ein Abonnement kündigen“. Je mehr der Bot ändern kann (Geld, Zugriff, persönliche Daten), desto strenger müssen die Regeln sein.

Nutzen Sie eine einzige Quelle der Wahrheit für Richtlinientexte und Snippets. Wenn Ihre Rückerstattungsrichtlinie über mehrere Dokumente und Agenten-Notizen verteilt ist, bekommen Sie inkonsistente Antworten. Legen Sie genehmigte Formulierungen an einem Ort ab und verwenden Sie sie überall (Chat, E‑Mail, Messaging-Kanäle). Hier trennen sich oft regelbasierte und LLM-Ansätze: Regeln erzwingen exakte Formulierungen, während LLMs starke Einschränkungen brauchen, um nicht abzudriften.

Schutzmechanismen, die Antworten richtlinienkonform halten

Gute Schutzmechanismen sind einfach, sichtbar und leicht zu testen:

• Genehmigte Textbausteine für sensible Themen (Rückerstattungen, Garantien, Rückbuchungen, Kontozugriff)
• Verbotene Behauptungen (wie „garantiertes Lieferdatum“ oder „sofortige Rückerstattung")
• Pflichtdisclaimer (Identitätsprüfungen, Bearbeitungszeiten, Anspruchsvoraussetzungen)
• Strukturierte Felder, die der Bot vor jeder Aktion sammeln muss (Bestellnummer, E‑Mail, letzte 4 Ziffern)
• Eine „bei Unsicherheit eskalieren“-Regel, die frühzeitig auslöst

Versionierung und Nachvollziehbarkeit

Richtlinien ändern sich. Behandeln Sie sie wie Software: versionieren Sie sie und protokollieren Sie, welche Version bei jeder Antwort verwendet wurde. Wenn ein Kunde das, was der Bot letzte Woche gesagt hat, anfechtet, können Sie den genauen Richtlinientext sehen, dem der Bot gefolgt ist.

Beispiel: Ein E‑Commerce-Shop ändert das Rückgabefenster von 30 auf 14 Tage. Mit Versionierung kann der Bot je nach Datum antworten und Sie können Randfälle später auditieren.

Eskalationsflüsse, die Kunden nicht frustrieren

Ein Chatbot ist nur so gut wie seine Übergabe. Wenn Menschen das Gefühl haben, in einer Schleife gefangen zu sein, verlieren sie das Vertrauen in den Kanal. Egal ob Sie sich für regelbasierte oder LLM-Chatbots entscheiden: gestalten Sie Eskalation als normalen Bestandteil der Erfahrung, nicht als Fehler.

Beginnen Sie mit klaren Auslösern, die den Chat zu einem Menschen weiterleiten, ohne den Nutzer betteln zu lassen. Häufige Auslöser sind: geringe Bot‑Konfidenz, Stichwörter wie „Rückerstattung“, „Rückbuchung“, „rechtlich“ oder „kündigen“, starke negative Stimmung, Zeitlimits ohne Fortschritt oder mehrere fehlgeschlagene Versuche beim gleichen Schritt.

Wenn eskaliert wird, lassen Sie den Kunden nicht alles wiederholen. Übergeben Sie ein kompaktes Paket Kontext an den Agenten:

• Eine kurze Zusammenfassung des Problems in einfacher Sprache
• Bekannte Kundendetails (Name, Konto, Bestellnummer)
• Was der Bot gefragt hat und wie der Nutzer geantwortet hat
• Bereits versuchte Schritte und deren Ergebnisse
• Alle Dateien, Screenshots oder Fehlermeldungen

Geben Sie eine Erwartung in einem Satz an: was als Nächstes passiert und wie lange es ungefähr dauern kann. Zum Beispiel: „Ich leite das jetzt an einen Support‑Spezialisten weiter. Die typische Wartezeit beträgt etwa 5 Minuten. Sie können hier weiter chatten.“

Machen Sie die Übergabe umkehrbar. Agenten wollen häufig, dass der Bot Routineaufgaben übernimmt (Logs sammeln, Basis‑Troubleshooting, fehlende Details sammeln), während sie sich auf Ausnahmen konzentrieren. Eine einfache Option „sende dem Kunden eine vom Bot geführte Checkliste“ spart Zeit und sorgt für konsistente Abläufe.

Schließlich: verfolgen Sie, warum eskaliert wurde. Taggen Sie jeden Übergabegrund (geringe Konfidenz, Richtlinienanfrage, wütender Kunde, fehlende Daten) und überprüfen Sie wöchentlich die wichtigsten Gründe. Dieser Feedback‑Loop ist, wie der Bot besser wird, ohne riskant zu werden.

Schritt für Schritt: den richtigen Chatbot auswählen und einführen

Starten Sie absichtlich klein. Automatisieren Sie zuerst ein paar repetitive Fragen und verbessern Sie dann anhand echter Transkripte. Dieser Ansatz funktioniert unabhängig davon, ob Sie sich für regelbasierte oder LLM-Chatbots entscheiden, weil die schwierigen Teile nicht das Modell sind, sondern Entscheidungen zu Richtlinien, Übergabe und Messung.

Praktischer Rollout‑Plan

1. Wählen Sie 3 bis 5 häufige, risikoarme Tickettypen. Gute Starter: Bestellstatus, Passwortzurücksetzungen, Öffnungszeiten und Zusammenfassungen der Rückerstattungsrichtlinie. Vermeiden Sie alles, was zu Geldverlusten oder Kontoänderungen führen kann, bis Sie dem Ablauf vertrauen.

2. Definieren Sie Erfolg, bevor Sie bauen. Wählen Sie 2 bis 3 Metriken, die Sie wöchentlich verfolgen können, z. B. Lösungsrate ohne menschliche Hilfe, CSAT nach dem Chat und Minuten, die pro Agent eingespart werden.

3. Schreiben Sie Richtlinienregeln und eine kurze „nie tun“-Liste. Beispiele: niemals Identität ohne verifizierten Schritt bestätigen, niemals Lieferdaten versprechen, die Sie nicht sehen können, niemals vollständige Kartennummern anfordern.

4. Bauen Sie die Hauptpfade und einen echten Fallback. Entwerfen Sie ideale Antworten und fügen Sie dann einen höflichen Fehlerfall hinzu, wenn der Bot unsicher ist: wiederholen Sie, was er verstanden hat, stellen Sie eine klärende Frage oder bieten Sie eine Übergabe an. Wenn Sie ein LLM nutzen, halten Sie sensible Themen an genehmigte Textbausteine gebunden.

5. Führen Sie einen Pilot mit echten Kunden durch und skalieren Sie dann. Halten Sie es begrenzt (ein Kanal, ein Team, eine Woche). Prüfen Sie Transkripte täglich, taggen Sie Fehler (falscher Intent, fehlende Daten, Richtlinienrisiko), aktualisieren Sie den Ablauf und fügen Sie erst dann weitere Themen hinzu.

Häufige Fehler und Fallstricke

Der schnellste Weg, von regelbasierten vs. LLM-Chatbots enttäuscht zu sein, ist, sie als dasselbe Werkzeug zu behandeln. Sie versagen unterschiedlich, also sehen die Fallstricke anders aus.

Ein häufiger Fehler ist, „was der Bot tun muss“ (Richtlinie) mit „wie er klingen soll“ (Ton) in einem Block von Anweisungen zu mischen. Ton ist flexibel. Richtlinie nicht. Halten Sie Richtlinien als klare, testbare Regeln (Rückgabefenster, Identitätsprüfungen, was Sie niemals versprechen), und lassen Sie den Bot dann eine freundliche Stimme darüberlegen.

Ein weiterer hohes Risiko ist, dem Bot Konto‑spezifische Fragen ohne harte Absicherung zu erlauben. Wenn ein Nutzer fragt: „Wo ist meine Bestellung?“, sollte der Bot nicht raten. Er sollte eine Verifizierung verlangen oder an ein sicheres System übergeben, das die Daten korrekt abruft.

Achten Sie vor dem Start auf diese Muster:

• Kein echter Fallback, sodass der Bot weiter rät, wenn er unsicher ist
• Testen nur höfliche, klare Fragen und das Überspringen von wütenden oder vagen Nachrichten
• Dem Bot erlauben, Ausnahmen und Sonderangebote zu erfinden
• Kein menschlicher Review‑Loop, sodass dieselben Fehler sich wiederholen
• Nicht das vollständige Transkript an Agenten übergeben, sodass Kunden sich wiederholen müssen

Ein einfaches Beispiel: Ein Kunde tippt: „Eure App hat mich doppelt belastet. Macht das jetzt gut.“ Wenn der Bot nicht auf Frustration und Dringlichkeit vorbereitet ist, antwortet er vielleicht mit einer generischen Abrechnungs‑FAQ. Besser ist eine kurze Entschuldigung, eine klärende Frage (Zahlungsmethode und Zeitpunkt) und ein klarer nächster Schritt: den richtigen Workflow starten oder eskalieren.

Schnelle Checkliste vor dem Livegang

Behandeln Sie den Bot vor dem Einsatz wie einen neuen Support‑Mitarbeiter: er braucht Training, Grenzen und Aufsicht. Das ist der schnellste Weg, vermeidbare Eskalationen und Richtlinienfehler zu vermeiden, egal ob Sie regelbasiert oder LLM wählen.

• Antwortquellen sind gesperrt. Der Bot antwortet nur aus genehmigten Richtlinientexten (Rückerstattungsregeln, Versandzeiten, Garantiebedingungen, Sicherheitsregeln). Wenn er keine Übereinstimmung findet, sagt er das und bietet eine Übergabe an.
• Eskalation ist klar und jederzeit verfügbar. Definieren Sie Auslöser (wütende Sprache, Konto‑Zugriffsprobleme, Zahlungsstreitigkeiten, rechtliche Anfragen, wiederholtes „das hat nicht geholfen“). Stellen Sie sicher, dass „mit einem Menschen sprechen“ jederzeit funktioniert.
• Sie können jedes Gespräch prüfen. Speichern Sie die Nutzerfrage, die Bot‑Antwort, welche Quellen verwendet wurden (oder „keine“) und das Ergebnis (gelöst, eskaliert, abgebrochen).
• Sie haben eine wöchentliche Review‑Gewohnheit. Überprüfen Sie im ersten Monat wöchentlich die größten Fehlerkategorien (falsche Richtlinie, unvollständige Antwort, unklare Sprache, falsches Routing) und verwandeln Sie sie in testbare Fixes.
• Richtlinienupdates haben einen Testplan. Wenn sich Richtlinien ändern, aktualisieren Sie die Quelleninhalte und führen Sie eine kleine Gruppe von Muss‑Bestandstests durch (Rückerstattungsanfrage, Adressänderung, Lieferverzögerung, Passwortzurücksetzung, wütender Kunde).

Ein realistisches Beispiel: ein E‑Commerce‑Support‑Chat

Stellen Sie sich eine kleine E‑Commerce‑Marke mit drei Hauptchat‑Anfragen vor: „Wo ist meine Bestellung?“, „Ich möchte meine Lieferadresse ändern“ und „Ich möchte eine Rückerstattung.“ Hier wird die Debatte regelbasierte vs. LLM-Chatbots sehr praktisch.

Beim Bestellstatus ist ein regelbasierter Bot meist die sicherste erste Instanz. Er fragt nach Bestellnummer und E‑Mail, prüft den Versandstatus beim Carrier und antwortet dann konsistent: aktueller Standort, erwartetes Lieferfenster und was zu tun ist, wenn das Paket verspätet ist. Kein Raten.

Adressänderungen sind ebenfalls ein guter regelbasierter Pfad, weil die Regeln klar sind. Der Bot prüft, ob die Bestellung noch nicht erfüllt ist, bestätigt die neue Adresse und aktualisiert sie. Falls die Bestellung bereits versendet wurde, stoppt er und bietet den richtigen nächsten Schritt an (Carrier kontaktieren oder nach Lieferung Rücksendung einleiten).

Ein LLM-Bot hilft vor allem, wenn die Kundenmeldung unklar oder emotional ist. Er kann neu formulieren, was der Kunde will, fehlende Details sammeln und den Fall für einen Agenten zusammenfassen. Das Ziel ist kein langes Gespräch, sondern eine sauberere Übergabe.

Rückerstattungen sind der Bereich, in dem Eskalation und kontrollierte Formulierungen zählen. Ein Bot sollte eskalieren, wenn die Entscheidung Ausnahmen oder Beweise braucht: beschädigte Artikel (Fotos nötig), fehlende Pakete nach „zugestellt“-Scan, Anfragen außerhalb des Richtlinienfensters, Rückbuchungs‑ oder Betrugssignale und Bestellungen mit hohem Wert.

Um Antworten richtlinienkonform zu halten, behandeln Sie die finale Rückerstattungsnachricht als kontrollierte Vorlage, nicht als Freitext. Lassen Sie das LLM nur genehmigte Felder ausfüllen (Daten, Bestellnummer, nächste Schritte), während die Richtlinientexte fest bleiben.

Nächste Schritte: eine dauerhafte Support‑Automatisierung aufbauen

Wählen Sie einen häufigen, risikoarmen Bereich im Support (Bestellstatus, Passwortzurücksetzung, Adressänderung) und automatisieren Sie nur diesen. Erweitern Sie basierend auf dem, was tatsächlich Tickets reduziert und Agentenzeit spart.

Wählen Sie Ihr Muster nach Risikoniveau, nicht nach Vorliebe. Für sachliche, richtlinienlastige Antworten gewinnen in der Regel Regeln oder strukturierte Flows. Für unklare Fragen („Was soll ich als Nächstes tun?“) kann ein LLM helfen, aber nur mit Schutzmaßnahmen. Viele Teams entscheiden sich für einen Hybrid: Regeln für die Teile, die exakt sein müssen, und ein LLM fürs Formulieren, Zusammenfassen und Routen.

Ein einfaches Wiederverwendbares Bauplan über Kanäle hinweg:

• Eine klare Intake‑Abfrage im Chat (was ist passiert, Bestellnummer, E‑Mail)
• Routing‑Regeln (Abrechnung, Versand, Technik) mit einer Option zur menschlichen Übergabe
• Authentifizierungschecks für konto­spezifische Anfragen
• Audit‑Logs dafür, was der Bot gesagt hat und welche Daten er verwendet hat
• Genehmigte Vorlagen für sensible Themen (Rückerstattungen, Datenschutz, Kündigungen)

Wenn Sie diese Workflows implementieren möchten, ohne alles von Grund auf zu bauen, kann AppMaster (appmaster.io) verwendet werden, um Daten zu modellieren, Support‑Prozesse mit visueller Geschäftslogik zu erstellen und Chat‑Übergaben an Backend‑Systeme anzubinden, die Anfragen und Richtlinienversionen nachverfolgen.