Support-Ticket-System: So richtest du eines ein, das hält

Was ein Support-Ticket-System eigentlich ist

Ein Support-Ticket-System ist im Kern das, was ein Gespräch in einen Datensatz verwandelt. Eine E-Mail, ein Chat, eine WhatsApp-Nachricht und ein Webformular landen alle am selben Ort, bekommen eine Nummer, einen Verantwortlichen, einen Status und eine Uhr, und bleiben dort, bis jemand sie schließt.

Das klingt offensichtlich, bis man es tatsächlich mit dem gemeinsamen Postfach vergleicht, das es ersetzt. In einem Postfach lebt der Zustand einer Anfrage im Kopf von irgendjemandem oder daran, ob der Thread gelesen aussieht. In einem Ticket-System ist der Zustand ein Feld, Punkt. Diese eine Veränderung macht Routing, SLAs, Reporting und jede Art von automatisierter Ticket-Lösung erst möglich, weil Software ein Feld lesen kann, aber keine Ahnung.

Das bezahlst du eigentlich:

• Eingehende Kanäle. E-Mail, Chat-Widget, ein Kundenportal, WhatsApp, Telefon und zunehmend eine API aus der eigenen App.
• Ein Ticket-Datenmodell. Felder, Status, Priorität, Typ, Tags. Das ist der Teil, den alle unterschätzen.
• Routing und SLA. Wer es bekommt, in welcher Reihenfolge und bis wann.
• Eine Wissensebene. Das Help Center plus die Makros und gespeicherten Antworten, die deine Agenten tatsächlich nutzen.
• Reporting. Ob man "was ist letzten Monat passiert" beantworten kann, ohne nach Excel zu exportieren.
• Eine KI-Ebene, mittlerweile Standard und separat abgerechnet.

Die Schleife in diesem Diagramm ist der Teil, der später zubeißt. Felder entscheiden, was man reporten kann, und beim Reporting stellt man sechs Monate später fest, dass man genau das eine Feld, das man jetzt tatsächlich braucht, nie erfasst hat.

Das Signal, dass du das gemeinsame Postfach überwachsen hast

Volumen ist hier ehrlich gesagt das schlechteste Signal, an dem man sich orientieren kann. Ich habe Zweier-Teams mit 40 E-Mails am Tag gesehen, die wirklich keinen Desk brauchten, und Fünfer-Teams mit 200, die einen Desk ein Jahr früher gebraucht hätten, als sie ihn bekamen. Die eigentlichen Auslöser sind strukturell, nicht numerisch.

Man braucht ein Support-Ticket-System in dem Moment, in dem eine Anfrage die Abwesenheit einer einzelnen Person überstehen muss, wenn zwei Agenten weiter demselben Kunden antworten, wenn jemand anfängt, Zahlen von einem zu verlangen, die man nicht liefern kann, oder wenn man einem Kunden schriftlich eine Antwortzeit zusagt. Letzteres ist wirklich die harte Grenze. Ein SLA ohne zeitgestempelten Datensatz ist nur ein Wunsch.

Es gibt auch einen leiseren Auslöser, nämlich wenn der bisherige Anbieter nicht mehr passt. Diese Bewertung ist die klarste Version davon, die ich gelesen habe:

"Zendesk is very configurable, though I struggle to think of what I like about Zendesk. I found the reporting tool in particular to be very difficult to use. Their AI offerings felt bolted on versus integrated, and their integrations didn't work particularly well. Support was not timely. Pricing was not competitive. This is why we moved to another tool."

Gail D., Senior Director of Customer Support, G2

Vier verschiedene Gründe in einem Atemzug, und keiner davon lautet "es kann kein Ticket speichern". Genau so sieht es in der Praxis aus, wenn man einen Desk überwächst, und es lohnt sich, das zu lesen, bevor man sich für die nächsten fünf Jahre auf eine Plattform festlegt. Wenn du schon an diesem Punkt bist, sind unser Vergleich von Help-Desk-Software und der Vergleich von Ticketing-System-Software die Shortlists, mit denen ich anfangen würde.

In dieser Reihenfolge einrichten

Jedes gescheiterte Rollout, das ich gesehen habe, hat Schritt zwei übersprungen und ist direkt zu Automatisierungen gesprungen. Hier ist die Reihenfolge, der ich folgen würde, und was man an jeder Station tatsächlich entscheiden sollte.

