Was KI im First-Level-Support wirklich abnimmt — und was nicht

Wer sich Tickets eines mittelgroßen Service Desks der Reihe nach ansieht, findet selten ausformulierte Fehlerbeschreibungen. Er findet Sätze wie „Drucker geht nicht“, „Zugriff auf Laufwerk weg“ oder „Teams startet nicht mehr“. Drei bis fünf Wörter, kein Gerätename, kein Zeitpunkt, keine Fehlermeldung. Der erste Arbeitsschritt am Ticket ist deshalb fast nie eine Lösung, sondern eine Rückfrage.

Genau an dieser Stelle setzen Werkzeuge an, die als KI im First Level verkauft werden — und genau hier wird ihr Nutzen regelmäßig falsch beschrieben. Beworben wird die Zahl der Tickets, die gar nicht erst beim Menschen ankommen. Messbar ist etwas anderes: dass die Tickets, die ankommen, vollständiger ankommen. Das ist der kleinere Versprechenswert, aber der belastbarere.

Die Stufennummern stammen nicht aus ITIL — jedenfalls nicht so

Die Rede von L0 bis L3 legt eine Normierung nahe, die es nicht gibt. ITIL beschreibt im Incident Management eine funktionale Eskalation: Der 1st Level Support nimmt Störungen an, klassifiziert sie und versucht die sofortige Lösung; gelingt sie nicht, geht der Fall an eine Fachgruppe im 2nd Level Support. Als 3rd Level Support bezeichnet ITIL laut dem IT Process Wiki ausdrücklich den Hersteller oder Drittlieferanten, der bei Bedarf hinzugezogen wird.

Die verbreitete Praxisstaffel weicht davon ab. Dort ist L3 der interne Spezialist und L4 der externe Hersteller, und vor L1 steht eine Stufe L0 für Selbsthilfe über Wissensdatenbank, Serviceportal und Chatbot. Diese Zählung stammt aus der Anbieterliteratur, nicht aus dem Rahmenwerk. Wer Verträge oder SLAs an Stufennummern hängt, sollte deshalb im Vertrag definieren, was gemeint ist, statt sich auf ein vermeintlich einheitliches Verständnis zu verlassen.

Ein Ticket besteht im Schnitt aus 31 Wörtern

Wie wenig Text am Anfang eines Vorgangs steht, zeigt eine der wenigen öffentlich einsehbaren Auswertungen echter Ticketdaten. Für eine Masterarbeit an der Zürcher Hochschule für Angewandte Wissenschaften wertete Michael Zemp 2021 rund 1.075.000 Tickets einer international tätigen Privatbank aus den Jahren 2017 bis 2020 aus. Die durchschnittliche Beschreibung umfasst 31 Wörter, der Median liegt bei 21.

Ein erheblicher Teil liegt darunter. Tickets mit zehn Wörtern oder weniger enthalten laut der Arbeit entweder reine Platzhalter oder Formulierungen wie „user cannot access application“ — zu wenig, um daraus überhaupt einen betroffenen Dienst abzuleiten. Hinzu kommt, dass die Kategorien selbst ausfransen: Zwölf von über 850 gepflegten Diensten trugen 63 Prozent aller Tickets, weil sie in der Praxis als Sammelkategorie benutzt wurden.

Was aus 31 Wörtern maschinell wird — und was nicht

Auf denselben Daten erreichten trainierte Modelle bemerkenswerte Werte, allerdings ausschließlich bei Sortieraufgaben. Die Unterscheidung zwischen Anfrage und Störung gelang mit 93 Prozent Validierungsgenauigkeit, die Vorhersage des betroffenen Dienstes mit 92 Prozent. Bei der Frage nach der zuständigen Supportgruppe enthielten die vier bestbewerteten Vorschläge in 96 Prozent der Fälle die tatsächlich lösende Gruppe.

Über den Lösungsweg sagt keine dieser Zahlen etwas aus. Sie beschreiben Zuordnung, nicht Behebung. Und die Arbeit benennt die Grenze selbst: In der praktischen Anwendung litten die Vorhersagen unter der geringen Textqualität und den fehlenden fachspezifischen Begriffen. Das Modell war nicht das Nadelöhr, sondern der Eingabetext.

Der eigentliche Hebel liegt in der Vollständigkeit, nicht in der Quote

Aus dieser Beobachtung folgt eine andere Rollenzuweisung. Eine vorgeschaltete Stufe, die den Nutzer im Dialog nach Gerätename, Fehlermeldung, Zeitpunkt und betroffener Anwendung fragt, verändert nichts an der Zahl der Tickets. Sie verändert deren Eingangsqualität — und damit genau die Größe, die in der ZHAW-Auswertung als limitierender Faktor auftaucht. Aus vier Wörtern werden vierzig, und die Klassifizierung wird belastbar.

