AI für eine Support-Knowledge-Base. AI für eine Support-Knowledge-Base ist ein internes Retrieval-Tool, das deine Agenten in normaler Sprache fragen können. Es durchsucht deine historischen Tickets, Produktdokumentation und Richtlinien in einer Abfrage und liefert eine Antwort, die die Quelle nennt, aus der sie stammt. Es sitzt hinter dem Agenten. Der Kunde spricht weiterhin mit einem Menschen.
Eure agenten verbringen die hälfte ihrer schicht damit, die dokumente zu durchsuchen. Das ist die klage, auf die ihr im eigenen team hören solltet. Die antwort existiert irgendwo. Sie steckt in einem alten ticket, einer produktspezifikation oder einer versandrichtlinie, die seit januar niemand geöffnet hat. Sie zu finden ist jetzt die eigentliche arbeit.
#Warum verbringen meine Agenten die Hälfte ihrer Zeit mit der Suche in den Docs?
Weil die Antwort über Systeme verstreut ist, die nicht miteinander sprechen. Die Rückerstattungsregel steht in einer Richtlinien-PDF. Der Grenzfall, der sie aushebelt, liegt vergraben in einem gelösten Zendesk-Ticket aus 2023. Das Produktverhalten steht auf einer Confluence-Seite, die ein ehemaliger PM geschrieben hat. Ein Agent bei einem komplexen Ticket muss drei Stellen prüfen, raten, welche aktuell ist, und hoffen.
Was macht AI für eine Support-Knowledge-Base eigentlich?
Es indexiert deine Tickets, Produktdokumentation und Richtlinien und lässt einen Agenten dann eine einzige Frage in normaler Sprache stellen und eine einzige Antwort zurückbekommen. Die Antwort verlinkt auf genau das Dokument und die Passage, aus der sie stammt, sodass der Agent sie mit einem Klick prüfen kann. Es ist intern. Kunden kommen nie damit in Berührung und sprechen weiterhin mit einem Menschen.
Die Quellenangabe ist der Teil, der zählt. Eine Antwort ohne Quelle ist eine Vermutung, die ein Agent noch prüfen muss. Eine Antwort, die auf die Passage verlinkt, aus der sie stammt, ist ein Fakt, den der Agent mit einem Klick bestätigt und dann in eine Antwort einfügt. Genau deshalb verknüpfen wir jede Antwort mit dem Dokument, aus dem sie stammt.
#Was ändert sich bei der erstantwortzeit?
Zur veranschaulichung nehmen wir ein angenommenes mittelständisches e-commerce-support-team, keinen kunden. Ein retrieval-werkzeug, das frühere tickets, produktdokumente und versandrichtlinien mit einer einzigen anfrage durchsucht, hilft am meisten bei den schwierigen tickets, bei denen der agent früher sechs tabs öffnete, bevor er ein wort schrieb. Ein team in dieser lage würde die erstantwortzeit bei komplexen tickets vorher und nachher messen.
Einfache tickets sind schon schnell. Das passwort-zurücksetzen, das wo-ist-meine-bestellung. Gebremst wird bei dem komplexen ticket, das einen richtlinien-sonderfall und eine frühere lösung braucht. Verkürzt man dort die suchzeit, bewegt sich der durchschnitt. Use-Case-Seite für Customer Support zeigt die gesamte form des entwurfs.
Wenn ihr diesen satz von eurer eigenen support-leitung hört, ist die suchschicht der ort, an dem ihr anfangt, noch vor jedem werkzeug für antworten.
#Ist das nicht einfach ein kundengerichteter Chatbot?
We are
Wir bauen eine Retrieval-Schicht, die hinter deinem Agenten sitzt, sodass ein Mensch die zitierte Antwort liest, prüft und die Antwort in seiner eigenen Stimme schreibt.
We aren't
Wir bauen keinen kundengerichteten Chatbot, der von sich aus antwortet und hofft, die Richtlinie vor der bereits verärgerten Person richtig verstanden zu haben.
Ein kundengerichteter Bot stellt das Modell zwischen deine Marke und einen verärgerten Kunden. Eine falsche Antwort zur Rückerstattung ist dort ein öffentlicher Fehler. Retrieval steht einen Schritt dahinter. Der Agent bekommt die zitierte Antwort, der Agent entscheidet, der Agent antwortet. Der Mensch bleibt dort im Loop, wo am meisten auf dem Spiel steht, und das Modell übernimmt das Graben dort, wo es nur mühsam ist.
#Was der Agent sieht
- Eine Suchleiste, gefragt in normaler Sprache, kein Stichwortfeld.
- Eine Antwort, gezogen aus Tickets, Docs und Richtlinien gleichzeitig.
- Eine Quellenangabe bei jeder Antwort, die auf die Passage verlinkt.
- Kein Kunde kommt je damit in Berührung. Es ist ein Agent-Assist-Tool, kein Chatbot.
Das Tool liest deine unstrukturierte Historie. Die Versandrichtlinie, die eine PDF ist, das gelöste Ticket, das ein Thread ist, die Produktdokumentation, die eine Wiki-Seite ist. Es braucht nicht, dass du davon vorher irgendetwas bereinigst oder umstrukturierst. Genau das ist der Punkt an Retrieval gegenüber dem händischen Aufbau einer weiteren Knowledge-Base, die du für immer aktuell halten musst. Wir schreiben über weitere Builds wie diesen im Journal.
Wenn deine Agenten mehr suchen als antworten, sollten wir erst kartieren, wo dein Wissen tatsächlich liegt, bevor wir irgendetwas bauen. Buche einen 30-minütigen Discovery-Call, und wir gehen deine Tickets, Docs und Richtlinien durch und sagen dir, wo eine Retrieval-Schicht die Erstantwortzeit bewegt und wo nicht.