Schritt 1: Kanäle, und ein Ort, an dem sie alle landen

Aktiviere die Kanäle, die du tatsächlich besetzen kannst, nicht nur die auf der Feature-Liste. Jeder Kanal, den man einschaltet, ist eine Queue, die jemand im Auge behalten muss, und die Kosten pro Kontakt unterscheiden sich je nach Kanal enorm. HDIs Zahlen von 2021 setzen Self-Help bei 2,37 $ pro Ticket an, Web-Formular bei 15,07 $, Chat bei 15,72 $, E-Mail bei 16,13 $, Sprache bei 17,19 $ und persönliche Vorsprache bei 37,52 $ – eine Spanne, die die Quelle selbst "100X" nennt.

Hier zwei praktische Regeln. Route alles in eine Queue, selbst wenn es aus fünf verschiedenen Kanälen kommt, denn eine zweite Queue ist nur ein zweiter Rückstand, den freitags niemand kontrolliert. Und bei E-Mail speziell: Schick sofort eine Empfangsbestätigung mit der Ticket-ID in der Betreffzeile – diese ID sorgt dafür, dass eine Antwort dem richtigen Datensatz zugeordnet bleibt, statt ein Duplikat zu öffnen. Dieser Mechanismus ist im Grunde der ganze Unterschied zwischen einem Thread und einem Ticket, und wir haben ihn in unserem Leitfaden zu E-Mail-Help-Desk-Software auseinandergenommen.

Schritt 2: Felder, vor allem anderen

Felder sind das Schema deines gesamten Betriebs. Zendesks Standardsatz besteht aus Anfragesteller, Follower, Verantwortlicher, CC, Freigabe, Betreff, Beschreibung, Status, Typ, Priorität, Tags, Genehmigungsstatus, Lösungstyp, Lösungsstufe und Kanalgruppe, wobei der Betreff laut der Ticketfelder-Dokumentation auf 255 Zeichen begrenzt ist und die Beschreibung gleichzeitig als erster Kommentar dient. Freshdesk liefert 11 Standardfelder, die nicht gelöscht werden können.

Zwei Fallen, die man kennen sollte, bevor man anfängt, eigene Felder hinzuzufügen:

• Ein Feld zu deaktivieren kann still und leise etwas anderes kaputt machen. Schaltet man Zendesks Prioritätsfeld aus, gelten laut Zendesk selbst "SLA-Ziele nicht mehr". Schaltet man den Typ aus, setzt jedes Ticket standardmäßig auf Incident.
• Ein Dropdown zu bearbeiten zerstört die Historie. Freshdesk sagt es unverblümt: "Wenn du eine Dropdown-Option änderst oder löschst, die bei einem bestehenden Ticket verwendet wird, wird der Wert dieses Felds auf null gesetzt."

Auch benutzerdefinierte Felder sind eine Plan-Sperre, was man vorab wissen sollte. Bei Freshdesk gibt es sie ab Growth mit Obergrenzen je Typ – 80 einzeilige Textfelder, 10 mehrzeilige, 80 Dropdowns – und mehr bei Pro und Enterprise. Entscheide dich für die Handvoll Felder, die du tatsächlich für Reports nutzt, benenne sie einmal sauber und widerstehe dem Drang, für jeden Sonderfall ein neues Feld hinzuzufügen. Für den Long Tail gibt es ohnehin Tags, und Ticket-Tags lassen sich später viel leichter aufräumen als ein Dropdown, auf dem schon jemand einen Workflow aufgebaut hat.

Schritt 3: Status, und die zwei Regeln zum Schließen

Bei den Status sind sich die Anbieter still uneinig, und hier verrotten die meisten Queues am Ende. "Offen" bedeutet bei niemandem dasselbe wie bei dir.

Zendesk hat sechs Status (New, Open, Pending, On-hold, Solved, Closed), und drei seiner Regeln überraschen viele. New ist eine Einbahnstraße, denn "nachdem der Status von New auf einen anderen geändert wurde, kann er nicht mehr auf New zurückgesetzt werden". On-hold bleibt für den Kunden unsichtbar, der weiterhin Open sieht. Und "Tickets können überhaupt nicht manuell auf Closed gesetzt werden" – das Schließen ist eine Automatisierung: standardmäßig vier Tage nach Solved, mit einer harten Obergrenze, nach der Tickets 28 Tage nach der Lösung schließen, und jede Regel, die das überschreiten will, "wird nicht berücksichtigt".

