
Was ein Service-Desk-Ticketsystem eigentlich ist
Ich entwickle die Integrationen bei eesel. Das heißt, meine Tage bestehen darin, die APIs dieser Produkte zu lesen statt ihrer Landingpages, und genau da ist die Lücke zwischen beidem am größten. Jede Anbieter-Homepage sagt mehr oder weniger denselben Satz über die Optimierung des IT-Supports. Was du tatsächlich kaufst, verrät dir das Datenmodell darunter.
Fangen wir mit der Unterscheidung an, die zählt. Ein Help Desk repariert, was kaputt ist. Ein Service Desk liefert zusätzlich, was Menschen angefordert haben. Diese zweite Hälfte ist der gesamte Grund, warum die Kategorie existiert, und die Arbeit ist strukturell anders: Du brauchst eine veröffentlichte Liste bestellbarer Dinge, dann eine Möglichkeit, jedes davon hinter der richtigen Person zu sperren, plus eine Möglichkeit, die entstehende Arbeit auf Teams zu verteilen, die keine gemeinsame Warteschlange teilen.

Atlassian gibt erfrischend offen zu, dass die Namensgebung ein Durcheinander ist. Man zitiert HDI-Forschung, die feststellt, dass 41 % der Desks "anders genannt werden", und fügt hinzu, es gebe "keine Garantie, dass die in dieser HDI-Umfrage gemeldeten Service Desks und Help Desks unseren Beschreibungen entsprechen". Kauf also nicht nach dem Wort auf der Verpackung. Kauf danach, ob das Tool eine Anfrage als vollwertiges Objekt modelliert, mit Katalogeintrag, Genehmiger und untergeordneter Arbeit, oder nur als E-Mail mit einem Statusfeld. Die längere Version dieses Arguments habe ich separat in Help Desk vs. Service Desk aufgeschrieben.
Eine Anfrage, drei Datensatznummern
Der sauberste Weg, den Unterschied zu sehen, ist zu beobachten, was mit einem einzigen Satz passiert.
"Mein Laptop startet nicht" ist eine Störung. Ein Datensatz, ein Zuständiger, eine Lösung. "Ich brauche einen neuen Laptop" ist eine Anfrage, und innerhalb von ServiceNow werden daraus drei Datensätze mit drei verschiedenen Nummernserien. Es gibt eine Request (sc_request, Präfix REQ), den Container auf Warenkorbebene für einen Checkout. Es gibt ein Requested Item (sc_req_item, Präfix RITM), eines pro bestelltem Katalogartikel. Dann die Catalog Tasks (sc_task, Präfix SCTASK), die eigentliche Erfüllungsarbeit, die der Flow des Artikels erzeugt. ServiceNows eigene Service-Catalog-API-Referenz zeigt eine Checkout-Antwort mit "number": "REQ0010012" und "table": "sc_request", das ist also kein Gerücht.
Bestellst du einen Laptop und einen Monitor in einem Checkout, bekommst du eine REQ mit zwei RITM. Jedes RITM kann mehrere SCTASK erzeugen, da Beschaffung, Imaging und Versand die Aufgaben dreier verschiedener Personen sind. Eine Eigenheit, die man vor dem Bau von Reports kennen sollte: die Katalogantworten leben nur im RITM. ServiceNow erklärt, dass "Variablen nur mit der Tabelle des Requested Item [sc_req_item] verknüpft sind", weshalb ein Techniker, der das SCTASK bearbeitet, oft nicht sehen kann, was die Person eigentlich wollte, sofern es nicht jemand absichtlich sichtbar gemacht hat.
Eine Nachricht rein. Wie viele Datensätze raus?
Derselbe Satz, von derselben Person eingegeben, wird zu völlig unterschiedlichen Mengen an Arbeit, je nachdem, unter welchem Datensatztyp dein Service-Desk-Ticketsystem ihn ablegt. Wähl eine Anfrage und sieh dir die Kette an, die tatsächlich entsteht.
Das ist die Hälfte, die ein einfacher Help Desk schon gut beherrscht. Etwas ist kaputt, eine Person repariert es, das Ticket schließt. Wenn deine Warteschlange größtenteils daraus besteht, brauchst du noch kein Service-Desk-Ticketsystem.
Gleiche Person, gleiches Postfach, mehr als doppelt so hohe Kosten. Der Katalog, die Genehmigung und die Erfüllungsaufgaben sind der gesamte Grund, warum ein Service-Desk-Ticketsystem existiert, und auch der Grund für seine Preisgestaltung.
Zugriffsanfragen sind es, die Menschen den Service Desk hassen lassen, und fast nichts davon ist die Schuld des Desks. Das Ticket bleibt liegen, während es auf zwei Personen wartet, die in Meetings sind. Das zu beheben ist ein Routing- und Erinnerungsproblem, kein Ticketing-Problem.
Onboarding ist der ehrliche Stresstest für jedes Service-Desk-Ticketsystem. Wenn ein Tool eine Anfrage nicht in parallele Aufgaben über vier Teams verteilen und dir sagen kann, welche am Freitag davor noch offen ist, dann ist es ein Help Desk mit aufgeklebtem ITIL-Vokabular.
Arbeitszeit- und Kostenwerte sind MetricNet-/HDI-Benchmarks für Desktop-Support, veröffentlicht 2011 (Daten von 2010). Behandle das Verhältnis zwischen Störungen und Serviceanfragen als das dauerhafte Signal, nicht die Dollarbeträge. Datensatzketten spiegeln ServiceNows Anfragemodell wider; andere Anbieter legen für dieselbe Arbeit weniger Nummern an.
Der Grund, sich um Datensatzzahlen zu kümmern, ist keine Ordentlichkeit. Es liegt daran, dass laut MetricNets Benchmarks zu Tickets pro Techniker die Anfragehälfte deiner Warteschlange etwa drei- bis fünfmal so viel Arbeit ist wie die Störungshälfte, und die Kosten pro Ticket daraus folgen: 113 $ pro Serviceanfrage gegenüber 48 $ pro Störung im Desktop-Support. Datiere diese Dollarbeträge auf 2011, und behandle das Verhältnis als die dauerhafte Zahl, nicht den Betrag.

