Das ServiceNow-Ticketsystem: Funktionsweise und Kosten

Was ein ServiceNow-Ticketsystem eigentlich ist

Beginnen wir ganz unten. Die Basis erklärt alles, was darüber liegt.

Jedes Ticket in ServiceNow lebt in einer Tabelle, die von einem einzigen übergeordneten Element erbt. Die eigene Dokumentation des Unternehmens ist da unmissverständlich: Die Task-Tabelle "ist eine Basisklasse, die Felder für die zentralen ITSM-Anwendungen wie Incident, Problem und Change Management bereitstellt. Alle Anwendungen, die die Task-Tabelle erweitern, teilen sich diese Felder gemeinsam."

Man kann nicht direkt in task schreiben. Versucht man es, stoppt einen ein Task Interceptor und zwingt dazu, zuerst eine Kindtabelle auszuwählen. Das Feld sys_class_name speichert dann, welches Kind man ausgewählt hat. Für immer.

Hier ist die gesamte Familie mit den exakten Tabellennamen, denn der Tabellenname entscheidet über das Verhalten:

Auch die Präfixe sind nicht fest codiert. Sie liegen als Zeilen in der sys_number-Tabelle unter System Definition, und jeder Administrator kann sie ändern, laut ServiceNows Dokumentation zur Datensatznummerierung. Wer von einem flachen Tool wie Zendesk kommt, spürt hier den ersten echten Unterschied: Der Datensatztyp ist eine Schema-Entscheidung, keine Dropdown-Auswahl in einem Formular.

Der Gewinn aus all dieser Vererbung ist real und verdient eine faire Würdigung, bevor ich anfange, Schwachstellen aufzuzeigen. Genehmigungen, Zuweisungsregeln, SLAs, Inaktivitätsmonitore und Flows laufen alle auf allem, was von task erbt, sodass man sie nur einmal bauen muss. Das ist genau der Teil, den ein kleineres Helpdesk-Tool nicht nachbilden kann, und es ist das, was eine Plattform von einem automatisierten Ticketsystem unterscheidet. Auch Rezensenten fällt das auf.

"Keeping requests, incidents, and changes connected is the core of this platform, which I really appreciate. Plus, finding related knowledge without leaving the ticket open. And lastly, bringing different IT tools together through integrations."

Louis B., G2

So sieht ein Datensatz aus, wenn man ihn geöffnet hat. Achte auf die Felder, die die Routingarbeit übernehmen, Assigned to und Assignment group, beide direkt von task geerbt:

Ein Request, drei Ticketnummern

Hier geht für fast alle der erste Tag schief.

Jemand fragt nach einem Laptop. In einem normalen Ticketsystem ist das ein Ticket, und in den meisten internen Ticketsystemen bleibt es bis zur Lieferung ein einziges Ticket. ServiceNow macht daraus drei Datensatztypen, weil Request Management die Anfrage, den Artikel und die Arbeit bewusst als getrennte Dinge modelliert:

1. REQ in sc_request, der Container auf Warenkorbebene. Ein Checkout ergibt ein REQ.
2. RITM in sc_req_item, eines pro Katalogartikel. Ein Laptop und ein Monitor im selben Checkout bedeuten ein REQ mit zwei RITMs.
3. SCTASK in sc_task, die eigentliche Erfüllungsarbeit, erzeugt durch den Flow des RITM. Beschaffen, imagen, dann versenden: drei SCTASKs aus einem einzigen RITM.

Eine Person, die eine Sache anfragt, kann also leicht fünf Datensätze über drei Nummernserien hinweg erzeugen, mit drei separaten Orten, an denen man den Status prüfen muss. Kein Bug. Das ist die absichtlich gebaute Trennung von Warenkorb, Artikel und Arbeit. Und es ist auch, zuverlässig, das, worüber neue Agenten stolpern:

"At times, especially as a beginner, it may be hard to navigate with all the various levels of a customer ticket--Interactions, Requests, RITMs, SCTasks etc. And then there's the occasional what seems like a bug."

Andrei F., Knowledge Specialist, Capterra