Freshdesk behält vier Status und zieht die Grenze etwas anders: Resolved bedeutet erledigt "aus Sicht des Agenten" und Closed bedeutet erledigt "aus Sicht des Kunden", mit automatischem Schließen 72 Stunden nach Resolved. Jira Service Management verwendet zwei Namen für einen Zustand, sodass ein internes "Waiting for Customer" dem Anfragesteller als "Requester Action Needed" angezeigt wird. HubSpot hat eigentlich gar kein Statusfeld, sondern nur Pipeline-Phasen, die standardmäßig als Status bezeichnet werden.

Hier ist dasselbe Gespräch, erzählt in vier verschiedenen Desks. Wähle deinen:

Der Grund, warum das mehr als nur eine Randnotiz ist: Dein Reporting übernimmt diese Definitionen, was auch immer sie sind. Wenn "offen" auf deinem Desk jedes Ticket einschließt, das auf einen schweigenden Kunden wartet, ist deine Rückstandszahl fiktiv – und trotzdem wird man dich irgendwann anhand dieser Zahl bewerten.

Diese Aufteilung ist übrigens nicht hypothetisch:

"I was going through our queue today and found 90 tickets where we responded, asked for more information from the customer but then never heard back from them. They just sit there inflating our numbers and that honestly doesn't look good for management. We have been called before for unresolved open tickets so this is a big deal."

Our Help desk ticketing system shows 200 open tickets but half of them have had no user response, Reddit

Die Lösung ist eine Auto-Close-Regel plus die Disziplin, ihr tatsächlich zu vertrauen. Ein IT-Manager schrieb in r/ITManagers, dass das automatische Schließen von Tickets, die älter als fünf Tage sind, "den Rückstand einer Gruppe sofort um 54% reduziert hat". Für Kunden wurde dadurch auch nichts schlechter, da eine Antwort das Ticket ohnehin wieder öffnet.

Schritt 4: Routing, Priorität und SLA sind ein System

Behandelt man diese drei als separate Einstellungen, geraten sie früher oder später aneinander. Die Priorität speist die SLA-Richtlinie, und das Routing entscheidet, wer tatsächlich auf die Uhr achtet.

Beginne mit der Prioritätsfrage – sie ist es, die tendenziell politisch wird. Lass Anfragesteller sie nicht selbst festlegen. Das ist der meistbewertete Kommentar zu diesem Thema, mit 371 Upvotes, und er hat sich gut gehalten:

"Dealt with this decades ago. It was scrapped quickly because as you might imagine it was abused to death. It really didn't bother me though. I still got the same number of tickets and just slogged through them. When people got mad because we were missing SLAs we just replied there was nothing we could do now that all tickets were priority."

u/bitslammer, Reddit

Lege die Priorität selbst fest, anhand von Regeln, auf Basis von Dingen, die man tatsächlich beobachten kann: Plan-Stufe, Bestellwert, Stichwort, Kanal oder ein Kunde, der schon dreimal geantwortet hat. Freshdesk hat seine vier Prioritätswerte fest codiert, gerade weil sie "direkt an die SLA-Richtlinien-Funktionalität gebunden" sind – man konfiguriert damit also, ob man will oder nicht, tatsächlich das SLA.

Dann kommt das SLA selbst. Wähle Ziele, die man in der schlechtesten Woche erreichen kann, nicht in der besten, definiere Geschäftszeiten ehrlich, und denke daran, dass Pending existiert, um die Uhr anzuhalten, während der Kunde derjenige ist, der die Sache blockiert. Freshdesks mehrere SLA-Richtlinien beginnen ab Pro, sodass es bei Growth zwar den eingebauten SLA-Report gibt, man ihn aber nicht nach Kunde oder Produkt segmentieren kann. Wenn du die ausführlichere Version davon willst, haben wir SLA-Management mit KI und SLA-Eskalationsautomatisierungen separat aufgeschrieben.

Das Routing selbst ist ehrlich gesagt die einfachere Hälfte: Skills oder Gruppen, ein Fallback-Verantwortlicher für alles Unzugeordnete und ein Alert, wenn ein Ticket eine Stunde lang ohne Zuständigen liegt. Wenn dir lieber wäre, das würde passieren, ohne dass du dutzende Regeln selbst schreibst, lesen sowohl KI-Ticket-Routing als auch Ticket-Priorisierung den Ticket-Text statt sich auf eine Stichwortliste zu verlassen, und die Ticket-Klassifizierung taggt es gleich beim Eingang.