Der Katalog ist der Ort, an dem sich Anbieter still uneins sind
Jeder Anbieter verkauft dir "einen Servicekatalog". Fast keiner meint damit dasselbe, und die Unterschiede sind groß genug, um zu ändern, welches Tool du kaufst.
Jira Service Management hat überhaupt kein Katalogprodukt. Atlassian sagt das direkt: Die ITSM-Vorlage "kommt mit einem Servicekatalog häufiger Anfragen. Diese heißen Anfragetypen", und du siehst deinen Katalog, indem du zu den Bereichseinstellungen gehst, dann zu Anfragenverwaltung, dann Anfragetypen. Es gibt keinen separaten Builder. Die alte Dokumentations-URL set-up-a-service-catalog liefert einen 404, weil so etwas nicht existiert. Das ist nicht automatisch schlecht, und es bedeutet auch, dass keine Plansperre auf dem Katalog liegt, aber wenn du mit der Erwartung eines Shopping-Erlebnisses mit Kategorien und Preisen kommst, wirst du überrascht sein. Ein Administrator berichtete, ihm sei in einem Atlassian-Schulungsanruf gesagt worden, die Liste solle klein bleiben:
"The answer that I got was like, 'You shouldn't have more than 8-10 requests in your help center so if they need unique workflows then it shouldn't be a problem.'"
Acht bis zehn Artikel sind der Umfang eines Help Desks. Ein Enterprise-Katalog ist das nicht. Ob das als Empfehlung oder als strukturelle Obergrenze zählt, hängt davon ab, wen man fragt, aber es zeigt trotzdem, wo der Schwerpunkt des Produkts liegt.