Die Katalogartikel, die den größten Teil dieses Volumens erzeugen, sind die unspektakulären. Zugriffsanfragen sind die mit Abstand größte Kategorie und lohnen sich am meisten für die Automatisierung. Ausrüstungs- und Geräteanfragen folgen dicht dahinter, und unser Leitfaden zu Hardware-Anfragen behandelt diese separat.

Eine Falle, die man kennen sollte, wenn man den Katalog aufbaut: Variablen existieren nur auf sc_req_item. ServiceNow sagt es unverblümt: "Variablen werden für erweiterte Tabellen nicht unterstützt." Alles, was der Nutzer in das Katalogformular eingegeben hat, liegt also auf dem RITM, und es zum SCTASK zu bringen, wo der Fulfiller es tatsächlich sehen kann, ist ein bewusster Konfigurationsschritt. Wenn deine Fulfiller ständig fragen "welche Monitorgröße wollten sie", liegt das genau daran.

Der Incident-Lebenszyklus, Status für Status

Incidents sind die einfachere Hälfte. Das Statusmodell ist vollständig veröffentlicht.

Richtig gelesen, es gibt kein 4 und kein 5. Das sind ausgebrannte Löcher, hinterlassen vom Modell aus der Zeit vor Helsinki, das drei separate Wartestatus hatte, wo es jetzt nur noch On Hold gibt. ServiceNows eigener Knowledge-Artikel KB0564465 veröffentlicht die Zuordnung und sagt genau, was dabei kaputtgeht: "Wenn du einen Workflow hattest, der bei Status 5 auslöste, musst du ihn so anpassen, dass er bei Status 3, Grund 2 auslöst."

Und jetzt der Teil, der mich in der Dokumentation am meisten überrascht hat. ServiceNow rät davon ab, das moderne Statusmodell auf aktualisierten Instanzen zu installieren. Das bedeutet, dass viele langjährige Produktivinstanzen unter einer modernen Oberfläche noch immer die alte fünfteilige Form nutzen. Jeder Report oder Workflow, der auf eine rohe Statusnummer geschrieben ist, hängt von der Version ab, also eine echte Frage, die man stellen sollte, bevor man die Instanz von jemand anderem übernimmt.

Drei Verhaltensweisen, die einen überraschen

Priorität ist keine Entscheidung des Agenten. Sie wird aus einem 3x3-Raster aus Impact und Urgency berechnet, und das Feld ist standardmäßig schreibgeschützt. ServiceNow sagt das direkt auf der Seite zu den Priority-Lookup-Regeln: "Einzelne Incident-Bearbeiter können die Priority-Lookup-Regeln nicht ändern." Ein P3, bei dem sich alle einig sind, dass es eigentlich ein P1 sein müsste, wird so zu einem Gespräch mit einem Administrator statt zu einer Dropdown-Auswahl.

Auto-Close ist ein geplanter Job, kein Timer am Datensatz. Daraus ergeben sich zwei Folgen. Erstens lügt der Audit-Trail, weil "der Name des Administrators, der eingeloggt ist, wenn der Autoclose-Incidents-Job läuft, in das Feld Updated by eingetragen wird." Zweitens "setzt ein Inaktivitätsmonitor diese Auto-Close-Uhr bei jeder Auslösung zurück", sodass eine Instanz, die beide Funktionen nutzt, still und leise Resolved-Incidents ansammelt, die nie geschlossen werden, ohne dass der Konflikt sichtbar wird. Die Lösung, laut ServiceNows Dokumentation, ist eine Reset Condition von [Incident state] [is not] [Resolved].

Das Schließen eines Elternteils schließt nicht dessen Kinder. Resolven schon. Closen nicht. Man setze hundert Kinder unter einen Eltern-Incident für einen Netzwerkausfall, und das Schließen des Elternteils lässt hundert Resolved-Datensätze zurück, die auf einzelne Anrufer warten, laut der Parent-Child-Sync-Tabelle. Diese Asymmetrie trägt häufig dazu bei, dass ein Ticket-Rückstand auf einem Dashboard schlimmer aussieht, als er tatsächlich ist.

Wie Tickets tatsächlich geroutet werden

Das Routing läuft über zwei geerbte Felder, assigned_to und assignment_group, weshalb es sich bei jedem Datensatztyp gleich verhält. Zuweisungsregeln setzen sie automatisch, sobald Bedingungen zutreffen.