Schritt 5: die Wissensdatenbank, und die Zahl, die niemand druckt

Jeder Anbieter zeigt dir eine Deflection-Grafik. Die ehrliche Zahl ist kleiner als das. MetricNets Benchmarking-Datenbank setzt die durchschnittliche Self-Service-Abschlussrate bei 10,4% an, von null bei Desks ohne Self-Service bis zu 55% am oberen Ende, und der frühere Durchgang von 2018 hat 8,9% gemessen, wobei die meisten dieser selbst gelösten Vorfälle einfache Passwort-Zurücksetzungen waren.

Eine Wissensdatenbank aufzubauen lohnt sich also durchaus, aber es lohnt sich nicht, so zu tun, als würde sie die Queue allein halbieren. Baue sie aus den Tickets, die tatsächlich eingehen, mit den Worten, die Kunden tatsächlich verwenden. Und plane auch Verfall ein, denn der ist so ziemlich universell:

"I run a small team, and we have an internal wiki for processes, FAQs, and troubleshooting. The problem? No one updates it. People keep asking the same questions in Slack instead of checking the wiki."

Keeping a Knowledge Base Up to Date is a Nightmare, Reddit

Zwei Dinge helfen hier wirklich. Mache das Schreiben des Artikels zu einem Teil des Schließens des Tickets selbst, nicht zu einem separaten Freitagsprojekt. Und lege eine Suchebene über alles, statt zu erwarten, dass die Leute danach browsen – genau das ist die Idee hinter einem KI-Wissensdatenbank-Chatbot.

Wenn deine Inhalte an fünf verschiedenen Orten liegen, ist die Frage des Abrufs wichtiger als das Help-Center-Theme, das man gewählt hat, und eine aufgeräumte interne Wissensdatenbank ist das, was den Rest tatsächlich zum Funktionieren bringt.

Schritt 6: Reporting, die Ebene, die man später nicht mehr reparieren kann

Das ist der Schritt, den man gern bis zum Quartalsende liegen lässt. Dann ist es zu spät – ein Report kann nur nach einem Feld gruppieren, das bereits existierte.

Schlimmer noch: Der Report-Builder selbst entpuppt sich als Plan-Sperre, und der Preis dieser Sperre ist auch nicht gerade klein.

Auch Zendesks eigene Live-Dashboards werden schrittweise abgeschafft: Sie sind auf Accounts beschränkt, die vor dem 5. Mai 2026 auf Explore zugegriffen haben, und am 25. Januar 2027 werden vorgefertigte Live-Dashboards und die Möglichkeit, sie zu erstellen, komplett aus Explore entfernt.

Wenn das native Reporting schwach ist, sieht der Workaround immer gleich aus, und er kostet eine Personenwoche pro Monat:

"The reports and automations can be somewhat difficult to navigate. We ended up just exporting all of our tickets every month and creating our own reports through Power query in Excel."

Trent B., Director of Client Care, Capterra

Zwei Kennzahlen, die man dabei richtig verstehen sollte. First Contact Resolution ist eine Qualitätskennzahl, First Level Resolution eine Kostenkennzahl, und HDI stellt explizit klar, dass die beiden nicht austauschbar sind: Die Netto-FLR liegt im Schnitt bei 74,3%, und nur 1,4% der Service Desks erreichen 95%. Und Vorsicht auch bei der One-Touch-Resolution: Zendesks eigene Definition zählt Tickets "mit einer einzigen Agenten-Antwort oder keiner Antwort", was bedeutet, dass ein gerade gelöschtes Spam-Ticket immer noch als Erfolg zählt.

Auf der Zufriedenheitsseite ist CSAT-Reporting eine eigene Konfigurationsaufgabe, die man sich lohnt, direkt in derselben Woche und nicht im darauffolgenden Quartal einzurichten.

Die KI-Ebene ist eine zweite Preisliste

Jeder Desk verkauft mittlerweile KI oben drauf auf den Sitzplatz, und die Zähler stimmen überhaupt nicht miteinander überein. Ehrlich gesagt beeinflusst die Einheit die Rechnung stärker als der Satz, also zuerst die Einheit lesen.