Freshservice legt den Katalog hinter seine zweite Stufe. Ein Starter-Account für 19 $ pro Agent bekommt Störungen, Knowledge, Aufgaben und ein Portal, aber keinen Katalog und keine Serviceartikel, also auch keine Serviceanfragen, die aus einem Katalogformular ausgelöst werden. Der Katalog beginnt bei Growth, 49 $, was einen 158-%-Sprung gegenüber dem Einstiegspreis für genau die eine Funktion bedeutet, die es zu einem Service Desk macht. SLA-Management kreuzt auf derselben Linie, und das summiert sich, weil untergeordnete Anfragen gegen "die entsprechenden SLAs" durchgesetzt werden.
ManageEngine berechnet ihn separat. ServiceDesk Plus listet 13 $ pro Techniker bei Standard, 27 $ bei Professional, und verkauft den Servicekatalog dann als Add-on: 1.595 $ im Jahr in der Cloud-Add-on-Tabelle, oder 1.195 $ in der jährlichen. Nur bei Enterprise für 67 $ ist er gebündelt. Die CMDB kostet weitere 1.595 $ im Jahr, nur bei Professional.
SolarWinds bündelt ihn ganz unten. Sein Service Catalog und Advanced Approval Workflows sind beide sowohl bei Essentials, bei Advanced als auch bei Premier als "Included" gelistet, was den 39-$-Essentials-Plan zur günstigsten echten Kombination aus Katalog und Genehmigungen auf dieser Liste macht. Zwei genehmigungsnahe Punkte bleiben gesperrt: Service Portal Tasks and Approvals sowie der Portal Designer. Beide brauchen Advanced.
ServiceNow bündelt ihn und berechnet dich anderswo. Service Catalog und Request Management liegen innerhalb von ITSM Foundation, der Basisstufe, zusammen mit Incident Management und Asset Management. Die Preisseite enthält null Dollarbeträge und nur einen "Get Custom Quote"-Button, sodass der Katalog ohne Plansperre nur ein schwacher Trost ist.
Halo bündelt buchstäblich alles. Ein einziger Plan, 69 £ pro Agent im Monat, jährlich abgerechnet, und Genehmigungsworkflows, CMDB, Projektmanagement und KI stecken alle im Grundpreis, mit der expliziten Zeile "keine Stufen, keine Add-ons, keine weggesperrten Funktionen". Der Haken sitzt in der Fußnote. Onboarding-Pakete sind beim Kauf zu einem individuellen Preis verpflichtend, und der US-Dollar-Betrag wird clientseitig eingefügt, sodass tatsächlich nur der GBP-Preis gerendert wird.
Genehmigungen, der Schritt, der sowohl deine verstrichene Zeit als auch deine Rechnung entscheidet
Hier meine ehrliche Einschätzung, nach dem Bauen gegen die meisten dieser APIs: Genehmigungen sind das am wenigsten erforschte Element beim Kauf eines Service Desks, und dort stecken sowohl die Verzögerung als auch die Überraschungsrechnung.
Jeder Anbieter modelliert sie völlig anders. In Jira Service Management existiert eine Genehmigung als Eigenschaft des Workflow-Status, nicht als Formulareinstellung. Atlassians Dokumentation zu Workflow-Genehmigungen ist unverblümt, dass die Checkbox "Genehmigungsschritt einschließen" nur verfügbar ist, wenn der Status bereits mindestens zwei Übergänge trägt, einen für Genehmigen und einen für Ablehnen. Mehrstufige Genehmigung ist also eigentlich keine Builder-Funktion. Es bist du, der mehrere genehmigungstragende Status von Hand verkettet. Das Quorum ist konfigurierbar, wobei eine Ablehnung absolut bleibt: Lehnt irgendein Genehmiger ab, wird das Arbeitselement abgelehnt, egal welche Zahl du eingestellt hast.
Freshservice hat sein altes sequenzielles Modell durch Genehmigungsgruppen und -ketten ersetzt: vier Gruppenregeln und vier Kettenregeln, wobei Gruppen innerhalb einer Kette parallel laufen, aber nur eine Kette gleichzeitig aktiv ist. Noch beim Legacy-Modell? Merk dir das Datum. Freshservice sagt, die letzte Verlängerung für die Abschaffung der Legacy-Genehmigungen sei August 2026, "danach werden keine weiteren Verlängerungen gewährt". Diese Migration hat auch einen unangenehmen API-Nachlauf. Der alte Single-Approver-Endpunkt akzeptiert jeweils einen Genehmiger, und nach der Migration erzeugt jeder Aufruf seine eigene Gruppe, wobei die Kettenregel standardmäßig auf "Alle Gruppen müssen genehmigen" steht, was Genehmigungen, die früher bei "irgendjemand" durchgingen, still ins Stocken bringt.
Nun der kommerzielle Teil, den ich jedem vorlegen würde, der den Vertrag unterschreibt.
Bei Jira Service Management sind Genehmiger kostenlos. Atlassian sagt es unverblümt: "Genehmiger brauchen keine Jira-Service-Management-Lizenz", sie müssen nur Kunden des Service-Bereichs sein.
Bei ServiceNow ist das nicht so. Reine Genehmiger fallen stattdessen in eine separat gezählte Business-Stakeholder-Klasse. Ein ServiceNow-Mitarbeiter erklärt in seinem eigenen Lizenzierungsleitfaden, wie es funktioniert:
"Business Stakeholder (BSH): This one catches people off guard because it is measured across two separate tables - one for role assignment and one for approval activity. A user qualifies as a BSH if they hold an Approver role but hold no Fulfiller role. The moment a BSH user gains a Fulfiller-mapped role, they move out of BSH measurement entirely."
Wenn deine Genehmigungsketten an sechzig Manager weitergeleitet werden, die sonst nie ein Ticket anfassen, ist genau dieser Satz dein Budget. Und die Ersparnis durch kostenlose Anfragende verschwindet komplett, sobald du das gute Mitarbeiterportal hinzufügst, da Produkte wie Employee Center Pro und HRSD nach dem Unrestricted-User-Modell abrechnen, bei dem jeder aktive Nutzer der Instanz zählt.
Praktiker stoßen genau in dem Moment darauf, in dem sie ihren ersten Katalogartikel bauen. Im Dezember 2025 stellte ein Administrator die naheliegende Frage:
"I know I need the itil role for approvers to approve the requests, but, is that it? Isn't there like a 'lower' role that I can assign them that is enough for them to view the answers of the item and approve/reject the catalog task instead of assigning them the itil role?"
Der alte Workaround war die Genehmigung per E-Mail, die die Rolle komplett umging. Eine Antwort in diesem Thread berichtet, dass sich diese Tür schließt: "Email approvals require the business stakeholder license to be assigned. This has come up for a ton of my clients recently." Du kannst also keine ServiceNow-Genehmigungskette entwerfen, ohne zuerst jeden Menschen darin zu bepreisen.
Erfüllung, und die Checkbox, die eine Anfrage in zehn verwandelt
Sobald die Genehmigung durch ist, muss das Tool diese Arbeit verteilen. Das ist die Schicht, die Käufer am wenigsten bewerten und mit der sie danach am meisten leben.
Freshservices Mechanismus ist eine einzige Checkbox am Katalogartikel: "Create Child Requests for each of the items above." Lässt du sie deaktiviert, liegt jede Position in einem einzigen Ticket, das einem Agenten zugewiesen ist, der dann jede Position von Hand auf Delivered oder Cancelled setzt. Aktivierst du sie, wird jede Position ein einzelnes Kind-Ticket mit System als Anfragendem, weitergeleitet an die zuständige Abteilung, jedes mit eigener SLA-Uhr. Freshservices eigenes Beispiel ist ein Elternobjekt New Employee Hire, das New CRM Account, Apple MacBook und Adobe Photoshop CS6 als Kinder erzeugt.
Diese Checkbox ist für mich die schärfste einzelne Illustration dieser gesamten Kategorie. Ein Schalter, und das ist der Unterschied zwischen einem Shared Inbox und einem Service Desk.

