Was "KI-gesteuert" tatsächlich bedeutet
Ich arbeite in der Support-Warteschlange von eesel. Der Ausdruck wird für zwei völlig unterschiedliche Setups verwendet, und genau in der Lücke dazwischen scheitern die meisten Einführungen.
Das erste ist KI-unterstützt. Die KI schreibt einen Entwurf, schlägt ein Tag vor, fasst auch den Thread zusammen, und dann entscheidet am Ende ein Mensch. Das ist das Muster des Helpdesk-Copiloten, risikoarm, weil eine Person immer als letzte Instanz erhalten bleibt.
Das zweite ist KI-gesteuert. Hier ist die KI selbst die Instanz. Vier Entscheidungen werden gleichzeitig übertragen: in welche Warteschlange das Ticket fällt, was in der Erstantwort steht, ob eskaliert wird, wie es getaggt wird. Niemand gibt dazwischen irgendwo sein Okay.
Diese Unterscheidung ist für das, was im Alltag tatsächlich passiert, wichtiger als die Frage, welches Modell darunter läuft. Zwei Teams können beide behaupten, KI-gestützten Kundenservice zu betreiben, und trotzdem genau das Gegenteil tun. Es ist dieselbe Trennlinie wie zwischen einem KI-Agenten und einem traditionellen Chatbot, nur eine Ebene tiefer: Entscheidungsfindung gegen Skriptfolge.
Der Grund, warum Menschen zur gesteuerten Version greifen, ist ehrlich gesagt offensichtlich genug. Das Tier-1-Volumen ist repetitiv. Obendrein ist es einen Rückstau abzubauen von Hand eine elende Arbeit, was genau das Versprechen hinter Helpdesk-Automatisierung ist: die langweilige Hälfte läuft von selbst. Aber vier Entscheidungen auf einmal, am ersten Tag, an ein System zu übergeben, das man noch nicht einmal beobachtet hat, das ist der Weg zu den unten stehenden Threads.
Die Zahl, die verändert hat, wie ich KI-Genauigkeitsbehauptungen lese
Wir haben einen kreuzvalidierten Test bei einem deutschen Online-Schmuckhändler durchgeführt, der monatlich rund 1.000 Tickets über Zendesk und Shopify abwickelt: 284 Chats, plus eine 100-Ticket-Kreuzvalidierung gegen echten Traffic. Die Schlagzeilenzahlen waren gut. 93 % Triage-Genauigkeit. 100 % Spam-Erkennung bei null Falschpositiven, und das bei einem Postfach, das sich als zu 22 % Spam herausstellte. 88 % der Entwürfe waren inhaltlich korrekt.
Dann kommt die Zahl, auf die es eigentlich ankam: 12 % der Entwürfe wurden unverändert versendet, und die faktische Fehlerquote lag bei 7 %.
Bleiben Sie kurz bei dieser Lücke zwischen 88 und 12 stehen, es lohnt sich, sie hervorzuheben. Die KI hatte das Ticket verstanden. Sie hatte auch den richtigen Ansatz gewählt, dann etwas entworfen, dem der Support-Mitarbeiter im Prinzip zustimmte. Und trotzdem schrieb derselbe Mitarbeiter es siebenmal von acht trotzdem um. Ton, ein Detail zur Richtlinie, ein Link, oder die spezifische Formulierung, die diese Marke bei Rücksendungen verwendet.
Diese Lücke bleibt in jeder Anbieter-Genauigkeitsstatistik, die ich je gelesen habe, unsichtbar, weil "genau" und "versandfertig" nicht wirklich dieselbe Messlatte sind. Es erklärt auch ein Muster, das in Support-Communities ständig auftaucht: Teams schalten die Sache ein, verbrennen sich, und stufen sie dann still wieder herab:
"Auto-replies sounded great in theory, but once real tickets came in, it started giving confident but wrong answers. CSAT dipped quick. What worked better for us was using it as an agent assist, draft replies, summaries, tagging, not full auto mode."
Beachten Sie, was sie dort getan haben. Sie haben es nicht komplett entfernt. Sie haben es um ein Feld zurückgesetzt, von steuernd zu unterstützend, was wahrscheinlich der Punkt war, an dem es überhaupt hätte beginnen sollen. Der ursprüngliche Verfasser desselben Threads beschrieb die Triage-Version davon:
"the ai kept misclassifying things like warranty claims as general inquiries... customers complained the responses felt too robotic and sometimes gave wrong info on returns. we rolled it back partially and now our agents are using it as an assist."
Und ein Freshdesk-Nutzer aus demselben Thread landete bei dem Ergebnis, das jede Support-Führungskraft beunruhigen sollte, weil es im Grunde das Gegenteil dessen ist, was man tatsächlich gekauft hat:
"We tested an ai integration in freshdesk and had almost the exact same experience. it worked for very simple tickets but anything slightly complex got misclassified. agents ended up spending more time fixing errors than before, so we had to rethink our approach."
Die Bearbeitungszeit stieg. Nicht weil die KI schlecht darin war, Tickets zu klassifizieren als solches, sondern weil niemand die Korrekturarbeit gemessen hatte, bevor der Schalter umgelegt wurde.
Niemand berechnet Ihnen dasselbe
Hier kommt der Teil, von dem ich nicht erwartet hatte, dass er sich als der chaotischste von allen herausstellen würde, und ehrlich gesagt ist es das Erste, was ich vor allem anderen prüfen würde.
Jeder Anbieter in dieser Kategorie betreibt einen Nutzungszähler. Fast keiner von ihnen misst jedoch dasselbe Ereignis. Ich habe die veröffentlichten Preise von neun von ihnen zusammengetragen, und die Einheiten sind schlicht nicht vergleichbar.
| Anbieter | Abrechnungseinheit | Veröffentlichter Preis | Was den Zähler auslöst |
|---|---|---|---|
| Zendesk | Automatisierte Lösung | Nicht veröffentlicht | Nur wenn ohne Eskalation gelöst |
| Freshdesk | Freddy-Sitzung | $0.49 ($49 pro 100) | Der Versuch des Bots, gelöst oder nicht |
| Gorgias | Automatisierte Interaktion | $1.50 bei Überschreitung | Jede automatisierte Interaktion |
| Salesforce | Konversation oder Aktion | $2.00, oder $0.10 | Pauschal pro Konversation oder pro Tool-Aufruf |
| Ada | Lösung oder Konversation | Nicht veröffentlicht | Definition des Anbieters, nur auf Anfrage |
| Decagon | Konversation oder Lösung | Nicht veröffentlicht | Kunde wählt das Modell |
| Forethought | Unbenanntes "Ergebnis" | Nicht veröffentlicht | Einheit wird auf der Seite nirgends genannt |
| Tidio | Lyro-Konversation | $0.70 bis $0.78 | Eine Antwort von Lyro, vorausbezahlt |
| eesel | Ticket oder Chat-Sitzung | $0.40 | Ein Ticket, beliebig viele Antworten |
Drei Dinge springen aus dieser Tabelle sofort ins Auge.
Eine "Sitzung" berechnet den Versuch. Eine "Lösung" berechnet das Ergebnis. Gleiches Bot-Verhalten, unterschiedliche Rechnung. Freshdesk ist recht deutlich, eine Sitzung ist eine Interaktion und keine garantierte Lösung, sodass Sie so oder so für den Versuch bezahlen. Zendesk hingegen definiert seine Einheit so, dass nur Anfragen berechnet werden, die "erfolgreich vom KI-Agenten gelöst wurden, ohne jegliche Eskalation an einen menschlichen Mitarbeiter". Klingt für den Käufer streng genommen besser, allerdings nur, bis man bemerkt, dass Zendesk dafür nirgends auf der Preisseite einen Satz veröffentlicht. Damit landet man genau bei der günstiger klingenden Einheit, die sich nicht bepreisen lässt.
Anbieter verwenden "Lösung" und "Interaktion" synonym, und nur eine davon steht auf der Rechnung. Die Überschrift der Gorgias-Preisseite verspricht "zahlen Sie nur, wenn eine Konversation gelöst wird", was gut klingt. Aber der Zähler, der auf jeder Plankarte abgedruckt ist, bei $1.50, das ist die automatisierte Interaktion, nicht die Lösung. Wenn Sie also diese $1.50 mit dem Pro-Lösung-Preis eines anderen Anbieters vergleichen, vergleichen Sie in Wirklichkeit zwei völlig unterschiedliche Ereignisse.
Auf einem Ticket können zwei oder drei Zähler gleichzeitig auslösen. Gorgias kann im selben Monat sowohl bei Tickets als auch bei automatisierten Interaktionen überschreiten. Tidio lässt drei Zähler gleichzeitig laufen, und ein Chat, den Lyro allein bearbeitet, verbraucht eine Lyro-Konversation, und in dem Moment, in dem ein Mensch eingreift und antwortet, verbraucht er zusätzlich eine abrechenbare Konversation.
<div class="adcs-panel adcs-p1">
<div class="adcs-row adcs-best"><div class="adcs-name">eesel<span class="adcs-unit">500 Tickets zu $0.40</span></div><div class="adcs-num">$200</div></div>
<div class="adcs-row"><div class="adcs-name">Freshdesk<span class="adcs-unit">500 Sitzungen, alle innerhalb des enthaltenen Kontingents</span></div><div class="adcs-num">$0</div></div>
<div class="adcs-row"><div class="adcs-name">Tidio Lyro<span class="adcs-unit">500 vorausbezahlte Lyro-Konversationen</span></div><div class="adcs-num">$350</div></div>
<div class="adcs-row"><div class="adcs-name">Gorgias Advanced<span class="adcs-unit">500 innerhalb der 530 gebündelten Interaktionen</span></div><div class="adcs-num">$477</div></div>
<div class="adcs-row"><div class="adcs-name">Salesforce Agentforce<span class="adcs-unit">500 Konversationen zu $2.00</span></div><div class="adcs-num">$1,000</div></div>
<div class="adcs-row"><div class="adcs-name">Zendesk<span class="adcs-unit">automatisierte Lösungen, kein Preis veröffentlicht</span></div><div class="adcs-na">Nicht veröffentlicht</div></div>
</div>
<div class="adcs-panel adcs-p2">
<div class="adcs-row adcs-best"><div class="adcs-name">eesel<span class="adcs-unit">2.000 Tickets zu $0.40</span></div><div class="adcs-num">$800</div></div>
<div class="adcs-row"><div class="adcs-name">Freshdesk<span class="adcs-unit">1.500 Sitzungen über dem Kontingent, zu $49 pro 100</span></div><div class="adcs-num">$735</div></div>
<div class="adcs-row"><div class="adcs-name">Gorgias Advanced<span class="adcs-unit">Paket $477 plus 1.470 zu $1.50</span></div><div class="adcs-num">$2,682</div></div>
<div class="adcs-row"><div class="adcs-name">Salesforce Agentforce<span class="adcs-unit">2.000 Konversationen zu $2.00</span></div><div class="adcs-num">$4,000</div></div>
<div class="adcs-row"><div class="adcs-name">Tidio Lyro<span class="adcs-unit">Staffelung endet bei 1.000, darüber nur auf Anfrage</span></div><div class="adcs-na">Nicht veröffentlicht</div></div>
<div class="adcs-row"><div class="adcs-name">Zendesk<span class="adcs-unit">automatisierte Lösungen, kein Preis veröffentlicht</span></div><div class="adcs-na">Nicht veröffentlicht</div></div>
</div>
<div class="adcs-panel adcs-p3">
<div class="adcs-row adcs-best"><div class="adcs-name">eesel<span class="adcs-unit">5.000 Tickets zu $0.40</span></div><div class="adcs-num">$2,000</div></div>
<div class="adcs-row"><div class="adcs-name">Freshdesk<span class="adcs-unit">4.500 Sitzungen über dem Kontingent, zu $49 pro 100</span></div><div class="adcs-num">$2,205</div></div>
<div class="adcs-row"><div class="adcs-name">Gorgias Advanced<span class="adcs-unit">Paket $477 plus 4.470 zu $1.50</span></div><div class="adcs-num">$7,182</div></div>
<div class="adcs-row"><div class="adcs-name">Salesforce Agentforce<span class="adcs-unit">5.000 Konversationen zu $2.00</span></div><div class="adcs-num">$10,000</div></div>
<div class="adcs-row"><div class="adcs-name">Tidio Lyro<span class="adcs-unit">Staffelung endet bei 1.000, darüber nur auf Anfrage</span></div><div class="adcs-na">Nicht veröffentlicht</div></div>
<div class="adcs-row"><div class="adcs-name">Zendesk<span class="adcs-unit">automatisierte Lösungen, kein Preis veröffentlicht</span></div><div class="adcs-na">Nicht veröffentlicht</div></div>
</div>
</div>
<div class="adcs-foot">Preise von der jeweils eigenen Preisseite des Anbieters, geprüft am 27. Juli 2026. Freshdesk enthält die ersten 500 Freddy-Sitzungen in jedem Plan. Die Gorgias-Zahlen verwenden die im Advanced-Plan gebündelte KI-Komponente und deren $1.50-Überschreitungsgebühr. Salesforce verkauft zudem einen Flex-Credits-Zähler zu $0.10 pro Aktion, was nach eigener Rechnung $0.30 bis $0.60 für denselben Austausch ergibt. Sitzplatzlizenzen sind durchgehend ausgeschlossen.</div>
Bei 5.000 Konversationen beträgt die Spanne etwa das Fünffache zwischen dem günstigsten und dem teuersten veröffentlichten Preis. Das ist kein Rundungsunterschied, und auch kein echter Qualitätsunterschied, sondern schlicht und einfach ein Unterschied in der Definition der Einheit.
"Gelöst" ist eine Ermessensentscheidung, und bezahlt wird der Anbieter dafür
Das ist der Teil, der zu einer öffentlichen Debatte wurde, und ich glaube ehrlich gesagt, es ist das mit Abstand Wichtigste, das man verstehen sollte, bevor man irgendeinen Zielwert auf ein Dashboard setzt.
Ada zieht diese Linie klar, direkt auf der eigenen Website: Containment zählt Konversationen, die nicht eskaliert wurden, "einschließlich frustrierter Kunden, die aufgegeben haben", während eine automatisierte Lösung auch Relevanz, Genauigkeit und Sicherheit bestehen soll. Zwei Zahlen, sehr unterschiedliche Bedeutung, und es ist meist die weichere, die zitiert wird.
Decagon geht sogar noch weiter, und ich respektiere die Firma sehr dafür, das tatsächlich zu veröffentlichen. Ihr eigenes Glossar räumt ein, dass die Definition einer Lösung "Grauzonen und Abrechnungsstreitigkeiten" schafft, dass die Abrechnung von Monat zu Monat weniger vorhersehbar wird, und dass es einen Anreiz für Anbieter gibt, eine Konversation überzuklassifizieren als gelöst. Das sagt der Anbieter Ihnen im Grunde direkt: Der Zähler hat einen Daumen auf der Waage.
Support-Teams haben das selbst herausgefunden. Als Zendesk zu einer Preisgestaltung nach automatisierter Lösung wechselte, kam der r/Zendesk-Thread direkt zum Punkt:
"the subjective part in the resolutions. who knows if the bot is just leaving the customer hanging and marking it as a resolution... the bot just didn't help the customer in anyway. they got agitated and abandoned the chat and it was considered a resolution"
Und hier ist die strukturelle Version derselben Beschwerde, die ehrlich gesagt das Schärfste war, was ich bei dieser ganzen Recherche gelesen habe:
"What is defined as a resolution isn't really fair. If it's an abandoned deflection, it shouldn't count. Mechanisms to understand that aren't well-tuned. This creates an incentive misalignment where, theoretically, creating abandonment would make sense as it would maximize 'resolutions' as currently defined."
Um fair zu sein, ich glaube nicht, dass irgendein Anbieter Abbrüche absichtlich herbeiführt. Aber die Anreizstruktur ist real, und sobald man sie einmal gesehen hat, kann man sie nicht mehr unsehen: Man hört auf, die KI-Lösungsquote als Qualitätskennzahl zu lesen. Es ist eine Abrechnungskennzahl, die nur zufällig wie eine solche aussieht, und dieselbe Vorsicht gilt für jede zitierte Deflection-Zahl ebenfalls.
Was ich stattdessen verfolgen würde, und was wir intern auch tatsächlich anschauen:
- Wiedereröffnungsquote bei KI-bearbeiteten Tickets. Eine Lösung, die innerhalb von 48 Stunden zurückkommt, war keine Lösung. Von allen Zahlen die am schwersten zu fälschende.
- Nach Bearbeiter aufgeschlüsselter CSAT. Der CSAT der gesamten Warteschlange verbirgt ein KI-Problem hinter guter menschlicher Arbeit. Also aufschlüsseln.
- Kundenaufwand bei eskalierten Tickets. Wie viele Runden hat jemand mit dem Bot verbrannt, bevor er endlich einen Menschen erreicht hat.
- Bearbeitungsquote bei Entwürfen. Unsere 12%-Zahl gehört hierher. Wenn Entwürfe immer wieder umgeschrieben werden, kostet die KI eher Mitarbeiterzeit, als dass sie sie spart. Nehmen Sie das in Ihre Support-QA-Prüfung auf, statt es der Anekdote zu überlassen.
Nichts davon ist wirklich exotisch, die meisten Helpdesks könnten das heute berichten, wenn sie wollten. Es ist nur weniger schmeichelhaft als die Deflection, weshalb es auch nie die Folie anführt.
Wo KI-gesteuerter Support seinen Platz verdient
Ich war jetzt vier Abschnitte lang hart mit dieser Kategorie, also lassen Sie mich kurz fair sein, die Erfolge hier sind real, und sie sind auch spezifisch.
Spam und Triage. Das Postfach des Schmuckhändlers bestand zu 22 % aus Spam, und die KI erfasste ihn zu 100 %, null Falschpositive. Das ist kein marginaler Gewinn, das ist ein ganzes Fünftel der Warteschlange, das kein Mensch je hätte sehen müssen. Eine Triage-Genauigkeit von 93 % schlägt auch, ehrlich gesagt, das, was die meisten müden Menschen freitags um 17 Uhr noch zustande bringen.
Repetitives Tier-1-Volumen. Gridwise, eine Analyse-App für Fahrer in der Gig-Economy, die auf Zendesk läuft, berichtete, dass eesel im ersten Monat 73 % der Tier-1-Anfragen gelöst hat, nachdem bereits innerhalb einer 7-Tage-Testphase Ergebnisse sichtbar waren. Der interne IT-Helpdesk von InDebted auf Jira Service Management liegt bei 15 % Deflection mit einem Ziel von 55 %, und das ist eigentlich die typischere Form, die eine ehrliche Einführung annimmt: real, schrittweise, keine Pressemitteilung.
Kategoriespezifisches Entwerfen. Im selben Test lag die Entwurfsnützlichkeit nach Kategorie bei 100 % für Produktanfragen und Erstattungsstatus, 96,4 % für Garantieansprüche, 93,8 % für Retouren und Erstattungen. Die KI war hervorragend bei engen, gut dokumentierten Fragen und nur mittelmäßig bei allem anderen. Das ist eine Anweisung zum Umfang, kein wirkliches Urteil.
Und das Gegengewicht-Zitat, von einem Team, bei dem das tatsächlich funktioniert hat:
"Ada is able to take on the small stuff. So much of support is made up of monotonous, easy-to-answer inquiries... Ada handles the majority of those inquiries, so our team is able to handle the big stuff... it has cut our teams response time into a third of what it was pre-Ada."
Jeder einzelne dieser Erfolge hat dieselbe Form: enger Umfang, hohes Volumen, gut dokumentierte Antwort. Nichts davon bedeutet "richte es auf die gesamte Warteschlange und schau, was passiert", nicht einmal annähernd.
Die Kontrolleinstellung, die entscheidet, ob das funktioniert
Wenn Sie nur eine operative Sache aus diesem Beitrag mitnehmen, dann diese. Das entscheidende Merkmal ist überhaupt nicht das Modell. Es ist, ob Sie der KI sagen können, was sie nicht entscheiden darf.
Die klarste Aussage dazu, die ich je gehört habe, kam von einer CX-Leiterin einer DTC-Nahrungsergänzungsmittelmarke, die Gorgias und Shopify betreibt, bei etwa 7.000 Tickets und 30.000 Bestellungen pro Monat:
"The AI will never be able to answer 100% of the questions, but if it tries and just answers 'sorry I don't know this,' I cannot go and check all my 7,000 tickets to see if the AI actually made a good answer, then the point is a little bit gone. I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."
Genau das war das entscheidende Ausschlusskriterium in diesem Gespräch. Nicht Genauigkeit, nicht Preis, nicht Integrationen, nichts davon. Nur ob man der KI beibringen konnte, in ihrer Spur zu bleiben oder nicht. Wir hatten damals kein konfidenzbasiertes Routing, das scharf genug war, und wir haben diesen Deal verloren, was genau die Art von Sache ist, die am Ende verändert, wie ein Produkt gebaut wird.
Die Tore, die es sich zu fordern lohnt, in dieser Reihenfolge:
- Ausschluss nach Tickettyp. Abrechnungsstreitigkeiten, Rechtliches, Sicherheit, alles mit einer Erstattung über einem Schwellenwert. Einer unserer eigenen Administratoren brachte es in einem Chat unverblümt auf den Punkt: "Es gibt bestimmte Tickets, die ich nicht durch die KI laufen lassen möchte." Das sollte wirklich eine Einstellung sein, kein Feature-Wunsch.
- Eine verschiebbare Konfidenzschwelle. Darunter erstellt die KI einen Entwurf statt zu senden. Prüfen Sie vor dem Kauf, ob das Tool überhaupt eine Intent-Konfidenzschwelle bietet, denn viele tun das nicht.
- Explizite Auslösung. Ein anderer Evaluator wollte genau das: "Ich möchte nur eine Antwort, wenn ich @eesel erwähne, nicht bei der Erstellung und nicht bei jeder Kunden-Ticket-Nachricht." Bei jedem einzelnen Ticket auszulösen ist eine Entscheidung, und es sollte Ihre Entscheidung sein, sie zu treffen.
- Eine saubere Übergabe. Mit vollständig übertragenem Kontext, sodass der Kunde sich nicht wiederholen muss. Den Übergabepunkt richtig zu setzen ist wichtiger, als die Deflection-Zahl nach oben zu treiben.
- Eine Feedback-Schleife, die tatsächlich trainiert. Einen Entwurf mit Begründung abzulehnen sollte den nächsten Entwurf verändern. Das ist es, was einen KI-Agenten zu coachen in der Praxis bedeutet.
Der Screenshot oben ist die Version davon, die ich am häufigsten nutze. Statt sich durch ein Einstellungsfeld zu wühlen, sagt man dem Agenten die Regel einfach in klarem Englisch, und er schreibt seine eigenen Anweisungen um. In diesem Fall: Wenn in Zendesk getaggt, immer eine kundengerichtete Antwort entwerfen, statt eine interne Notiz zu hinterlassen.
Eine Einführungsreihenfolge, die die Zahlen ehrlich hält
Das ist die Abfolge, die ich selbst durchführen würde, und sie ist bewusst langsamer als das, was die meisten Onboarding-Dokumente vorgeben.
- Zuerst gegen historische Tickets simulieren. Bevor auch nur ein Kunde etwas sieht, den Agenten über bereits geschlossene Tickets laufen lassen und seine Antwort mit dem vergleichen, was Ihr Team tatsächlich gesendet hat. Wir haben diesen Schritt eingebaut, weil wir selbstbewusste Bots in der Produktion falsche Antworten geben sehen haben, und einmal war für uns schon genug.
- Mindestens zwei Wochen Entwurfsmodus. Die Bearbeitungsquote verfolgen, nicht die Genauigkeit. Wenn Ihre Mitarbeiter weiterhin die meisten Entwürfe umschreiben, ist das ein Wissensproblem, kein Modellproblem, und keine Menge an Auto-Reply wird das beheben.
- Das Wissen reparieren, bevor der Umfang erweitert wird. Ein G2-Rezensent zu Agentforce hat dieses Fehlermuster gut beschrieben: "Wenn Ihre Content-Version-Dateien (Wissensartikel) seit 2021 nicht aktualisiert wurden, gibt der KI-Agent den Kunden selbstbewusst veraltete Informationen." Auf einer aktuellen Wissensdatenbank zu trainieren, das ist der größte Teil der eigentlichen Arbeit.
- Auto-Reply für genau eine Kategorie. Wählen Sie diejenige mit der höchsten Entwurfsnützlichkeit. Bestellstatus ist hier meist die Antwort. Beobachten Sie danach vierzehn Tage lang die Wiedereröffnungen.
- Eine Kategorie nach der anderen erweitern. Bestellverfolgung, dann Retouren, dann Garantie. Ticket-Routing kann sich schneller erweitern lassen als Auto-Reply, weil eine falsche Route nur Minuten kostet, während eine falsche Antwort Vertrauen kostet.
- Ihr Ausgabenlimit am ersten Tag festlegen. Dieselbe Agentforce-Bewertung beschrieb, was sonst passiert: Wenn ein Agent "in einer Schleife hängen bleibt oder einen unerwarteten Anstieg im Feiertagsverkehr bearbeitet, kann Ihre 'digitale Geldbörse' an Credits schneller leerlaufen als erwartet". Limits sind langweilig, aber sie retten tatsächlich Wochenenden.
Schritt 2 ist der, der am häufigsten übersprungen wird, und es ist der, der sich tatsächlich auszahlt. Alles in diesem Beitrag, was mich überrascht hat, kam daher, dass ich gelesen habe, was die KI gesagt hätte, direkt neben dem, was wir tatsächlich gesagt haben.
eesel für KI-gesteuerten Kundenservice ausprobieren
Wir setzen inzwischen seit Jahren KI-Agenten in echte Support-Warteschlangen ein, unter anderem bei Einführungen wie dem vollständig automatisierten deutschen Zendesk-Agenten von Smava mit über 100.000 Tickets pro Monat, und den über 10.000 von Ecosa über Zendesk, Slack und die eigene Website (Fallstudie). Das meiste in diesem Beitrag ist Narbengewebe aus genau diesen Einführungen.
eesel ist um zwei Dinge herum aufgebaut, auf die ich selbst bestehen würde, wäre ich der Käufer. Erstens: Der Agent läuft im Entwurfsmodus, bis Sie damit zufrieden sind, sodass nichts einen Kunden erreicht, bevor Sie gelesen haben, was er gesagt hätte. Zweitens: Die Einheit ist ein Ticket, keine Lösung: $0.40 pro bearbeitetem Ticket oder Chat-Sitzung, egal wie viele Antworten es braucht, keine Sitzplatzgebühren, außerhalb von Enterprise auch keine Plattformgebühr. Niemand kann einen abgebrochenen Chat in einen abrechenbaren Erfolg umklassifizieren, weil es einfach nichts gibt, das umklassifiziert werden könnte.
Es lässt sich mit Zendesk, Freshdesk, Gorgias, Front, Jira Service Management und Slack verbinden, und es liest das Wissen, das Sie bereits in Confluence, Notion, Google Docs und Ihren vergangenen Tickets gespeichert haben. Die meisten Teams bringen ihren ersten Agenten in etwa 30 Minuten zum Laufen. Sie erhalten $50 an kostenloser Nutzung, keine Kreditkarte nötig, was bei $0.40 pro Ticket 125 echten Tickets entspricht, um es zu beurteilen.
Wenn Sie es lieber an Ihrer eigenen Warteschlange sehen möchten als an einer Demo-Warteschlange, starten Sie kostenlos und richten Sie es auf die Tickets des letzten Monats. Allein die Bearbeitungsquote wird Ihnen an einem Nachmittag mehr sagen als jeder Anbieter-Benchmark.
Häufig gestellte Fragen
Was ist KI-gesteuerter Kundenservice?
Wie viel kostet KI-gesteuerter Kundenservice pro Ticket?
Ist die Lösungsquote eine gute Möglichkeit, KI-Kundenservice zu messen?
Was ist der Unterschied zwischen Deflection und Lösung im KI-Support?
Wie verhindere ich, dass KI-Kundenservice Dinge beantwortet, die er nicht sollte?
Kann KI-gesteuerter Kundenservice für ein kleines Support-Team funktionieren?
Sollte KI-Kundenservice zuerst im Auto-Reply- oder im Entwurfsmodus laufen?
Article by
Riellvriany Indriawan
Riell is a designer and writer at eesel AI with about two years of experience researching CX platforms, AI chatbots, and helpdesk software. She combines her design background with a sharp eye for how these tools actually look and feel in practice — making her comparisons unusually visual and user-focused.