Die Lücke zwischen "gelöst" und "engagiert" ist der Punkt, an dem die Rechnungen anfangen, seltsam zu werden. Zendesks Drei-Stufen-Modell, seit dem 18. Mai 2026 live, rechnet nur die verifizierte Lösung ab, was tatsächlich fairer ist als das, was davor kam – auch wenn die Änderung nicht bei allen gut ankam, die das alte Modell miterlebt haben:

"Complete trash lol, stuff I used to get free now counts as an AR. Most of the ARs are abandoned chats. There's no dispute resolution process. Complete scam. I used to like Zendesk but since trying the new bot and now this I have little good will left"

u/Kerrick, Reddit

Die Angaben zur Obergrenze verdienen ehrlich gesagt denselben Skeptizismus. Zendesk bewirbt KI-Agenten auf seiner Service-Seite damit, dass sie "bis zu 80% der Interaktionen automatisieren" könnten, während MetricNets Einschätzung des Feldes lautet, dass führende Organisationen bis zu 50% automatisieren. Beides kann gleichzeitig stimmen, bei unterschiedlichen Queues, und genau deshalb testet man es an der eigenen, bevor man irgendetwas unterschreibt. Wir haben aufgeschrieben, wie eine realistische KI-Lösungsrate tatsächlich aussieht, und was ein KI-Help-Desk eigentlich tut, falls du das größere Bild willst.

Eine Sache, auf die ich noch bestehen würde, aus Erfahrung statt aus Theorie. Frag, was die KI tut, wenn die Wissensdatenbank keine Antwort dafür hat. Wir hatten zahlende Kunden, darunter einen dänischen Solarenergie-Anbieter, deren Bot diese Lücke gefüllt hat, indem er Behauptungen erfand und sie direkt an echte Menschen geschickt hat. Ein Konfidenz-Schwellenwert und ein Fallback zum Nicht-Antworten sind keine nette Zugabe, sie sind der Unterschied zwischen Halluzinationen verhindern und einer ganz neuen Ticket-Kategorie.

Was ein Ticket kostet, sobald es eskaliert

Volumen ist eigentlich nicht das, was Support teuer macht. Eskalation schon.

MetricNets Kostenleiter setzt Level 1 bei 22 $, Desktop-Support bei 62 $, Level 3 bei 85 $, Field Support bei 196 $ und Vendor Support bei 471 $ an, und das Schlüsselwort hier ist kumulativ: Ein auf Level 1 erfasstes und auf Level 2 eskaliertes Ticket kostet "62 $ plus 22 $, macht zusammen 84 $". Das sind Dollar von 2011, also sollte man sie eher als Verhältnisse behandeln als als aktuelles Angebot. Das Verhältnis ist wirklich der Punkt, und deshalb ist die Maximierung der First-Level-Resolution in MetricNets Rahmen im Grunde dasselbe wie die Minimierung der Gesamtkosten.

Zwei unterstützende Zahlen, die man im Kopf behalten sollte. Gehälter und Zusatzleistungen der Agenten machen mehr als die Hälfte der Kosten eines Service Desks aus, und rund zwei Drittel der Gesamtkosten sind am Ende Personalkosten, sobald man Supervisor, QA und Trainer mitzählt. Und die Auslastung der Agenten liegt im Schnitt bei 48%, mit der Warnung, dass Raten nahe 60 bis 70% "eine relativ hohe Agenten-Fluktuation erzeugen, weil die Agenten zu sehr gefordert werden".

Der ehrliche Business Case für ein Support-Ticket-System lautet also nicht "es spart Zeit bei jeder Antwort". Er lautet, dass Struktur Tickets von vornherein daran hindert, die Leiter hochzuklettern: bessere First-Level-Resolution, weniger Wiedereröffnungen, weniger Übergaben. Das gilt auch für den Einsatz von KI auf der Tier-1-Bandbreite statt auf allem gleichzeitig, und ist der Grund, warum Ticket-Deflection an vermiedenen Eskalationen gemessen wird, nicht an gesendeten Nachrichten.

Wenn Eskalationen bereits dein Problem sind, mehr als Volumen, dann ist Eskalationsmanagement der Teil des Setups, an dem ich als Erstes arbeiten würde, noch vor allem auf der KI-Einkaufsliste.

Was ich prüfen würde, bevor ich irgendetwas unterschreibe

Die Demo zeigt einem die Agenten-Ansicht. Das hier sind die Dinge, die sie nicht zeigt, und sie gelten unabhängig davon, ob man seinen ersten Desk kauft oder zu einer der Zendesk-Alternativen wechselt.