Zwei Dinge daran werden dich in der Produktion beißen, und beide stehen in Freshservices eigener Dokumentation. Das Schließen eines Elterntickets schließt automatisch jedes verknüpfte Kind, mit der Warnung, "sicherzustellen, dass alle untergeordneten Serviceanfragen erfüllt wurden, bevor das übergeordnete Ticket geschlossen wird". Dann gibt es eine feste Obergrenze von 100 Aufgaben unter einer übergeordneten Entität, was großzügig klingt, bis eine Massen-Onboarding-Welle trifft.
ServiceNows Gegenstück ist die Aktion Create Catalog Task innerhalb des Item-Flows, die pro Arbeitsschritt einen sc_task-Datensatz prägt. Jira Service Management trägt bemerkenswerterweise überhaupt keine native Verteilung dieser Art. Du bekommst ein Arbeitselement pro Anfragetyp, und die teamübergreifende Erfüllung ist etwas, das du selbst baust, mit Automatisierung oder untergeordneten Issues.
Assets sind der zweite Zähler, den niemand einplant
Wenn ein Service-Desk-Ticketsystem verfolgt, was es ausgibt, dann braucht es eine CMDB, und diese CMDB kommt mit ihrer eigenen Preisliste.
- Freshservice zählt die Geräte nicht. Stattdessen berechnet es Asset Units, eine eigene Lizenzmetrik, die man in Paketen zu 500 kauft. Weder der Paketpreis noch die planweise enthaltene Menge werden irgendwo auf dieser Preisseite veröffentlicht.
- SolarWinds schafft es, gleichzeitig am explizitesten und am stärksten hinter einer Angebotssperre zu sein. IT-Asset-Management ist "als Zusatzkauf verfügbar", mit "Asset-Preise auf Anfrage" auf jeder Plankarte, und die Zählregel ist breit: Jedes Gerät mit der Fähigkeit, auf ein Netzwerk zuzugreifen, zählt zum Asset-Limit, "auch wenn die IP-Adresse nicht aktiv verfolgt wird".
- Jira Service Management veröffentlicht Objektkontingente statt eines Preises: 5.000 bei Standard, 50.000 bei Premium und 500.000 bei Enterprise, dazu eine site-weite Obergrenze von 10 Millionen darüber. Überschreitest du das Limit, schlagen Importe fehl. Assets gibt es zudem nur in unternehmensverwalteten Bereichen, sodass es in einem teamverwalteten Bereich keine CMDB gibt.
- ManageEngine berechnet verwaltete IT-Assets als eine unkomplizierte zweite Dimension neben Technikern, und die Preisseite sagt genau das: "Wenn du IT-Asset-Management nutzt, zahlst du nach der Anzahl der verwalteten IT-Assets."
- Halo und ServiceNow haben beide die CMDB im Grundangebot enthalten, für einen Sitzplatz zu 69 £ beziehungsweise ein unveröffentlichtes Angebot.