Eine Regel über diese Regeln verdient ein Poster. Aus der Dokumentation zu Zuweisungsregeln: "Zuweisungsregeln können bestehende Zuweisungen nicht überschreiben (einschließlich Zuweisungen, die durch einen Standardwert oder eine zuvor ausgeführte Zuweisungsregel gesetzt wurden)." Ein hilfreicher Standardwert für assignment_group deaktiviert dann still und leise jede Routing-Regel, die man danach schreibt. Und wenn mehrere Regeln zutreffen, läuft nur die mit dem niedrigsten Order-Wert. Immer.

Es gibt auch eine Berechtigungsfalle, die beim ersten Mal wie ein Bug aussieht: Ein Nutzer mit der itil-Rolle kann einen Incident nicht einer Gruppe mit der Rolle admin oder security_admin zuweisen, auch keiner Gruppe, deren übergeordnete Gruppe diese Rollen trägt.

Für eine tiefere Behandlung dieser Ebene geht unser Leitfaden zum KI-Ticket-Routing weiter, als ich es hier kann, während der Begleitartikel zum Taggen von Tickets mit KI die Klassifizierungshälfte abdeckt. Der breitere Kategorieüberblick liegt in unserem Leitfaden zum automatisierten IT-Ticketing.

SLAs, und das Feld, das nichts tut

ServiceNows Service Level Management ist stark, und ein einzelner Task kann mehrere SLAs gleichzeitig tragen, jedes einzeln über einen eigenen task_sla-Datensatz verfolgt. Rezensenten bewerten das:

"The SLA tracking feature is another aspect I like, as it helps our team assess the performance of the person resolving issues."

vignesh m., admin, G2

Zwei Dinge sollte man kennen, bevor man seine Vereinbarungen gestaltet.

Erstens. Die Unterscheidung zwischen SLA, OLA und Underpinning Contract, der jeder ITIL-Kurs eine Stunde widmet, ist im Produkt selbst nur ein Label. ServiceNows Hinweis zum Feld Type besteht aus einem einzigen Satz: "Type wird ausschließlich für Reporting-Zwecke verwendet." Gleiche Engine, gleiche Bedingungen, identische Mathematik. Das Feld Target für Response gegenüber Resolution ist dieselbe Geschichte, es existiert "nur zum Filtern, Suchen und für Reporting-Zwecke."

Zweitens sind Tage keine Geschäftstage. Die Dokumentation legt die Falle offen dar: "Die in diesem Feld angegebene Anzahl von Tagen wird in 24-Stunden-Blöcke umgerechnet. Wenn das Feld Schedule einen Zeitplan mit Acht-Stunden-Tagen identifiziert, setzt eine Dauer von 1 Tag das SLA so, dass es drei Geschäftstage später verletzt wird." Vernünftiges Design. Auch eine sehr leichte Möglichkeit, ein SLA zu veröffentlichen, das ein Jahr lang danebengeht, bevor es jemand bemerkt.

Auch gut zu wissen: Auf einer modernen Instanz ist Breached überhaupt keine task_sla-Stufe. Die Stufen sind In progress, Cancelled, Paused und Completed. Breached überlebt nur "in Systemen, die entweder die SLA-Engine von 2010 verwenden oder im Kompatibilitätsmodus laufen", und trotzdem zeigt das visuelle Timer-Widget es weiterhin an, sodass die beiden Vokabulare nicht übereinstimmen. Baut man darauf SLA-Reporting auf, findet einen diese Diskrepanz garantiert.

Self-Service, und was der Virtual Agent wirklich abfängt

Self-Service ist der Ort, an dem die Geschichte des Ticketvolumens spielt, und dort, wo die Stufen anfangen, eine Rolle zu spielen.

Der vollständige Virtual Agent kann etwas. ServiceNow liefert vorgefertigte ITSM-Themen, die echte Arbeit erledigen. Check IT Ticket Status listet die aktiven Tickets eines Nutzers mit Stufe und letztem Update auf. Escalate IT Ticket erhöht die Dringlichkeit um eine Stufe, mit einer verpflichtenden Begründung. Es gibt auch Themen für Konferenzraumbuchungen und zugewiesene Ausrüstung. Deflection selbst ist eng definiert, als "wenn ein Nutzer eine Frage stellt oder eine Anfrage macht, die nicht zu einem Ticket oder menschlicher Hilfe führt."