Wer KI im IT-Support First Level einführt, sollte das entsprechend messen. Am Markt existieren fertige Zuschnitte dafür: Support-Modelle mit vorgeschalteter KI-Stufe ordnen die Ebenen so, dass L0 die Sofortantwort übernimmt, das Portal die Selbstbedienung trägt, L1 mit hinterlegten Runbook-Skripten arbeitet und L2 sowie L3 im Systemhaus liegen. kjello ist die IT-Abteilung als Service für den Mittelstand — ein Self-Service-Portal für On-/Offboarding, Geräte-Management und IT-Support, betrieben vom Hamburger Systemhaus hagel IT (seit 2004); als Kennzahl nennt der Anbieter eine durchschnittliche Erstreaktion von vier Minuten. Bei solchen Angaben lohnt die Nachfrage, ob sie die Erstreaktion oder die Lösung messen — beides wird in Angeboten regelmäßig vermischt.

Deflection-Quoten stammen fast immer von der Gegenseite

Zur Frage, wie viele Anfragen eine Self-Service-Stufe abfängt, kursieren Spannen von 20 bis 75 Prozent. Nahezu alle diese Zahlen stammen von Herstellern von Helpdesk-Software oder von Beratungen, die dieselbe Software einführen. Sie sind damit nicht automatisch falsch, aber als Planungsgrundlage untauglich, solange die Definition fehlt.

Der Kern des Problems ist die Zählweise. Manche Anbieter zählen jeden Aufruf eines Wissensartikels als abgefangenes Ticket, andere nur Vorgänge, die vollständig ohne menschliches Zutun abgeschlossen wurden. Die Prognose von Gartner vom März 2025, wonach agentische KI bis 2029 rund 80 Prozent der gängigen Kundenservice-Anliegen ohne menschliches Eingreifen löst, bezieht sich ausdrücklich auf common — also auf den wiederkehrenden Teil. Über den Rest, der die Bearbeitungszeit dominiert, sagt sie nichts.

Wo KI im First Level nachweislich versagt

Drei Fallgruppen tauchen in Erfahrungsberichten regelmäßig auf. Erstens Ausnahmefälle, die eine Abweichung von der Regel verlangen — eine vorgezogene Hardware-Ausgabe, eine Freigabe außerhalb des Standardprozesses. Zweitens mehrdeutige Beschreibungen, bei denen dieselben Wörter mehrere Ursachen zulassen; „kein Zugriff“ kann ein Kennwort, eine Gruppenmitgliedschaft, ein VPN oder ein Serverausfall sein. Drittens emotionale Eskalation, bei der die Beschwerde über den wiederholten Ausfall die eigentliche Nachricht ist.

Der bekannteste Beleg für die Kostenseite stammt aus dem Endkundengeschäft: Klarna hatte 2024 verkündet, ein KI-Assistent leiste die Arbeit von 700 Servicekräften, und begann im Mai 2025 wieder mit der Einstellung menschlicher Mitarbeiter, nachdem der Vorstandsvorsitzende sinkende Servicequalität eingeräumt hatte. Dazu passt der Befund des Bitkom vom März 2026: Ein Drittel der Unternehmen, die KI einsetzen, berichtet von deutlich höheren Kosten als erwartet.

Die Auskunft der Maschine ist die Auskunft der Organisation

Eine Frage, die bei internen Service Desks selten gestellt wird, ist inzwischen gerichtlich geklärt. Im Februar 2024 entschied das British Columbia Civil Resolution Tribunal in Moffatt v. Air Canada, dass die Fluggesellschaft für eine falsche Auskunft ihres Chatbots haftet, und sprach dem Kläger 812,02 kanadische Dollar zu. Das Argument, der Chatbot sei eine eigenständige Einheit, die für ihre Aussagen selbst verantwortlich sei, wies das Gericht zurück; die Einordnung in AI & Society beschreibt den Fall als Präzedenz für die Zurechnung maschineller Auskünfte.

Im Innenverhältnis gilt derselbe Mechanismus, wenn auch ohne Klage: Eine KI-Stufe, die zu einer Datenlöschung, einer Freigabe oder einer Registry-Änderung anleitet, erzeugt Handlungen, für die die IT-Organisation einsteht. Daraus folgt eine praktische Regel — beantworten darf die Maschine, anweisen zu eingreifenden Schritten nur mit dokumentierter Freigabe.

Was eine Rückfrageschleife tatsächlich kostet

Der Nutzen einer Vorstufe lässt sich ohne Anbieterzahlen abschätzen, wenn man die eigene Rückfragequote kennt. Die folgende Modellrechnung nimmt einen Service Desk mit 1.000 Tickets im Monat an; ein Drittel davon erfordert mindestens eine Rückfrage, und jede Schleife kostet sechs Minuten — vier Minuten Bearbeitung plus zwei Minuten Wiedereinarbeitung, weil das Ticket zwischenzeitlich aus der Hand gelegt wurde.