Was ein Service-Desk-Ticketsystem 2026 kostet
Hier ist der Vergleich, den ich mir gewünscht hätte, als ich anfing, diese Preisseiten zu lesen. Jede Zahl ist ein Listenpreis von der eigenen Seite des Anbieters, geprüft am 31. Juli 2026.
| Tool | Einstiegs-Listenpreis | Lizenzierte Einheit | Anfragende | Wo der Katalog lebt | Genehmiger lizenziert? | Assets / CMDB | KI-Zähler |
|---|---|---|---|---|---|---|---|
| ManageEngine ServiceDesk Plus | 13 $/Techniker/Monat (kostenlos ≤5 Techniker) | Techniker | Kostenlos, unbegrenzt | 1.595 $/Jahr Add-on bei Standard und Pro; gebündelt bei Enterprise | Nicht separat gezählt | CMDB 1.595 $/Jahr, nur Pro; Assets ein zweiter Zähler | Zia enthalten, kein veröffentlichter Zähler |
| Freshservice | 19 $/Agent/Monat Starter | Agent | Kostenlos | Growth, 49 $/Agent/Monat | Nicht separat gezählt | Asset Units, Pakete zu 500, Preis unveröffentlicht | 1.200 Freddy-Sitzungen pro Enterprise-Lizenz im Jahr; Überschreitung unveröffentlicht |
| Jira Service Management | 25 $/Agent/Monat (1–15 Agenten) | Agent | Kostenlos, unbegrenzt | Kein Katalogprodukt; es ist die Liste der Anfragetypen | Nein, Genehmiger sind kostenlos | 5.000 / 50.000 / 500.000 Objekte je nach Plan | Virtueller Service-Agent ab 0,30 $/unterstütztem Gespräch; Rovo Customer Service 1 $/Lösung |
| Zendesk Employee Service | 29 $/Agent/Monat Team | Agent | Kostenlos | Growth, 59 $/Agent/Monat | Nicht separat gezählt | ITAM ab Growth | Nur verifizierte Lösungen; Tarif unveröffentlicht |
| SolarWinds Service Desk | 39 $/Techniker/Monat, nur jährlich | Techniker | Kostenlos, unbegrenzt | Essentials, der Basisplan | Nicht separat gezählt | ITAM separater Kauf, Preis auf Anfrage | Keine veröffentlicht |
| HaloITSM | 69 £/Agent/Monat, jährlich | Agent, namentlich oder gleichzeitig | Kostenlos | Enthalten, keine Stufen | Nicht separat gezählt | Enthalten | Enthalten, kein veröffentlichter Tarif |
| ServiceNow ITSM | Kein veröffentlichter Preis | Fulfiller | Nur bei ITSM kostenlos | ITSM Foundation, die Basisstufe | Ja, Business-Stakeholder-Klasse | In Foundation enthalten | Assists-Tarifkarte, gepoolt auf Kontoebene |
| eesel | 0,40 $ pro bearbeitetem Ticket | Keine, keine Sitzplätze | n/a | Setzt sich auf deinen bestehenden Desk | n/a | n/a | Das Ticket ist die Einheit |
Zwei Lesarten dieser Tabelle sind es wert, ausgesprochen zu werden.
Erstens: Der günstigste Sitzplatz und der günstigste Katalog sind selten dasselbe Produkt. ManageEngine gewinnt beim Sitzplatzpreis, verlangt dann aber 1.595 $ im Jahr für das, was es zu einem Service Desk macht. Freshservices tatsächlicher Einstiegspunkt für einen Katalog liegt bei 49 $, nicht bei 19 $. Zendesk spielt denselben Zug bei 29 $ und 59 $. SolarWinds wirkt bei 39 $ teuer, bis man bemerkt, dass Katalog und Genehmigungs-Engine beide schon enthalten sind.
Zweitens hört der Sitzplatzpreis auf, deine Rechnung vorherzusagen, sobald du KI oder Assets aktivierst. Vier Zähler, nicht einer, und nur der erste steht in großer Schrift auf der Preisseite.
Die KI-Schicht hat ihren eigenen Zähler, und die Einheit schlägt die Rate
Jeder dieser Anbieter verkauft inzwischen KI für den Service Desk, und jeder zählt sie anders. Die Einheit ist wichtiger als die Zahl.
ServiceNow veröffentlichte seine Assists-Tarifkarte am 23. Juli 2026 als öffentliches rechtsverbindliches PDF, was es gerade zur transparentesten der großen Plattformen macht. Die für ITSM relevanten Zeilen: eine Störungszusammenfassung ist 1 Assist, eine Genehmigungsempfehlung ist 1, das Vorausfüllen eines Katalogformulars ist 1, ein Virtual-Agent-Thema, das durchgängig ausgeführt wird, ist 10, mehrstufige Katalogbestellung ist 10, und ein agentischer Workflow ist 25, 50 oder 150, je nachdem, wie viele Tools er berührt. Assists werden auf Kontoebene über Produktion und Sub-Produktion gepoolt. Ein Workflow endet bei Abschluss, bei 20 Aktionen oder nach einer Stunde Inaktivität, was bedeutet, dass Aktion 21 einen zweiten abrechenbaren Workflow startet.