Virtual Agent Lite, was Kunden niedrigerer Stufen erhalten, ist ein völlig anderes Tier. Zwei Themen sind enthalten, Check Ticket Status und Report an Issue. Überhaupt kein NLU, nur Keyword-Matching. Man kann keine Themen oder Kanäle hinzufügen. Und entscheidend: Es gibt kein Analytics-Dashboard, also keine unterstützte Möglichkeit zu messen, wie viel abgefangen wurde. Deflection bei Lite zu bewerten bedeutet, etwas zu bewerten, das man nicht messen kann – gut zu wissen, bevor man es mit einem Service-Desk-Chatbot vergleicht, der tatsächlich eine Lösungsrate ausweist. Teams, die an diese Wand stoßen, landen meist bei Virtual-Agent-Alternativen.

Eine weitere Einschränkung beißt im Produktivbetrieb. Die Übergabe an einen Menschen erfordert einen Menschen. "Beim Transfer aus dem Virtual Agent muss mindestens ein Live-Agent verfügbar sein, sonst erhält der Endnutzer eine no agents available-Nachricht, und sein Gespräch wird nicht übertragen." Für diesen Pfad existiert kein dokumentierter Ticket-Fallback, genau der Moment, in dem ein gutes KI-Handoff-Design am wichtigsten ist.

Die E-Mail-Aufnahme hat ihre eigene Version des Problems. Die Weiterleitungsklassifizierung schlägt das Wasserzeichen, sodass ServiceNow "jede E-Mail, die diese Kriterien erfüllt, als Weiterleitung klassifiziert, selbst wenn die Nachricht ein Wasserzeichen oder eine Datensatznummer enthält, die sie sonst als Antwort klassifizieren würde." Im Klartext: Das Weiterleiten eines E-Mail-Threads an ServiceNow erzeugt immer ein doppeltes Ticket.

Was ein ServiceNow-Ticketsystem 2026 kostet

Jetzt der Teil, für den eigentlich alle gekommen sind.

ServiceNow nennt keinen Preis, weshalb unser ServiceNow-Preisleitfaden überhaupt existiert. Ich habe die ITSM-Preisseite am Tag des Schreibens erneut geprüft. Drei Pakete, Foundation, Advanced und Prime. Ein Button mit "Get Custom Quote". Kein Währungssymbol irgendwo auf der Seite. Die einzigen Zahlen in der gesamten Vergleichsmatrix sind Kapazitätsgrenzen für App-Engine-Starter-Tabellen und Process-Mining-Datensätze.

Seit dem 9. April 2026 sind die alten Stufen Standard, Pro, Pro Plus, Enterprise und Enterprise Plus verschwunden, wobei die alten SKUs am 1. Juli 2026 ausverkauft wurden. Foundation, Advanced und Prime sind nun die einzige Struktur, die ein neuer Käufer jemals zu sehen bekommt.

Die KI-Zeile sollte man zweimal lesen. Sie fasst die gesamte Paketierung in einer Zeile zusammen. Die KI, die ein Ticket tatsächlich ohne Mensch schließt, gibt es nur bei Prime. Foundation und Advanced bekommen stattdessen assistive KI: Zusammenfassungen, Entwürfe, einen Chatbot. Ein ServiceNow MVP schreibt in der Community dasselbe über Custom-Builds, dass Prime "die einzige Stufe ist, mit der man völlig neue, individuelle KI-Skills und KI-Agenten auf der Plattform bauen kann." Damit ist AI Agent Studio eher eine Feature der Top-Stufe als der Plattform insgesamt, und das vollständigere Kostenbild liegt in unserer Aufschlüsselung zu ServiceNow-KI-Preisen.

Die Trennung zeigt sich auch in ServiceNows eigenem Marketplace, wo der L1 IT Service Desk AI Specialist neben dem Personafilter steht, der Fulfiller als eigene lizenzierte Klasse benennt:

Für wen man tatsächlich zahlt