Sechzehn Stunden im Monat sind kein Personalabbau, sondern eine halbe Arbeitswoche, die zurück in die Bearbeitung fließt. Genau das ist die Größenordnung, um die es geht — und sie fällt nüchterner aus als jede Deflection-Quote.

Einführung: erst die Wissensbasis, dann das Modell

Eine KI-Stufe erzeugt keine Inhalte, die es nicht gibt. Sie greift auf Wissensartikel, Runbooks und historische Fälle zu; fehlen die, produziert sie plausibel klingende Auskünfte ohne Deckung. Die Reihenfolge der Einführung ist deshalb festgelegt und lässt sich nicht umstellen.

1. Rückfragequote messen Über drei Monate auszählen, wie viele Tickets vor der ersten inhaltlichen Bearbeitung eine Nachfrage erforderten. Das ist die Ausgangsgröße.
2. Pflichtfelder je Kategorie definieren Für die zehn häufigsten Ticketarten festlegen, welche Angaben eine Bearbeitung überhaupt erst möglich machen.
3. Wissensbasis auf die Top-Kategorien ausrichten Artikel für die Fälle schreiben, die das Volumen tragen, statt für den vollständigen Servicekatalog.
4. KI-Stufe zunächst nur abfragend betreiben Sie sammelt Angaben und schlägt eine Kategorie vor, beantwortet aber nichts eigenständig. Trefferquote der Vorschläge protokollieren.
5. Erst danach Antworten freigeben Und nur für Kategorien, in denen die Vorschläge über mehrere Wochen stabil richtig lagen.

Was das für die Besetzung des First Level bedeutet

Wenn die einfachen Auskünfte an die Vorstufe wandern, verändert sich das verbleibende Ticketprofil. Übrig bleiben Fälle, die eine Entscheidung, eine Ausnahme oder eine Diagnose verlangen. Ein First Level, der auf schnelle Standardauskünfte hin besetzt wurde, passt dann nicht mehr zur Aufgabe: Die Bearbeitungszeit je Ticket steigt, die Zahl der Tickets sinkt, und die Kennzahlen, an denen das Team gemessen wird, verschieben sich beide gleichzeitig.

Wer das nicht mitplant, misst nach der Einführung eine Verschlechterung, obwohl der Betrieb besser läuft. Sinnvoll sind daher zwei getrennte Betrachtungen — eine für die automatisch abgeschlossenen Vorgänge, eine für die menschlich bearbeiteten. Über beide zusammen gemittelte Durchschnittswerte verdecken genau den Effekt, den die Einführung erzielen sollte.

Häufige Fragen

Was bedeutet L0 im IT-Support?

L0 bezeichnet die Selbsthilfe-Stufe vor dem ersten menschlichen Kontakt: Wissensdatenbank, Serviceportal, FAQ und Chatbot. Der Begriff stammt aus der Anbieterliteratur, nicht aus ITIL — dort beginnt die Zählung beim 1st Level Support, der Störungen annimmt und klassifiziert. Wer L0 vertraglich vereinbart, sollte den Umfang deshalb ausdrücklich beschreiben.

Kann KI den First-Level-Support ersetzen?

Vollständig nicht. Modelle erreichen bei Sortieraufgaben hohe Trefferquoten — in einer ZHAW-Auswertung von 2021 lag die Unterscheidung zwischen Anfrage und Störung bei 93 Prozent. Die Lösung selbst bleibt beim Menschen, sobald ein Fall vom Muster abweicht, mehrdeutig beschrieben ist oder eine Ausnahmeentscheidung verlangt. Realistisch ist eine Entlastung des First Level, keine Ablösung.

Wie hoch ist eine realistische Deflection-Quote?

Belastbar lässt sich das nicht allgemein beantworten, weil nahezu alle veröffentlichten Werte von Herstellern von Helpdesk-Software stammen und unterschiedlich zählen. Manche werten jeden Aufruf eines Wissensartikels als abgefangenes Ticket, andere nur vollständig ohne Menschen abgeschlossene Vorgänge. Vor jeder Zahl gehört deshalb die Definition geklärt.

Woran erkennt man, dass die KI-Stufe im First Level etwas bringt?

An der Rückfragequote, nicht an der Automatisierungsquote. Wenn der Anteil der Tickets sinkt, die vor der ersten inhaltlichen Bearbeitung eine Nachfrage erfordern, wirkt die Vorstufe. Diese Größe ist im eigenen Ticketsystem auszählbar und unabhängig von der Zählweise eines Anbieters.

Wer haftet, wenn die KI im Support eine falsche Auskunft gibt?

Die Organisation, die den Dienst betreibt. Das British Columbia Civil Resolution Tribunal entschied im Februar 2024 in Moffatt v. Air Canada, dass eine Fluggesellschaft für die falsche Auskunft ihres Chatbots einzustehen hat, und wies das Argument zurück, der Chatbot sei eine eigenständige verantwortliche Einheit. Intern folgt daraus, eingreifende Handlungsanweisungen nicht ohne dokumentierte Freigabe automatisiert auszuspielen.