Auf diesem Screen bemerkenswert: Der L1 Service Desk AI Specialist, der tatsächlich das Tier-1-Volumen löst, ist nur bei Prime verfügbar. Foundation und Advanced bekommen die assistive KI.
Freshservice zählt Sessions, definiert als jede Interaktion, die ein eindeutiger Nutzer innerhalb eines 24-Stunden-Fensters mit dem KI-Agenten hat, sodass der Versuch berechnet wird, nicht das Ergebnis. Jede Enterprise-Lizenz enthält 1.200 Sessions pro Jahr, hundert im Monat, und der Überschreitungstarif ist nirgendwo veröffentlicht. Freddy AI Copilot kostet bei Pro und bei Enterprise separat 29 $ pro Agent im Monat, was einen Pro-Sitzplatz auf bis zu 128 $ treibt.
Jira Service Management fährt drei Zähler gleichzeitig. Es gibt mit dem Sitzplatz gebündelte Rovo-Credits, dazu den virtuellen Service-Agenten ab 0,30 $ pro unterstütztem Gespräch über 1.000 im Monat, plus Rovo Customer Service für 1 $ pro Lösung. Die Falle liegt in der Definition von "unterstützt": Atlassian zählt jedes Gespräch, das einer Absicht zugeordnet wurde, egal ob der Agent es löst oder eskaliert, sodass ein eskaliertes Ticket trotzdem berechnet wird.
Das ist die Kauffrage in einer Zeile. Ein Lösungs-Zähler berechnet dich, wenn es funktioniert hat. Ein Session- oder Gesprächszähler berechnet dich, wenn es versucht hat.
Was die Benchmarks ehrlich über Deflection sagen
Bevor du etwas auf Basis einer Deflection-Zahl kaufst, kalibriere gegen die Forschung statt gegen das Pitch-Deck.
MetricNets Benchmarking-Datenbank setzt die durchschnittliche Self-Service-Abschlussrate für Service Desks weltweit bei 10,4 %, mit einer Spanne von null, bei Desks ohne Self-Service, bis zu einem Höchstwert von 55 %. Der frühere Durchgang fand 8,9 % und stellte fest, dass "die überwiegende Mehrheit dieser selbst gelösten Störungen Passwort-Zurücksetzungen sind". Die Netto-First-Level-Lösungsrate liegt im Schnitt bei 74,3 %, während nur 1,4 % der Service Desks über 95 % kommen.
In derselben Forschung gibt es einen Effekt zweiter Ordnung, den fast niemand erwähnt und jeder spürt: Während die einfachen Tickets weggeleitet werden, "werden die durchschnittliche Komplexität und die durchschnittliche Bearbeitungszeit der Störungen, die weiterhin von Live-Agenten bearbeitet werden, zunehmen". Deflection verkleinert nicht nur die Warteschlange. Sie konzentriert sie. Plane deine Personalausstattung also um den schwierigeren Mix herum, der übrig bleibt.
Die Eskalationsleiter ist der Grund, warum das alles finanziell wichtig ist. MetricNet bepreist Level-1-Support mit 22 $ pro Ticket, Desktop-Support mit 62 $, Level 3 mit 85 $, Field-Support mit 196 $ und Vendor-Support mit 471 $, und diese Leiter ist kumulativ: Ein auf Level 1 erfasstes und dann auf Level 2 eskaliertes Ticket kostet 62 $ plus 22 $, nicht nur 62 $. Datiere diese Beträge auf 2011 und lies die Schlussfolgerung als dauerhaft: "Die Maximierung der FLR entspricht der Minimierung der TCO."
Was die Leute, die diese Desks betreiben, wirklich sagen
Anbieterseiten werden dir nichts davon erzählen, also hier eine Praktiker-Lektüre der letzten zwölf Monate.
Zur Frage, ob ein Katalog funktioniert: Der schärfste Test, den ich gefunden habe, ist überhaupt keine Funktion. Es ist eine Zahl, die niemand meldet:
"Every incident/request should narrow down to an obvious CSI that an idiot in a hurry could categorise, consistently and repeatedly. If everyone is just hitting other, other, other then it's failed. Capital F."
Prüf nach, welcher Prozentsatz deiner Anfragen in einem generischen Sammelbecken landet. Ist er hoch, helfen mehr Katalogartikel nicht, und ebenso wenig hilft KI-Routing auf einer Taxonomie, in der sich niemand zurechtfindet.
Bei der Lizenzierung ist das teuerste Missverständnis dieser Kategorie, wer als Agent zählt. Ein Atlassian-Käufer stellte seine eigenen Zahlen neben die seines Cloud-Ingenieurs:
"What I think I need (for starters): $ 8500 / year
What the cloud engineer thinks I need (for starters): $ 40,750 / year
JSM Standard - 10 agents - annual cost $2000Confluence Standard - 10 users - annual cost $ 500Atlassian access - 200 users - $6.000 (this one hurts)JSM Standard - 200 agents - annual cost $25,750Confluence Standard - 200 users - annual cost $ 9000Atlassian access - 200 users - $6.000" -- u/LooselySubtle, r/atlassian, Reddit
Das ist eine 4,8-fache Schwankung, die allein davon abhängt, ob 200 Mitarbeitende Agenten oder Anfragende sind. Klär diese Frage zuerst schriftlich, bevor du irgendwelche zwei Tools vergleichst.
Und zur KI: Der nützlichste Thread, den ich dieses Jahr gelesen habe, war der eines ServiceNow-Produktdesigners, der seine eigene Community um Now-Assist-Erfolgsgeschichten als Referenzen bat. Die Antworten waren nicht das, was er sich erhofft hatte:
"These features all seem like things that make for a cool demo but don't actually save a company much time or money. Most of our closed incidents never get looked at again, and when they need to be looked at it's not particularly hard to read the history."
Eine weitere Antwort in demselben Thread ging direkt gegen den Genauigkeitsanspruch vor:
"There is a persistent belief in the big tech bubble that it can, but it simply isn't good enough. It's auto prediction on steroids. Traditional automation is far more effective than chained ai agents that are only 50% accurate."
Ich verkaufe KI für Support-Warteschlangen, und ich finde, diese Antwort ist im Grunde fair. Zusammenfassung und Entwürfe sind die Funktionen, die in Demos am besten aussehen und am wenigsten verändern. Was die Zahlen eines Service Desks tatsächlich bewegt, ist das Unspektakuläre: die Wiederholungsfrage korrekt zu beantworten, bevor ein Mensch sie öffnet. Alles andere ist Dekoration auf einer Warteschlange, die gleich groß bleibt.
Was ich vor der Unterschrift tatsächlich prüfen würde
Nach über drei Jahren, in denen ich KI-Agenten in echte Support- und IT-Warteschlangen gesetzt habe, sehen die Fragen, die ich einem Anbieter stellen würde, überhaupt nicht wie eine Feature-Matrix aus.
- Stell im Test eine Onboarding-Anfrage. Kein Passwort-Reset. Bestell einen Laptop, ein Konto und ein Telefon in einer Einreichung, genehmige sie als zwei verschiedene Personen und schau dann, wie viele Datensätze existieren und ob du auf einen Blick erkennst, welche Erfüllungsaufgabe noch offen ist.
- Zähl deine Genehmiger, dann frag, wie sie lizenziert sind. Bei den meisten Tools ist das kostenlos. Bei ServiceNow ist es eine gezählte Klasse, und bei ServiceNow bringt dich auch das gute Mitarbeiterportal auf Abrechnung pro aktivem Nutzer.
- Frag schriftlich, was der KI-Zähler zählt. Session, Gespräch, Assist oder Lösung. Frag dann nach dem Überschreitungstarif, denn Freshservice und Zendesk veröffentlichen beide das Kontingent, aber nicht den Tarif.
- Frag nach dem Asset-Preis. SolarWinds und Freshservice sperren ihn beide hinter ein Angebot. Das ist keine kleine Position.
- Prüf den Exportweg, bevor du gebunden bist. Freshservice hat überhaupt keinen UI-Export für den Katalog; der dokumentierte Workaround ist ein API-Aufruf. Fein, wenn du Ingenieure zur Hand hast. Übel, wenn nicht.
Und noch ein ehrlicher Vorbehalt zu meiner eigenen Kategorie. KI im Service Desk ist keine Magie, und ich habe die Narben, um es zu beweisen. Ich hatte zahlende Kunden, darunter einen dänischen Solarenergie-Anbieter, deren Bot Antworten erfunden und sie an echte Kunden geschickt hat, in Momenten, in denen die Knowledge Base keinen Treffer hatte. Genau deshalb wird jedes eesel-Rollout zuerst gegen historische Tickets simuliert, und deshalb würde ich keiner Deflection-Behauptung trauen, meiner eigenen eingeschlossen, die nicht an deiner eigenen Tickethistorie getestet wurde.
Der Einwand, der die meisten dieser Käufe entscheidet, ist Kontrolle, nicht Preis. Ein CX-Lead bei einer Nahrungsergänzungsmittel-Marke mit rund 7.000 Tickets im Monat hat es besser formuliert, als ich es könnte: Die KI wird nie alles beantworten, aber wenn sie bei allem anderen "sorry, ich weiß es nicht" antwortet, "kann ich nicht hingehen und alle meine 7.000 Tickets durchsehen, um zu prüfen, ob die KI wirklich eine gute Antwort gegeben hat, dann ist der Punkt ein bisschen dahin". Was sie wollten, war eine KI, die nur das bearbeitet, worin sie sich sicher ist, und den Rest in Ruhe lässt. Ich habe diesen Deal wegen vertrauensbasiertem Routing verloren, und es hat das Produkt besser gemacht.
Wie ich 2026 wählen würde
Wenn deine Warteschlange überwiegend aus Störungsbehebung besteht und du unter zehn Technikern hast, starte mit ManageEngines kostenloser Standard-Stufe oder Freshservice Starter, und überspring den Katalog komplett, bis die Anfragen die Störungen tatsächlich zahlenmäßig übertreffen. Einen Katalog zu kaufen, den man dann nicht befüllt, ist die häufigste Verschwendung in dieser Kategorie.
Wenn du einen echten Katalog plus Genehmigungen zum ehrlich günstigsten Preis brauchst, ist SolarWinds Essentials für 39 $ die Wahl, weil beides im Basisplan steckt, statt dir später verkauft zu werden.
Wenn du bereits Atlassian nutzt, lässt sich Jira Service Management in Bezug auf die Kostenstruktur schwer widerlegen: kostenlose, unbegrenzte Anfragende, kostenlose Genehmiger, 25 $ bei 1 bis 15 Agenten. Wisse nur, dass die Preisseite ihren Rechner standardmäßig auf 75 Agenten stellt, sodass die 20 $, die du siehst, ein Mischtarif und kein Listenpreis sind. Geh mit der Erwartung hinein, deinen Katalog als Anfragetypen und deine Verteilung als Automatisierung selbst zu bauen.
Wenn du ein großes Unternehmen mit echten Change- und CMDB-Pflichten bist, ist ServiceNow hier das vollständigste Modell, und niemand bestreitet ernsthaft, dass das Design von Incident, Change und CMDB falsch ist. Die Beschwerde betrifft Kosten, Klicks und Monate, nicht die Richtigkeit. Seine G2-Bewertung liegt bei 4,5 von 5 über 1.915 Bewertungen, mit 70 % Fünf-Sterne und null Ein-Stern, was nicht das Profil eines schlechten Produkts ist.
Und wenn du wirklich einen einzigen Preis ohne jede Sperre willst, ist Halo hier der einzige Anbieter, der sich dazu verpflichtet, vorausgesetzt du kannst mit einem individuellen Onboarding-Preis und einer nur in GBP veröffentlichten Zahl leben.
Stell eesel vor den Service Desk, den du schon betreibst
Nichts von alledem ist ein Grund, dein Ticketsystem herauszureißen, und ich würde das auch nicht vorschlagen. Was die Wirtschaftlichkeit eines Service Desks 2026 verändert, ist keine andere Warteschlange. Es ist das, was mit einer Anfrage passiert, bevor ein Techniker sie überhaupt öffnet.
Das ist es, was ich baue. eesel klinkt sich in den Desk ein, den du schon hast, lernt aus deinen vergangenen Tickets und aus deinen bestehenden Dokumenten in Confluence, Slack, Google Docs oder einer Knowledge Base und beantwortet dann die Wiederholungsanfragen als First Responder. Gleiche Art von Arbeit, egal ob die Warteschlange kundenorientiert oder interne IT ist.