Das ist die eine Tatsache, die "wie viel kostet ServiceNow" überhaupt beantwortbar macht. Bei ITSM wird auf Basis der Fulfiller-Rolle abgerechnet. Ein ServiceNow-Mitarbeiter definiert das im Lizenzierungsleitfaden als "deine zentralen Service-Desk-Agenten, Case Manager und Workflow-Verantwortlichen. Jeder, der aktiv arbeitet und Datensätze löst" – gezählt als aktive Nutzer, die sich innerhalb der letzten 365 Tage eingeloggt haben.

Requester, also die Mitarbeiter, die Tickets erstellen, werden nicht gezählt. Ein echter Vorteil gegenüber Pro-Sitz-Tools, und dieselbe Art von Ersparnis, die Jira Service Management für einen Support-Anwendungsfall günstiger macht als reines Jira.

Dann kommen die zwei Ausnahmen.

Ein Manager, der nur genehmigt, zählt als separat gemessener Business Stakeholder, nicht als kostenloser Nutzer. Und manche Produkte rechnen nach dem Unrestricted-User-Modell ab, bei dem jeder aktive Nutzer der Instanz zählt. HRSD und Employee Center Pro gehören beide zu dieser Gruppe. Die Ersparnis "Requester sind kostenlos" verdampft also an dem Tag, an dem man das gute Portal kauft, oder an dem HR mit dabei sein will.

Das Ausmaß dieser Entscheidung ist nicht klein. Ein ServiceNow Certified Technical Architect schreibt öffentlich:

"In the world of ServiceNow platform governance, one decision stands above the rest in terms of financial impact: choosing between the Fulfiller (Named User) and the Unrestricted User model. As a ServiceNow Certified Technical Architect (CTA), I've seen this single choice result in a $780,000 variance in spend over a standard 3-year contract."

Bill Martin, ServiceNow Community

Dann taucht ein ServiceNow-Mitarbeiter in den Kommentaren auf, um das verbreitete Missverständnis der Alternative zu korrigieren:

"One quick correction though: Unrestricted Users (UU) aren't actually flat fee. They're still user-based. The "unrestricted" part means unlimited roles within the module, but if the customer's sys_user table grows, they're buying more UU licenses."

Lenny Leppers, ServiceNow Community

Zwei weitere Fallen vom selben Architekten, keine davon steht auf irgendeiner Preisseite. Lizenzierung erfolgt pro Instanz, sodass separate Instanzen für Nordamerika und EMEA die Rechnung verdoppeln. Und er beziffert Geisternutzer in großen Unternehmen auf "20-25 % der ServiceNow-Lizenzen", bei einer jährlichen Preissteigerung von 7 bis 12 %. Unser Leitfaden zu Lizenztypen geht das gesamte Set durch, falls man gerade mitten in einer Verhandlung steckt.

Der Assists-Zähler, jetzt öffentlich

Hier ist das Neue. Am 23. Juli 2026 veröffentlichte ServiceNow den Now Assist Overview als Rechtsdokument, und die Preisliste pro Aktion kam gleich mit. Bis acht Tage vor dem Schreiben dieses Artikels war keine dieser Zahlen öffentlich.

Ein Assist ist "eine Einheit zur Messung der Nutzung von Now-Assist-Skills anhand ausgeführter Skill-Aktionen", und er wird "sowohl in Produktions- als auch in Sub-Produktionsinstanzen" verbraucht. Kontingente werden auf Account-Ebene gepoolt und am Kaufjubiläum statt am Kalenderjahr zurückgesetzt. Überschreitet man sie, "kann ServiceNow dem Kunden die überschüssige Nutzung in Rechnung stellen."

Die Spreizung über drei Größenordnungen hinweg ist die eigentliche Geschichte:

Ein "agentischer Workflow" endet mit Abschluss, nach 20 Aktionen oder nach einer Stunde Inaktivität. Alles über diese 20 Aktionen hinaus startet einen neuen abrechenbaren Workflow. Ein Ticket kann einen also so viel kosten wie zwei.