1. Kann ich mit dem Plan, den ich kaufe, den Report bauen, den ich brauche? Frag nach dem genauen Plan, nicht nach dem Feature-Namen. Speichere einen Screenshot der Antwort.
2. Was schließt ein Ticket, und nach wie langer Zeit? Bestätige das Auto-Close-Fenster und ob eine Kundenantwort das Ticket wieder öffnet oder ein neues erzeugt.
3. Wie viele Status kann ich haben, und wie viele werden angezeigt? Zendesk erlaubt bis zu 100 Status, aber der Picker zeigt nur die ersten 10 aktiven an.
4. Was passiert mit einem Dropdown-Wert, den ich stilllege? Wenn die Antwort "das Feld wird null" lautet, plane deine Taxonomie jetzt schon.
5. Was ist die KI-Einheit, schriftlich festgehalten? Lösung, Session, engagierte Konversation oder Interaktion. Frag dann, was als abgebrochener Chat zählt.
6. Was macht die KI, wenn sie es nicht weiß? Kein Konfidenz-Schwellenwert bedeutet kein Deal.
7. Wo liegen meine Daten, und kann ich sie verschieben? Zendesks Region-Add-on ist ab Suite Professional kostenlos, aber "enthalten, aber nicht automatisch aktiviert", und Freshdesk lässt einen die Region nur bei der Anmeldung wählen.
8. Bekomme ich meine Historie heraus? Exporte funktionieren meist problemlos. Benutzerdefinierte Felder kommen unbeschriftet heraus, was später zu einem echten Problem wird.

Der letzte Punkt hat Kosten, die man wirklich erst beim Ausstieg zu spüren bekommt:

"I have exported my historical tickets to XML but not going to work. First my tickets are a mess. They are not properly organized, tagged, or anything. Lot of the info chatGPT would need to understand is in custom fields which are not labeled in any export."

u/ToastyPasta, Reddit

Und noch eine ehrliche Anmerkung zum Umfang, denn der Einwand ist berechtigt. Ein CX-Lead bei einer Nahrungsergänzungsmittel-Marke mit rund 7.000 Tickets im Monat sagte uns unverblümt: "Ich brauche eine KI, die nur die Tickets bearbeitet, bei denen sie sich sicher ist, und bei allen anderen die Finger lässt." Wenn ein Anbieter nicht beschreiben kann, wie sein System entscheidet, wo es die Finger lässt, ist das genau die Antwort auf Frage sechs.

eesel auf dem Support-Ticket-System testen, das du schon nutzt

Die meisten Teams, die das hier lesen, brauchen eigentlich keinen neuen Desk. Sie brauchen, dass der Desk, den sie schon haben, aufhört, Tier-1-Tickets zu verlieren, und genau das ist die Aufgabe von eesel – als KI-Ticketing-System, das auf den bereits genutzten Desk aufgesetzt wird.

eesel klinkt sich über deren APIs in Zendesk, Freshdesk, Gorgias, Help Scout und den Rest ein, lernt aus deinen vergangenen Tickets und deinem Help Center und übernimmt die repetitive Bandbreite eigenständig, während alles andere bei deinen Agenten bleibt.

Zwei Dinge unterscheiden es von der KI, die vielleicht schon in deinem Plan steckt. Man kann das Ganze gegen die eigene Ticket-Historie simulieren, bevor ein einziger Kunde es je sieht. Und die Preise liegen bei 0,40 $ pro bearbeitetem Ticket, ohne Sitzplatzgebühr, ohne Mindestmenge, sodass ein Teil-Rollout auch nur einen Teilbetrag kostet.

Das ist auch der Grund, warum ich der oben genannten Setup-Reihenfolge vertraue. Als wir für einen deutschen Schmuckhändler auf Zendesk und Shopify einen Test mit echtem Traffic gefahren haben, bei rund 1.000 Tickets im Monat, kam die Triage-Genauigkeit auf 93% und die Spam-Erkennung auf 100%, während nur 12% der Entwürfe so verschickt wurden, wie sie waren. Die Triage war bereit, das Verfassen von Entwürfen noch nicht, und die Simulation war es, die uns gesagt hat, was was war, bevor ein Kunde es herausgefunden hat. Du kannst kostenlos starten und es in ein paar Minuten auf deine eigene Queue ansetzen.