Durchgerechnetes Beispiel. Dies ist ein anschauliches, durchgerechnetes Beispiel und kein Kundenergebnis: Das Support-Team und seine Zahlen sind Annahmen. Es zeigt agentenseitiges Retrieval, ein Tool, das hinter dem Support-Mitarbeiter sitzt, nicht vor dem Kunden. Der Mitarbeiter stellt eine Frage in normaler Sprache, erhält eine belegte Antwort, bleibt im Ticket und schickt die Antwort selbst ab.
Stell dir ein mittelständisches E-Commerce-CX-Team vor, das die Erstantwortzeit bei komplexen Tickets senken will. Dieser Beitrag behandelt, woraus das Design besteht, was man messen sollte und was es nicht tut. Er berichtet kein Ergebnis, weil kein Kunde dahintersteht.
Das Team ist hypothetisch, und jede Zahl, die man hier erwarten könnte, ebenso. Das Design stützt sich auf die Support-Arbeit, die wir unter /ai-for/customer-support beschreiben. Noch etwas vorab: Es ist ausschließlich Agent-Assist. Zu keinem Zeitpunkt spricht ein Chatbot mit einem Kunden.
#Was hat die Mitarbeiter ausgebremst?
Die Antworten existieren. Sie zu finden, skaliert nicht. Ein komplexes Ticket heißt: Der Mitarbeiter öffnet den Zendesk-Verlauf, ein Produktdokument und ein PDF zur Versandrichtlinie und setzt die Antwort von Hand zusammen. Jahre vergangener Tickets enthalten den Präzedenzfall, und niemand kann dieses Archiv in der Zeit durchsuchen, die ein Kunde wartet.
Also blieb die erste Antwort in der Warteschlange liegen, während der Mitarbeiter suchte. Diese Wartezeit ist die Zahl, nach der die Support-Leitung gefragt wird. Erstantwortzeit, nicht Ticketvolumen.
Kann KI die Erstantwortzeit im Kundensupport ohne Chatbot senken?
Ja, das ist das Ziel. Ein internes Retrieval-Tool lässt Mitarbeiter in normaler Sprache Fragen über historische Tickets, Produktdokumente und Richtlinien-PDFs stellen und liefert eine belegte Antwort. Der Mitarbeiter schreibt und sendet die Antwort weiterhin selbst. Ein Team würde die Erstantwortzeit bei komplexen Tickets vorher und nachher messen, ganz ohne kundenseitigen Bot.
#Woraus besteht das Design?
Ein internes Retrieval-Tool über drei Quellen hinweg: historische Tickets, die Produktdokumente und die PDFs zur Versandrichtlinie. Ein Mitarbeiter tippt eine Frage so ein, wie er sie einem erfahrenen Kollegen stellen würde. Die Antwort kommt mit angegebener Quelle zurück, sodass der Mitarbeiter sie prüfen kann, bevor sie an einen Kunden geht.
- Durchsuche alle früheren Tickets mit einer einzigen Abfrage, statt Tab für Tab.
- Belegte Antworten, sodass der Mitarbeiter die Quelle prüft, statt einer Blackbox zu vertrauen.
- Antworten, die auf den PDFs zur Versandrichtlinie beruhen, wo die Sonderfallregeln tatsächlich stehen.
- Der Mitarbeiter bleibt im Ticket. Das Tool antwortet nie von selbst an einen Kunden.
Das Training des Support-Teams ist Teil des Designs, keine Übergabe am Ende. Die Kennzahl, auf die man sich einigt, ist die Erstantwortzeit bei komplexen Tickets, vorher und nachher gemessen. Was sie bewegt, sollen deine eigenen Daten zeigen, nicht dieser Beitrag.
#Ist das nicht einfach ein Ablenkungsbot?
Nein, und genau der Unterschied ist der Punkt. Ein Deflection-Ansatz versucht, das Ticketvolumen zu senken, indem er Kunden direkt antwortet. Dieses Design zielt auf eine andere Zahl: die Erstantwortzeit, indem Retrieval hinter den Mitarbeiter gesetzt wird. Der Kunde spricht weiterhin mit einem Menschen.
We are
Stennir baut KI, die hinter deinen Support-Mitarbeitern sitzt: Retrieval, Triage, Entwurf-und-Prüfung, gemessen an Erstantwortzeit und Lösungsqualität.
We aren't
Stennir ist kein Anbieter von kundenseitigen Chatbots und verkauft Ablenkung nicht als Ziel; der Mitarbeiter bleibt im Ticket, und deine Kunden sprechen weiterhin mit Menschen.
Tools wie Zendesk AI, Intercom Fin oder die Vorschläge von Gorgias arbeiten innerhalb ihrer eigenen Mauern: deine Makros, deine Hilfeartikel, deine gespeicherten Antworten. Dieses Design ergänzt Retrieval über den Rest. Die historischen Tickets, die Produktdokumente, die PDFs zur Versandrichtlinie, die Runbooks. Dort verstecken sich die Antworten auf komplexe Tickets.
Die KPIs, die wir bewegen, sind Erstantwortzeit und Lösungsqualität bei komplexen Tickets, nicht die Kopfzahl. Das sagen wir schon am ersten Tag, und wir messen es auch.
#Würde das auch für unser Support-Team funktionieren?
Der Passungstest ist einfach. Liegen eure Antworten bereits an Orten, die sich nur langsam durchsuchen lassen? Jahre an Tickets, ein Stapel Richtlinien-PDFs, Produktdokumente, die sich ständig ändern. Wenn Mitarbeiter vor jeder komplexen Antwort Minuten mit Suchen verlieren, ist genau diese Zeit das, was Retrieval zurückgeben soll.
Dieses Design gehört zu unserer Arbeit im Bereich KI-Beratung, mit dem Training des Support-Teams eingebunden aus unserem Bereich KI-Training. Wenn du sehen willst, wie die Teile zusammenpassen, findest du im Journal weitere durchgerechnete Beispiele wie dieses.
Wenn deine Mitarbeiter vor jeder komplexen Antwort nach Antworten suchen, ist das die Verzögerung, auf die dieses Design zielt. Erzähl uns, was du baust, und wir sagen dir, ob Retrieval der richtige Hebel ist oder nicht.