Der Satz, zu dem ich immer wieder zurückkomme, stammt aus einem ServiceNow-Praxisleitfaden: "Die Überraschung für die meisten Teams ist, dass der größte Verbrauch nicht von Nutzern kommt, die Prompts eintippen. Es ist die Automatisierung, die im Hintergrund läuft." Er nennt vier Quellen für stillen Verbrauch. Virtual Agent, der bei einem nicht passenden Thema auf Now Assist zurückfällt, Workspace-Zusammenfassung, die beim Öffnen eines Case auslöst, individuelle Skill-Kit-Skills und Sub-Produktionsinstanzen. ServiceNow hat im Juni 2026 Notausschalter und Spike-Alarme ausgeliefert, um all das einzudämmen, mit der dokumentierten Anweisung, die Benachrichtigungen nicht zu deaktivieren, weil "Sub-Prod-Umgebungen ebenfalls Assists verbrauchen!"

ServiceNow veröffentlicht für die neuen Stufen keine Poolgröße, also setze deine eigenen Zahlen gegen die letzte veröffentlichte Zuteilung an: 6.000 Assists pro Fulfiller pro Jahr, unter dem alten Pro-Plus-Modell.

Bewege den Schieberegler für den autonomen Agenten von 5 % auf 15 % und sieh, was passiert. Allein dieser eine Schritt macht den ganzen Unterschied zwischen assistiver KI und der autonomen KI, für die man Prime gekauft hat. Genau deshalb würde ich mir eine schriftliche Assist-Prognose während des Vertragsgesprächs wünschen, nicht danach.

Was Leute wirklich über die Arbeit damit sagen

Ich möchte hier fair sein. Es ist leicht, aus einer Suche nach Beschwerden einen Verriss zu basteln.

Der Korpus stützt das nicht. ServiceNow ITSM liegt bei 4,5 von 5 über 1.915 Rezensionen auf G2, 70 % davon mit fünf Sternen und, bemerkenswert, null Prozent mit einem Stern. Capterra bewertet es mit 4,5 über 352 Rezensionen. Niemand Ernsthaftes behauptet, das Incident-, Change- und CMDB-Modell sei falsch.

Was die Leute sagen, ist, dass es schwerfällig ist. G2s eigene Tag-Zählungen setzen Ease of Use mit 168 Erwähnungen als meistgelobtes Attribut, direkt gefolgt von Learning Curve (72), Expensive (60) und Complexity (56). Diese Spannung ist die ehrliche Zusammenfassung des Produkts.

Zur Alltagserfahrung:

"There's a lot of clicks which takes a long time"

Chris C., G2

Zur Einarbeitung, von einem Entwickler, der trotzdem 4,5 von 5 vergab:

"ServiceNow IT Service Management is huge, and when I started as a developer, it took months to really understand how everything connects like tables, scripts, workflows, ACLs. The documentation exists but is scattered, and half the time, you end up finding answers in community forums instead of official docs."

Shruti C., Developer, G2

Und die schärfste Metapher im gesamten Set, aus einer Einführung, die eindeutig schlecht gelaufen ist:

"Imagine you go to a car dealer to buy a new car. You pay the money and you get the keys. When you get outside to pick your new car you see a bunch of parts in a pile. So if you want to drive your car you need to put it together."

Verified User in Insurance, G2

Das Gegengewicht, und ich denke, es ist das Wahrste, was jemand im ganzen Set gesagt hat: Die Meinung der meisten Leute über ServiceNow ist eigentlich eine Meinung über die Einführung von jemand anderem. Ein Hacker-News-Kommentator brachte es so auf den Punkt, dass "eine gut geführte Instanz fliegen kann", und machte für die meisten schlechten Erfahrungen Kunden verantwortlich, die "sich mit schrecklichem Code und schlecht gestalteten LCNC-Apps abschleppen." Das deckt sich mit dem, was ich sehe. Die Plattform ist selten das Problem. Das 400-Felder-Formular, das jemand darauf gebaut hat, meistens schon.

Wo es passt, und wo ich es nicht einsetzen würde

ServiceNow ist die richtige Wahl, wenn Tickets nicht der Kern der Sache sind. Wenn man Incidents braucht, die mit einer CMDB verknüpft sind, Change Management mit echter CAB-Autorisierung, Problem-Datensätze, die die Incidents überdauern, die sie ausgelöst haben, plus eine einzige Workflow-Engine, die IT, HR-Support und Facility-Management umfasst, kommt im Mittelstandssegment nichts heran. Im direkten Vergleich mit Freshservice ist genau diese Breite das ganze Argument. In dieser Größenordnung ist es das Geld wert.