Jason Loyola, Head of IT bei InDebted, betreibt es genau auf dieser Art von Desk:
"We use it to be the first responder to our Helpdesk tickets in Jira. It essentially acts just like an agent would."
Jason Loyola, Head of IT, InDebted
Sein Team liegt heute bei 15 % Deflection bei internen IT-Tickets und peilt 55 % an. Ich zitiere lieber die Zahl im Fortschritt als eine fertige, weil ein Service-Desk-Rollout eine Rampe ist und kein Schalter.
Zwei Dinge machen es für genau dieses Problem passend. Der Preis hat überhaupt keine Sitzplatz-Dimension: 0,40 $ pro bearbeitetem Ticket, keine Pro-Agent-Gebühr und kein Minimum, sodass das Hinzufügen von sechzig Genehmigern oder tausend Anfragenden nichts kostet. Und du kannst einen Ausschnitt statt der gesamten Warteschlange routen, das heißt, du richtest es auf die zwanzig wiederkehrenden Katalogfragen, die deine Tier-1-Zeit auffressen, und lässt die Change-Genehmigungen in Ruhe. Wenn du Jira Service Management nutzt, dauert das Verbinden ein paar Minuten und ist kostenlos zum Ausprobieren.
Häufig gestellte Fragen
Was ist ein Service-Desk-Ticketsystem?
Was kostet ein Service-Desk-Ticketsystem 2026?
Was ist der Unterschied zwischen einem Help Desk und einem Service-Desk-Ticketsystem?
Braucht ein Service-Desk-Ticketsystem KI, damit es sich lohnt?
Welches Service-Desk-Ticketsystem ist am besten für ein kleines IT-Team?
Wie funktionieren Genehmigungen in einem Service-Desk-Ticketsystem?
Kann KI das Ticketvolumen im Service Desk reduzieren?
Brauchen Mitarbeitende, die Tickets eröffnen, eine Lizenz?

Article by
Rama Adi Nugraha
Rama is a software engineer at eesel AI with two years of experience writing about B2B SaaS, AI tools, and customer support technology. Based in Bali, Indonesia, he brings a developer's perspective to product comparisons — cutting through marketing copy to what the integrations and APIs actually do.








