Kundensupport ist einer der ersten Bereiche, in denen Unternehmen LLM in der Praxis erproben. Die Gründe sind nachvollziehbar: hohes Volumen wiederkehrender Anfragen, klar messbare Kosten, relativ strukturierter Inhalt. Die Ergebnisse fallen jedoch sehr unterschiedlich aus — und der Unterschied zwischen „Kunden sind begeistert" und „Kunden sind frustriert" liegt nicht darin, welches Modell Sie gewählt haben, sondern darin, wo Sie dem System erlaubt haben, selbstständig zu antworten, und wo Sie es an einen Menschen übergeben haben.
Dieser Artikel ist kein Verkaufsgespräch für ein Chatbot-Projekt. Er handelt davon, wo LLM im Kundensupport tatsächlich hilft, wo die konkreten Fallstricke liegen und wie man ein System so aufsetzt, dass Kunden nicht frustriert abwandern. Erfahrungen aus eigenen Deployments — nicht aus Marketingpräsentationen.
Wo LLM wirklich hilft
FAQ und Deflection wiederkehrender Anfragen
Der stärkste Anwendungsfall für LLM im Support ist auch der unattraktivste: immer wieder dieselben Fragen beantworten. „Wie lange dauert die Lieferung?" „Wie gibt man einen Artikel zurück?" „Wo ist meine Bestellung?" In vielen B2B-Unternehmen machen solche Anfragen 40–60 % des gesamten Ticket-Volumens aus.
LLM mit einer RAG-Pipeline — also mit Grounding über aktueller Dokumentation — beantwortet diese Fragen schneller als ein menschlicher Agent, ist 24/7 verfügbar und brennt nicht nach der dreißigsten gleichlautenden Anfrage am Tag aus. Messbarer Effekt: kürzere durchschnittliche Lösungszeit, geringeres Ticket-Backlog, Verfügbarkeit außerhalb der Geschäftszeiten.
Das Schlüsselwort ist Grounding: Der Chatbot darf nicht aus den Trainingsparametern antworten. Er muss aus Ihrer aktuellen Dokumentation antworten — Preislisten, Richtlinien, Produktspezifikationen. Ohne das erfindet er mit hoher Wahrscheinlichkeit Fakten.
Triage und Klassifizierung von Tickets
LLM kann eingehende Tickets zuverlässig nach Thema, Dringlichkeit und Abteilung klassifizieren, bevor ein menschlicher Agent sie zu Gesicht bekommt. Das ist keine spektakuläre Funktion, spart in der Praxis aber Zeit und reduziert Fehler bei der manuellen Sortierung.
Das System liest den Ticket-Text, weist eine Kategorie zu (technische Störung, Rechnung, Serviceanfrage) und leitet ihn an die richtige Warteschlange weiter. Bei einem gut trainierten Klassifikator ist die Trefferquote hoch — und ein Klassifizierungsfehler hat geringe Kosten, weil der Agent die Kategorie manuell korrigieren kann.
Entwurf von Antworten (Draft Mode)
Anstatt direkt dem Kunden zu antworten, schlägt LLM dem Agenten eine Formulierung vor. Der Agent genehmigt die Antwort, passt sie an oder schreibt sie um — und schickt sie unter seinem eigenen Namen ab.
Dieses Muster — auch Copilot Mode genannt — ist im Kundensupport sehr wirkungsvoll. Die Schreibgeschwindigkeit steigt, die Konsistenz verbessert sich, und der Agent bleibt für jede Antwort verantwortlich. Halluzinationen des Modells werden durch menschliche Kontrolle abgefangen, bevor die Antwort das System verlässt.
Für Unternehmen, bei denen Kunden in Fremdsprachen schreiben, ermöglicht der Copilot Mode auch Agenten, in Sprachen zu antworten, in denen sie nicht muttersprachlich sind — LLM übersetzt und macht einen Vorschlag, der Agent prüft Ton und Sachlichkeit.
Zusammenfassung des Gesprächsverlaufs vor der Eskalation
Wenn ein Kunde nach drei Nachrichten mit dem Chatbot mit einem Menschen sprechen möchte, sollte der Agent den Kontext erhalten — was der Kunde wollte, was das System geantwortet hat, warum es nicht gereicht hat. Ohne das fängt der Kunde von vorne an, und die Frustration wächst.
LLM kann laufend eine Zusammenfassung des Gesprächs generieren und sie dem menschlichen Agenten als strukturiertes Handoff übergeben. Der Kunde muss nicht wiederholen, was er gesagt hat. Das ist eine jener Funktionen, die nicht die Erfolgsquote des Chatbots verbessern — sie verbessern die Kundenerfahrung bei jedem Übergang zu einem Menschen.
Wo LLM den Kunden verärgert
Sackgassen ohne Eskalation
Das häufigste Problem in Produktionsdeployments: Der Chatbot kann nicht helfen, sagt dem Kunden das aber nicht klar. Stattdessen generiert er immer längere Antworten, fragt nach Präzisierungen oder wiederholt dieselbe Antwort mit anderen Worten.
Der Kunde weiß, dass er nicht weiterkommt, aber das System hält ihn in einer Schleife. Nach der fünften Iteration bricht er genervt ab — nicht unbedingt, weil das Problem nicht gelöst wurde, sondern weil er Zeit verloren hat und ignoriert wurde.
Die Lösung ist einfach, erfordert aber Disziplin beim Design: Jeder Chatbot muss eine explizite Eskalationsbedingung haben. Wenn der Kunde zweimal nicht bestätigt hat, dass die Antwort geholfen hat — einen menschlichen Agenten oder einen Rückruf anbieten. Ohne Entschuldigung, ohne weitere Rückfrage.
Halluzinierung unternehmensspezifischer Informationen
LLM ohne RAG oder mit schlecht konfiguriertem RAG erfindet Fakten über Ihr Unternehmen — Preise, Fristen, Garantiebedingungen, Servicepläne. Im Kundensupport ist das kein akademisches Problem. Der Kunde erhält eine falsche Information, handelt danach und stellt später fest, dass es nicht stimmt.
Forschungsergebnisse zeigen, dass Enterprise-Chatbots in Live-Produktionsdeployments immer noch eine Halluzinierungsrate von rund 18 % aufweisen. Korrekt implementiertes RAG reduziert diese Zahl deutlich — um 60–71 % gegenüber einem reinen LLM. Das Problem wird jedoch nicht vollständig beseitigt. Es versagt an zwei Stellen: Das Retrieval gibt ein irrelevantes Dokument zurück, oder das Modell ignoriert den abgerufenen Kontext und antwortet aus seinen Parametern.
Wir haben mehrere öffentliche Fälle dokumentiert, in denen ein Unternehmens-Chatbot Regeln und Richtlinien erfunden hat, die nicht existieren — Kunden haben daraufhin Ansprüche geltend gemacht, die das Unternehmen ablehnte. Der Vertrauensverlust ist in solchen Fällen langfristig.
Konfidenz ohne Deckung
LLM äußert sich mit gleicher Sicherheit, ob es aus verifizierten Dokumenten antwortet oder Dinge erfindet. Für den Kunden sind diese beiden Situationen nicht zu unterscheiden. Der Ton der Antworten ist höflich, strukturiert, überzeugend — unabhängig davon, ob die Antwort korrekt ist.
Dieses Problem tritt nicht nur beim Halluzinieren von Fakten auf. Es tritt auch bei mehrdeutigen Fragen auf, bei denen die richtige Antwort „das hängt von Ihrem konkreten Vertrag ab" wäre — und der Chatbot stattdessen eine scheinbar präzise Antwort liefert, die für den jeweiligen Kunden möglicherweise nicht gilt.
Technische Fragen jenseits des Chatbot-Rahmens
Im B2B-Kundensupport haben technische Kunden komplexe Fragen zu Konfiguration, Integration und spezifischen Geräteparametern. Ein Chatbot über FAQ-Dokumentation beantwortet diese Fragen — aber nicht notwendigerweise korrekt. Die Antwort kann grammatisch einwandfrei und sachlich unvollständig sein, was im technischen Bereich mehr Schaden anrichtet als ein ehrliches „Ich weiß es nicht".
Realistisches Ziel für 2026: 40–60 % der L1-Anfragen automatisieren (einfache FAQ, Statusabfragen, Standardprozesse). Komplexe technische B2B-Fragen und kundensensible Situationen erfordern Human-in-the-Loop ohne Ausnahme.
HITL: wann Menschen entscheiden müssen
Human-in-the-Loop (HITL) ist kein Eingeständnis einer Systemschwäche — es ist eine architektonische Entscheidung darüber, wo das Fehlerrisiko inakzeptabel ist. Im Kundensupport gibt es klare Kategorien:
Immer an einen Menschen eskalieren: - Der Kunde ist erkennbar frustriert (drei oder mehr erfolglose Antworten) - Die Frage betrifft Entschädigung, Garantie, Reklamation oder rechtliche Ansprüche - Der Kunde fragt explizit nach einem menschlichen Agenten - Die technische Frage übersteigt die Dokumentation (Deployment, Integration, nicht standardisierte Konfiguration) - Der Chatbot selbst bewertet die Antwortsicherheit als gering
Kann automatisiert werden: - Statusabfrage (wo ist die Bestellung, Liefertermin) - Standard-FAQ mit klarer Antwort in der Dokumentation - Weiterleitung des Kunden zum richtigen Formular, Verfahren, Dokument - Klassifizierung und Priorisierung von Tickets
Architektonisch: Die Eskalation darf nicht hinter einem weiteren Formular oder einer Wartezeit versteckt werden. Der Kunde muss wissen, dass jemand seinen Fall übernimmt — und wann. Best Practice ist die Übergabe mit Kontext: Der Agent erhält die Gesprächszusammenfassung automatisch, der Kunde muss nichts wiederholen.
Wie man misst, ob es funktioniert
Ohne Metriken ist jedes Chatbot-Projekt Überzeugung, kein Wissen. Wichtige Kennzahlen für LLM im Kundensupport:
Technische Metriken (regelmäßig kontrollieren): - Deflection Rate — Anteil der Anfragen, die ohne menschlichen Agenten gelöst werden - Faithfulness Score — Grad, in dem Antworten durch Quelldokumente gedeckt sind (Ziel ≥ 95 %) - Hallucination Rate — Anteil der Antworten mit sachlichen Fehlern (Ziel ≤ 2 %) - Eskalationsrate — wie viel Prozent der Gespräche mit einer Eskalation enden (Trend beobachten, nicht nur absolute Zahl)
Kundenmetriken (messen den tatsächlichen Effekt): - CSAT nach Chatbot-Interaktion versus nach menschlicher Interaktion — die Differenz zeigt, wie Kunden das System wirklich wahrnehmen - Repeat Contact Rate — ein Kunde, der mit derselben Frage zurückkommt, wurde nicht gelöst - Durchschnittliche Lösungszeit vor und nach dem Deployment
Operative Metriken: - Anteil der automatisch korrekt klassifizierten Tickets - Zeit bis zur Eskalation (von der Bedarfserkennung bis zur Übergabe an den Agenten)
Wenn keine Quality Gates eingerichtet sind — zum Beispiel eine automatische Benachrichtigung, wenn der Faithfulness Score unter 90 % fällt — merkt man nicht, wann das System mehr zu halluzinieren begonnen hat, als beim Deployment akzeptiert wurde. Modelle ändern sich, Dokumentationen ändern sich, die Anfragenverteilung ändert sich.
Architektur, nicht Produkt
LLM im Kundensupport funktioniert nicht als Produkt, das man „einfach deployt". Es funktioniert als Schicht in einem System, die von der Qualität der Unterlagen und den Regeln abhängt, wann gehandelt und wann übergeben wird.
Systeme, die in der Praxis funktionieren, haben einige gemeinsame Eigenschaften:
- Grounding ist Pflicht. Der Chatbot antwortet aus Dokumenten, nicht aus Modellparametern. Aktualisierungen der Produktdokumentation schlagen sich automatisch in der Wissensbasis nieder.
- Konfidenz ist explizit. Das System hat einen Schwellenwert — wenn es einer Antwort nicht sicher ist, sagt es das, anstatt eine scheinbar sichere Antwort zu generieren.
- Eskalation ist eine erstklassige Funktion. Kein Sicherheitsnetz. Sie wird genauso geplant, getestet und gemessen wie das Antworten selbst.
- Handoff trägt Kontext. Der Agent erhält eine Zusammenfassung, kein leeres Ticket mit dem Kundennamen.
Die Wahl zwischen Chatbot, Copilot und Agent hängt davon ab, wie viel Autonomie im jeweiligen Kontext sicher ist. Für die meisten B2B-Unternehmen, die im Kundensupport starten, ist der Copilot Mode — wo LLM vorschlägt und der Agent genehmigt — das beste Verhältnis zwischen Geschwindigkeit und Kontrolle. Ein vollständig autonomer Chatbot macht nur Sinn für eng begrenzte Daten, die gut durch Dokumentation abgedeckt sind und bei denen eine fehlerhafte Antwort ein geringes Risiko darstellt.
Für Unternehmen in regulierten Branchen (Versicherungen, Gesundheitswesen, Finanzdienstleistungen) empfehlen wir, auch einen Blick auf Agent Guardrails zu werfen — die Definition expliziter Grenzen dessen, was das System sagen darf und was nicht.
Häufige Fragen
Kann ein LLM-Chatbot das gesamte Support-Team ersetzen?
Das realistische Ziel ist die Automatisierung von 40–60 % der L1-Anfragen — wiederkehrende FAQ, Bestellstatus, Standardprozesse. Komplexe technische B2B-Fragen, Situationen mit Entschädigung oder Garantie sowie Kunden, die explizit mit einem Menschen sprechen möchten, bleiben in den Händen menschlicher Agenten. Ein Chatbot, der alles ersetzen soll, scheitert typischerweise genau in den Fällen, die dem Kunden am meisten bedeuten.
Wie verhindert man, dass der Chatbot Unternehmensinformationen halluziniert?
Die Grundlage ist eine RAG-Pipeline über aktueller Unternehmensdokumentation — Preislisten, Richtlinien, Produktspezifikationen. RAG allein reduziert das Halluzinieren, beseitigt es aber nicht. Ergänzende Maßnahmen sind ein expliziter Konfidenzschwellenwert (bei geringer Sicherheit antwortet das System mit „Ich weiß es nicht" statt zu halluzinieren), regelmäßige Evaluierung der Faithfulness-Metrik und Quality Gates im Produktionsmonitoring.
Wann ist der Copilot Mode besser als ein vollständig autonomer Chatbot?
Copilot Mode — wo LLM eine Antwort vorschlägt und der Agent sie vor dem Absenden genehmigt — ist immer besser, wenn ein Fehler in der Antwort nicht zu vernachlässigende Folgen hat: Der Kunde handelt auf Basis einer falschen Information, macht Garantieansprüche geltend oder baut falsche Erwartungen auf. Copilot Mode reduziert sichtbares Halluzinieren auf Kundenseite drastisch, während der Geschwindigkeitsvorteil für Agenten erhalten bleibt.
Wie setzt man die Eskalation auf, ohne Kunden zu verärgern?
Eskalation sollte proaktiv angeboten werden — nicht erst, wenn der Kunde nach mehreren gescheiterten Versuchen darum bittet. Das System sollte nach der zweiten erfolglosen Antwort automatisch einen menschlichen Agenten oder einen Rückruf anbieten. Das Handoff muss Kontext mitführen: Der Agent erhält eine Gesprächszusammenfassung, der Kunde muss die Geschichte nicht wiederholen. Wartezeiten transparent kommunizieren.
Was ist der Faithfulness Score und wie misst man ihn?
Der Faithfulness Score misst, inwieweit die Antwort des Chatbots durch die Quelldokumente in der Wissensbasis gedeckt ist — also ob der Chatbot aus dem abgerufenen Inhalt antwortet oder aus eigenen Parametern generiert. Er wird mit automatisierten Evaluierungsframeworks gemessen (z. B. RAGAS), die die generierte Antwort mit dem abgerufenen Kontext vergleichen. Das Produktionsziel liegt bei ≥ 95 %. Ein Abfall unter 90 % ist ein Signal, die Dokumentenqualität in RAG oder die Konfiguration der Retrieval-Schicht zu überprüfen.
---
*Wenn Sie den Einsatz von LLM im Kundensupport erwägen oder eine unabhängige Bewertung einer bestehenden Lösung wünschen — wo die tatsächlichen Lücken sind und was den schnellsten messbaren Effekt bringen würde — schauen wir uns gerne Ihren konkreten Fall an. MP Industrial Solutions hilft Unternehmen, Systeme zu entwickeln, die Kunden tatsächlich helfen, nicht nur nach KI aussehen.*