Schwarzer Freitag, 9:14 Uhr, Wien. Im Slack-Channel eines österreichischen Lifestyle-Shops flackert die rote Ticket-Lampe — 412 offene Anliegen, 24 Stunden Median-Wartezeit, drei Service-Mitarbeiter im Home-Office hängen im Telefon. Genau diese Szene war 2024 der Anlass, das Customer-Service- Modell auf den Tisch zu legen. Nicht für ein "Innovations-Projekt", sondern weil das alte Setup nicht mehr trug. Was 18 Monate später daraus geworden ist, beschreibt diese Case Study — anonymisiert, aber mit Zahlen.
1. Ausgangslage — 800 Tickets pro Tag und kein Skalierungspfad
Der Shop verkauft Outdoor- und Lifestyle-Produkte in drei Linien, drei Markenwebsites, ein gemeinsames Backend. Vor dem Projekt war die Service-Struktur klassisch: sieben Vollzeit-Servicemitarbeiter, Zendesk als Helpdesk, dazu E-Mail- und Instagram-DM-Kanäle, getrennte Workflows pro Marke. Volumen: rund 800 Tickets pro Werktag, mit Peaks auf 1.400 in der Vorweihnachtszeit.
Die Zahlen aus dem Discovery-Workshop:
- 40 Prozent aller Tickets waren wiederkehrend (Lieferstatus, Retouren- Modalitäten, Größentabellen, Stornierung).
- Median-Wartezeit auf erste Antwort: 24 Stunden in Peak, 6 Stunden im Normalbetrieb.
- CSAT-Score: 4,1 von 5 — solide, aber mit negativem Trend über zwölf Monate.
- Mitarbeiter-Fluktuation im Service: 38 Prozent pro Jahr, klar zu viel.
Das Team hatte 2023 schon einmal einen klassischen Decision-Tree-Bot versucht. Das Ergebnis: 11 Prozent Self-Service-Quote, Kunden waren genervt, der Bot wurde abgeschaltet. Die Skepsis im Service-Team war also real und berechtigt.
2. Lösung — KI-Agent mit klarer Eskalations-Architektur
Der Audit ergab klar: das Hauptproblem war nicht das Volumen, sondern die fehlende Trennung zwischen wiederholbaren Standard-Anliegen und echten Beratungsfällen. Beide liefen durch denselben Trichter und banden Service-Stunden, die für komplexe Fälle gefehlt haben.
Die Architektur, die wir gebaut haben, hat vier Schichten:
- Intent-Klassifizierung — eingehendes Ticket wird in eine von 18 definierten Kategorien gemappt (Lieferstatus, Retoure, Produktfrage, Beschwerde, Sonderwunsch, ...)
- Wissens-Layer — Antworten ausschließlich aus kuratierten Quellen (Produktdatenbank, Versand-FAQ, Retouren-Policy), keine freie LLM-Generierung bei Produktdetails
- Eskalations-Trigger — Beschwerden, emotionale Sprache, Sonderfälle, Anfragen über €500 Warenwert: harte Weiterleitung an Mensch, ohne "Versuch mal noch eine Runde"
- Helpdesk-Integration — vollständige Übergabe an Zendesk inklusive Konversationsverlauf, sodass der Mensch nicht bei null beginnen muss
durch KI-Agent + 35 % bewusste Eskalation an Menschen — das gesamte Service-Team konzentriert sich seither auf komplexe Fälle, nicht auf Lieferstatus-Anfragen
Der entscheidende Designschritt war Punkt 3. Wir haben bewusst keinen "Maximal-Bot" gebaut, sondern einen, der seine Grenzen kennt. Bei allem, was Emotion, Reklamation oder Geld über einer Schwelle betrifft, übernimmt sofort ein Mensch — mit der vollen Vorarbeit des Agenten im Rücken.
3. Umsetzung — sechs Wochen Sprint, drei Phasen
Das Projekt lief als Mid-Complexity-Sprint, sechs Wochen netto, drei Phasen:
Wochen 1–2: Daten und Intents. Auswertung von 90 Tagen historischer Tickets, Clustering, Definition der 18 Intent-Kategorien. Kuratierung der Wissensbasis — die Outdoor-Marke hatte 240 Produkte, jedes mit Größenchart, Materialdetails, Pflegehinweisen. Diese Inhalte mussten strukturiert vorliegen, sonst halluziniert das Modell. Wir haben hier zwei zusätzliche Tage gebraucht, weil die Produkt-CSVs aus drei Systemen kamen.
Wochen 3–4: Bau und Eskalations-Logik. Anbindung an Zendesk via API, Trainings-Set aus den 90-Tage-Tickets, Aufbau der Eskalations- Regeln. Die Regeln wurden zusammen mit dem Service-Team-Lead definiert, nicht von einem externen Engineer alleine — wichtig für die spätere Akzeptanz.
Wochen 5–6: Pilot und Rollout. Erste zwei Wochen Shadow-Mode (der Agent generiert Antworten, aber der Mensch sendet), dann Live mit 50 Prozent Traffic, dann Vollbetrieb. Eskalationsquote in Woche 1 live: 48 Prozent, in Woche 4: 35 Prozent — Lern-Effekt aus den korrigierten Antworten.
Go-Live: November 2025, also direkt rein ins Vorweihnachtsgeschäft. Bewusste Entscheidung des CEO, gegen Empfehlung des Tech-Leads. Hat funktioniert, weil die Eskalations-Schwellen so konservativ gesetzt waren, dass im Zweifel ein Mensch übernommen hat.
4. ROI nach 4 Monaten
Stand März 2026, nach knapp vier Monaten Vollbetrieb:
- First-Touch-Resolution durch den Agenten: 65 Prozent. Die restlichen 35 Prozent gehen sauber an Menschen, mit vollem Kontext.
- Wartezeit-Median: von 24 Stunden auf 8 Minuten. Das ist die Zeit bis zur ersten substanziellen Antwort, nicht bis zur vollständigen Lösung.
- CSAT: von 4,1 auf 4,7 von 5 Punkten — plus 0,6 Punkte, gemessen über die Post-Ticket-Umfrage in Zendesk.
- Service-Team-Auslastung: drei der sieben Vollzeit-Stellen wurden in andere Bereiche umgewidmet (Account-Management für B2B-Kunden, Content für die Marken-Sites), ohne Kündigungen.
- Investment: rund €68.000 Implementierungskosten, €1.800/Monat laufende Kosten (LLM-API + Zendesk-Plugin). Amortisation rechnerisch nach knapp 7 Monaten — der CEO rechnet primär in Service-CSAT, weil drei Mitarbeiter im Haus geblieben sind.
Wichtig: die Zahl, die am meisten Aufmerksamkeit zieht, ist die Wartezeit-Reduktion. Die Zahl, die geschäftlich am meisten zählt, ist das CSAT-Plus. Es korreliert mit Wiederkaufrate und Net Promoter Score, und beide haben sich messbar verbessert (NPS +9 Punkte).
5. Was wir gelernt haben — und was wir anders machen würden
Drei Punkte, die in Retrospektive wichtig waren:
Erstens: Die Eskalations-Logik ist das eigentliche Produkt. Der KI-Agent ist relativ einfach zu bauen, ein gutes LLM mit ordentlicher Wissensbasis liefert 80 Prozent der Funktion out-of-the-box. Was den Unterschied macht, ist die Frage, wann er an einen Menschen übergibt. Wir haben hier in den ersten zwei Wochen nachjustiert, weil zu viele "weiche" Beschwerden im Bot hängen blieben.
Zweitens: Das Service-Team braucht echte Ownership. Der Team-Lead hat heute Zugriff auf das Backend, kann Intents anpassen, Phrasen zur Eskalations-Liste hinzufügen. Ohne diese Ownership wäre der Agent nach drei Monaten ein "IT-Projekt", dem niemand vertraut.
Drittens: 24/7 ist nicht das Hauptargument. Wir haben anfangs mit "24/7-Verfügbarkeit" gepitcht. Realität: 78 Prozent des Traffics sind weiterhin in der Kernzeit 08–20 Uhr. Das Hauptargument hätte "acht statt 24 Stunden Wartezeit" sein müssen — das ist, was Kunden spüren.
Was wir anders machen würden: früheres Onboarding des Service-Teams, mehr Time-in-Saddle für die Mitarbeiter im Shadow-Mode. Wir hatten zwei Wochen — drei wären besser gewesen.
6. Was das für ähnliche E-Commerce-Setups bedeutet
Aus diesem und drei weiteren E-Commerce-Projekten in 2025/26 in Österreich lässt sich ein recht klares Muster ablesen:
- Ab rund 300 Tickets pro Tag rechnet sich ein KI-Customer-Service-Agent unter 12 Monaten.
- Der Self-Service-Anteil landet realistisch zwischen 50 und 70 Prozent, je nach Datenqualität.
- Das Service-Team schrumpft selten — aber es kommt vom Lieferstatus-Beantworten weg und macht echte Beratung, Account-Management, Content.
- Wartezeiten sind der sichtbarste KPI, CSAT der wirtschaftlich relevanteste.
Wer mit einem klassischen Decision-Tree-Bot angefangen hat und gescheitert ist, sollte nicht aufgeben — die LLM-basierten Agents 2025/26 spielen in einer anderen Liga, vor allem in Sprachqualität und Kontext-Verständnis. Voraussetzung bleibt: saubere Wissensbasis, klare Eskalations-Logik, Ownership im Service-Team.
Häufige Fragen
Was Geschäftsführer zu KI-Customer-Service fragen.
Wie haben die Kunden auf den KI-Agenten reagiert?
Wie war die Akzeptanz im Service-Team?
Welches LLM wurde eingesetzt — und warum?
Wie groß ist das Halluzinations-Risiko bei Produktfragen?
Was, wenn ein Kunde sich öffentlich in Social Media beschwert?
Was als Nächstes?
Wenn du in einem E-Commerce-Setup vergleichbar viele Tickets pro Tag hast und merkst, dass dein Service-Team die Skalierung nicht mehr trägt — der typische Einstieg ist ein Audit S oder Audit M mit Fokus auf Service-Volumen und Helpdesk-Architektur. Zwei bis drei Wochen, klare ROI-Schätzung, kein Bot ohne sauberes Fundament. Der Discovery-Call dauert 30 Minuten und kostet nichts.