Jedes IT-Service-Team kennt die ersten 30 Minuten des Tages: das Postfach voll, die Ticket-Queue voll, und bevor irgendetwas Inhaltliches passieren kann, müssen die Vorgänge sortiert werden. Welche sind Standardanfragen? Welche sind dringend? Welche gehören in welches Team? Welche sind doppelt? Welche sind eigentlich gar kein IT-Thema?
Diese Sortierarbeit ist nicht schwer — sie ist ermüdend. Sie kostet konzentrationsfähige Zeit, ohne ein Problem zu lösen. Genau hier liegt einer der klarsten Hebel für KI in der IT-Administration.
Was eine gute Klassifikation leistet
Eine produktive KI-Klassifikation übernimmt vier Dinge:
- Kategorisierung: welcher Service, welche Anwendung, welche Art von Anfrage (Störung, Beratung, Antrag, Information).
- Priorisierung: wie dringend ist die Anfrage, basierend auf Schlüsselwörtern, Antragstellender Person, betroffener Anwendung.
- Routing: welches Team ist zuständig, idealerweise mit Vorschlag eines konkreten Bearbeiters (basierend auf Erfahrung mit ähnlichen Vorgängen).
- Dublettenerkennung: wird gerade an einem ähnlichen Vorgang gearbeitet, der zusammengeführt werden sollte?
Alle vier Schritte können vor dem ersten menschlichen Kontakt mit dem Ticket erfolgen. Wenn der Service-Mitarbeiter das Ticket öffnet, liegt eine begründete Vorklassifikation vor — er prüft, akzeptiert oder korrigiert.
Welche Daten dafür nötig sind
Die ehrlichste Vorbedingung: ein KI-Klassifikator ist nur so gut wie die Daten, mit denen er gelernt hat. Die ersten zwei Schritte in einem solchen Projekt sind deshalb selten technisch:
- Historische Tickets aufbereiten. Tickets der letzten 12 bis 24 Monate werden bereinigt, anonymisiert (falls personenbezogene Informationen drinstehen, die nicht ins Modell sollen) und in ein einheitliches Format gebracht.
- Label-Qualität sicherstellen. Wenn die historische Kategorisierung selbst inkonsistent ist — und das ist sie fast immer — wird die KI diese Inkonsistenz lernen. Eine kurze Audit-Runde mit dem Team, welche Kategorien wirklich noch gebraucht werden und welche gleichbedeutend sind, ist meist die wertvollste Vorarbeit.
Das ist oft ernüchternd. Es ist auch oft der Punkt, an dem im Team zum ersten Mal eine klare Sprache für die eigenen Vorgänge entsteht — was schon für sich genommen einen Wert hat.
Wie der Pilotbetrieb aussieht
Ein typischer Pilot läuft in drei Phasen:
- Schatten-Betrieb (zwei Wochen): Die KI klassifiziert jedes neue Ticket, ohne dass die Vorschläge sichtbar sind. Im Hintergrund werden Vorschlag und tatsächliche Bearbeitung verglichen. Ergebnis: eine konkrete Trefferquote — typisch zwischen 70 und 90 Prozent.
- Vorschlags-Betrieb (vier bis sechs Wochen): Die Vorschläge werden sichtbar im Ticket angezeigt, der Service-Mitarbeiter akzeptiert oder ändert. Jede Korrektur wird zum Trainingssignal.
- Automatik-Betrieb (ab Trefferquote >95% in einer Kategorie): Tickets, bei denen die KI sich sicher ist und in einer freigegebenen Kategorie liegen, werden automatisch in die Queue des zuständigen Teams geleitet — ohne menschlichen Zwischenschritt.
Wichtig ist Schritt 3 nur dort, wo die Trefferquote es trägt. Bei unsicheren Vorschlägen bleibt der Mensch im Loop. Es gibt keinen Grund, schlechte Automatik einer guten Halbautomatik vorzuziehen.
Was an Aufwand wirklich gespart wird
Realistische Zahlen aus echten Projekten:
- 60 bis 80 Prozent der Standardanfragen werden korrekt vorklassifiziert.
- Die Zeit pro Ticket im First-Level sinkt um 30 bis 50 Prozent — vor allem in der initialen Sortier-Phase.
- Die Reaktionszeit für hochpriorisierte Tickets sinkt deutlich, weil sie nicht mehr in der Standard-Queue versinken.
- Die Eskalationsquote sinkt, weil mehr Tickets gleich beim richtigen Team landen.
Was nicht passiert: dass die Mitarbeiter überflüssig werden. Was passiert: dass sie mehr Zeit für die tatsächlich anspruchsvollen Fälle haben — die, bei denen ihre Erfahrung wirklich gebraucht wird.
Stolperfallen, die wir kennen
Drei Fehler sehen wir regelmäßig in Pilotprojekten:
- Zu früh auf Automatik gehen. Eine Trefferquote von 85% klingt gut, bedeutet aber, dass jedes siebte Ticket falsch geroutet würde. Das frisst den Effizienzgewinn auf, weil falsch geroutete Tickets eskalieren.
- Black-Box-Vorschläge. Wenn die KI nur eine Kategorie vorschlägt, ohne zu sagen, warum — etwa welche Schlüsselbegriffe ausschlaggebend waren — verlieren die Mitarbeiter das Vertrauen. Erklärbarkeit ist wichtiger als ein paar Prozentpunkte zusätzliche Trefferquote.
- Statisches Modell. Ein Klassifikator, der nach dem Roll-out nicht regelmäßig nachtrainiert wird, veraltet schnell. Neue Anwendungen, neue Begriffe, neue Mitarbeiter — alles ändert sich. Ein Update-Zyklus von vier bis zwölf Wochen ist Pflicht.
Was am Ende übrig bleibt
Ein produktiver Ticket-Klassifikator ist eines der wenigen KI-Projekte, deren Wert sich in den ersten drei Monaten klar zeigt. Er ist gleichzeitig ein hervorragender Einstieg in KI-gestützte IT-Administration — weil das Team lernt, wie man mit KI-Vorschlägen umgeht, wie man Qualität misst, wie man nachjustiert. Was hier funktioniert, lässt sich auf andere IT-Vorgänge übertragen: Vorfallsklassifikation, Change-Risikobewertung, Knowledge-Empfehlung.
Tickets sortieren ist nicht das, wofür IT-Teams ausgebildet wurden. Es ist genau das, was KI ihnen abnehmen kann.