Ich würde es nicht kaufen, um nur eine Warteschlange zu betreiben. Wenn Tickets rein, Tickets raus der ganze Job ist, zahlt man Enterprise-Plattform-Preise für einen Bruchteil der Plattform, und die Beschwerde über das teure Ticketing-Tool schreibt sich von selbst. Ein Hacker-News-Kommentator beschrieb einen CIO, der genau das tat: Er ersetzte einen bestehenden Tracker für nur zwei Warteschlangen, ohne CMDB und ohne Change Management, für "128k pro Jahr." Wenn das die Form deines Bedarfs ist, sind unsere Übersicht für kleine Teams oder die Open-Source-Optionen die ehrlichere Antwort.

Der dritte Fall ist der interessante, und dort befinden sich tatsächlich die meisten Leser dieses Artikels. ServiceNow ist bereits installiert, es geht nirgendwohin, und die Warteschlange wächst weiter. Es rauszureißen steht nicht zur Debatte. Eine Prime-Stufe hinzuzufügen, damit ein KI-Spezialist Tier-1-Tickets schließen kann, ist ein Budgetgespräch mit einem unveröffentlichten Zähler im Gepäck. Damit bleibt ein Hebel, derselbe, bei dem jedes IT-Helpdesk-KI-Projekt am Ende landet: Deflection bei der Aufnahme.

eesel vor deiner ServiceNow-Warteschlange ausprobieren

Lass mich ehrlich sagen, was ich hier anbiete und was nicht. Die ehrliche Version ist ohnehin nützlicher.

eesel ist kein ServiceNow-Plugin. Es gibt keine ServiceNow-Integration auf unserer Integrationsseite, und ich sage das lieber hier, als es dich mitten in einer Testphase entdecken zu lassen.

Was eesel tut, ist, einen Schritt früher anzusetzen, auf den Kanälen, auf denen IT-Fragen tatsächlich entstehen. Es antwortet in Slack, in Microsoft Teams und per E-Mail, bevor irgendjemand ein Formular öffnet. Das Wissen, aus dem es antwortet, ist Dokumentation, die man bereits geschrieben hat, egal wo sie heute liegt: Confluence, Google Docs, Notion, ein Hilfe-Center.

Ich baue die Agenten, die das tun, deshalb ist mir der Mechanismus wichtig. Der Agent durchsucht die tatsächliche Dokumentation, antwortet, wenn er dafür eine Grundlage hat, und schweigt, wenn nicht. Genau dieser letzte Teil ist das ganze Spiel. Nachdem ich gesehen habe, wie ein selbstsicher klingender Bot in einer Live-Warteschlange falsche Antworten gegeben hat, simulieren wir mittlerweile jedes Rollout gegen historische Tickets, bevor es überhaupt an eine echte Person geht, und alles unterhalb der Konfidenzschwelle wird eskaliert, statt zu raten.

Die Zahl, auf die ich verweisen würde, ist nicht unsere eigene. Jason Loyola, Head of IT bei InDebted, betreibt eesel als First Responder am internen IT-Desk, und die Ergebnisse sind öffentlich: heute werden 15 % der eingehenden Probleme vollständig abgefangen, mit 55 % als Ziel, während Wissen aus gelösten Tickets zurückgeschrieben wird. Seine eigene Beschreibung des Setups: "Es verhält sich im Grunde genau wie ein Agent."

Noch zwei Einschränkungen, die man kennen sollte, bevor man es ausprobiert. Es löst kein Dokumentationsproblem. Wenn die Antwort auf "wie bekomme ich einen neuen Laptop" nirgendwo in deiner internen Wissensdatenbank steht, wird keine KI sie erfinden. Und es ist eine Ebene, kein Ersatz, also bleiben dein Incident-, Change- und CMDB-Modell genau dort, wo sie sind. Die Preisgestaltung läuft pro bearbeitetem Ticket statt pro Sitz, was zumindest bedeutet, dass die Rechnung nicht jedes Mal steigt, wenn die IT jemanden einstellt.

Man kann es kostenlos ausprobieren und auf die Fragen loslassen, die der eigene Service Desk fünfzigmal im Monat beantwortet, um dann zu sehen, wie viele davon überhaupt ein Ticket gebraucht hätten.