Ihr 1st-Level bekommt täglich 30 bis 50 Tickets, und gefühlt sind davon zwei Drittel derselbe Frust — Passwort vergessen, Drucker offline, Zugriff auf Ordner X fehlt, Outlook startet nicht. Diese Seite beschreibt, wie Sie die Triage so weit automatisieren, dass Ihr Team wieder Zeit für die kniffligen 20 Prozent hat — und der Mensch trotzdem im Loop bleibt, wo es zählt.
Kennen Sie diese Situation?
- Die Person am 1st-Level macht 70 Prozent ihrer Zeit dasselbe — klassifizieren, zuordnen, Standard-Antwort tippen, ans 2nd-Level eskalieren oder eben selbst lösen. Der gleiche Vorgang, fünfzigmal am Tag.
- Tickets landen in der zentralen Mailbox oder im Ticket-System und bleiben dort vier Stunden liegen, weil gerade niemand triagiert hat. Der Fragende denkt, niemand kümmert sich.
- Es gibt drei Standard-Antworten, die so oft kopiert werden, dass sie inzwischen sechs leicht unterschiedliche Versionen haben — jede mit eigenen Tippfehlern.
- Eilige Tickets gehen unter, weil sie optisch genauso aussehen wie Routine-Tickets. Die Geschäftsführung bekommt mit, dass „die IT überlastet ist”, obwohl in Wahrheit ein Prozess-Problem vorliegt.
- Wenn eine Person aus dem 1st-Level krank ist oder Urlaub hat, staut sich der Eingang sichtbar — weil kein Stand-By existiert und das Wissen, was wohin gehört, nicht dokumentiert ist.
Warum jetzt — und nicht später
- Die Mitarbeitendenzahl wächst, die IT-Mannschaft nicht. Mittelständische IT-Teams sind dünn besetzt. Jede zusätzliche Person im Haus erzeugt im Schnitt Tickets, aber niemand stellt deshalb eine zusätzliche 1st-Level-Kraft ein. Irgendwann kippt das Verhältnis.
- Die guten Leute kündigen, wenn sie nur noch Passwörter zurücksetzen. 1st-Level-Tätigkeit ist Einstieg, nicht Lebensaufgabe. Wer dort gute Leute halten will, muss ihnen die Routine vom Hals halten.
- Klassifikation per LLM funktioniert mittlerweile zuverlässig genug, dass es im Mittelstand ankommen darf. Vor drei Jahren war das experimentell, heute ist es betriebsfähige Standardtechnik — wenn man die Grenzen kennt.
So sähe das bei Ihnen aus
Schritt 1 — Ticket-Historie analysieren (Woche 1–2)
Wir schauen uns die letzten 6–12 Monate Ihrer Tickets an: Was ist die häufigste Kategorie, was sind die häufigsten Lösungen, wo hakt es zwischen 1st und 2nd Level, was wird falsch klassifiziert und führt zu Schleifen. Daraus entsteht eine Karte, welche Ticket-Typen automatisierbar sind, welche teil-automatisierbar, welche menschlich bleiben müssen.
Stack: API Ihres Ticket-Systems (Jira Service Management, Zammad, OTRS/Znuny, Freshservice, ServiceNow oder Microsoft Dynamics 365 Customer Service — je nachdem, was bei Ihnen läuft). Auswertung in Python, Ergebnis als kompakter Bericht für Geschäftsführung und IT-Leitung.
Schritt 2 — Klassifikator aufbauen (Woche 2–4)
Wir bauen einen Klassifikator, der ein eingehendes Ticket einer Kategorie zuordnet (Passwort, Hardware, Software, Berechtigung, Sonstiges), eine Dringlichkeit einschätzt (Standard, eilig, kritisch) und einen Vorschlag macht, an wen es gehen sollte. Der Klassifikator läuft auf einem Sprachmodell mit Ihrem eigenen Kategorie-Schema — nicht mit einem generischen „IT-Klassen”-Schema von der Stange.
Stack: Azure OpenAI in Ihrem Azure-Tenant, Klassifikations-Prompt mit Few-Shot-Beispielen aus Ihren echten Tickets, optional Feinjustierung über Evaluierungs-Runs.
Schritt 3 — Auto-Zuweisung und Erstantwort-Vorschlag (Woche 4–6)
Bei klaren Kategorien wird das Ticket automatisch an die zuständige Gruppe zugewiesen, und es wird eine vorgeschlagene Erstantwort generiert — basierend auf vorhandenen Lösungsartikeln oder ähnlichen, schon gelösten Tickets. Wichtig: In den ersten Wochen geht die Erstantwort NICHT automatisch raus. Ein Mensch sieht den Vorschlag und drückt Senden oder korrigiert. Mensch-im-Loop ist Standard, nicht Ausnahme.
Stack: Webhook oder Trigger in Ihrem Ticket-System, Verarbeitung via Azure Function oder Power Automate, Antwort-Vorschlag-Generierung über Azure OpenAI, optional Anbindung an Ihre interne Wissensbasis aus der RAG-Suche.
Schritt 4 — Eskalations-Logik mit Augenmaß (Woche 5–7)
Tickets, bei denen der Klassifikator unsicher ist (niedrige Konfidenz), gehen zurück in den menschlichen Eingang und werden NICHT automatisch zugewiesen. Lieber ein Ticket händisch nachbessern als zehn falsch zugewiesene, die anschließend durch alle Teams wandern. Wir kalibrieren die Konfidenz-Schwelle so, dass falsch-automatisierte Fälle die Ausnahme sind.
Stack: Konfidenz-Score aus dem Klassifikator, Fallback-Regel im Trigger, Logging in einen Dashboard-View für die IT-Leitung.
Schritt 5 — Erprobung, messen, ausweiten (Woche 6–10)
Wir starten mit einer Kategorie — etwa Passwort-Resets und Standard-Zugriffsanfragen — und messen vier Wochen: Wie viele Tickets wurden korrekt vorklassifiziert, wie oft musste die Erstantwort geändert werden, wie schnell ging der Durchlauf. Erst wenn die Zahlen stimmen, erweitern wir auf weitere Kategorien. Ziel ist nicht „alles automatisieren”, sondern „die Routinen erkennen und sauber bearbeiten lassen”.
Worauf Sie achten sollten
- Lassen Sie sich das Mensch-im-Loop-Konzept zeigen, bevor irgendwer „voll-automatische” Antwort-Versand-Funktionen vorschlägt. Eine KI, die direkt mit Endnutzenden kommuniziert, ohne menschliche Freigabe in der Einführungsphase, ist ein Reputations-Risiko. Eine schlecht formulierte Antwort an einen verärgerten Endnutzenden ist schlimmer als ein langsam beantwortetes Ticket.
- Klären Sie, wie Falsch-Klassifikationen behandelt werden. Es gibt keinen Klassifikator mit 100 Prozent Genauigkeit. Wichtig ist, dass falsche Zuordnungen schnell sichtbar werden und sich daraus eine Korrektur-Schleife ergibt — nicht, dass falsche Zuordnungen unter den Tisch fallen.
- Seien Sie vorsichtig bei Anbietern, die Ihnen eine fertige „IT-Helpdesk-KI” verkaufen, ohne Ihre Ticket-Historie gesehen zu haben. Ihre Kategorien, Ihre Sprache, Ihre Standard-Lösungen sind spezifisch. Ein Standard-Klassifikator von der Stange trifft Ihre Realität selten gut.
- Stellen Sie sicher, dass das Ticket-System überhaupt API-fähig genug ist. Wenn Ihr System nur per Mail oder per starrem Webformular funktioniert und keine Webhooks oder API-Trigger anbietet, ist die Automation aufwendiger als gedacht. Manchmal ist der erste Schritt nicht Automation, sondern Wechsel oder Update des Ticket-Systems.
Was sich danach realistisch ändert
- Das 1st-Level verbringt deutlich weniger Zeit mit Sortieren und Tippen und mehr Zeit mit den Tickets, die wirklich Aufmerksamkeit brauchen.
- Endnutzende bekommen schneller eine Erstreaktion — auch dann, wenn niemand gerade aktiv triagiert, weil der Auto-Hinweis „Ihr Ticket wurde Gruppe X zugewiesen, voraussichtliche Bearbeitung bis Y” sofort rausgeht.
- Eilige Tickets werden als solche erkannt und vorn einsortiert, nicht in der Reihenfolge des Eingangs vergraben.
- Standard-Antworten werden konsistent — keine sechs Varianten desselben Texts mit unterschiedlichen Tippfehlern mehr.
- Die IT-Leitung bekommt erstmals belastbare Zahlen, was die häufigsten Ticket-Ursachen sind — und damit eine Grundlage, wo es sich lohnt, das Problem an der Wurzel zu lösen statt jedes Mal wieder Tickets dazu zu beantworten.
Was Sie beisteuern
- Zugriff: Lesezugriff auf die Ticket-Historie (anonymisiert, wenn Personalbezug heikel ist) und administrativen Zugriff auf das Ticket-System für die Trigger-Einrichtung.
- Stakeholder-Zeit: Die Person, die heute den 1st-Level macht oder leitet — geschätzt 4–6 Stunden in der Analyse-Phase, danach 1–2 Stunden pro Woche in den ersten Erprobungs-Wochen. Ohne dieses Wissen wird der Klassifikator generisch und damit schlecht.
- Betriebsrat und Datenschutz: KI-gestützte Bearbeitung von Mitarbeitenden-Tickets ist mitbestimmungs- und datenschutz-relevant. Wir liefern die technische Beschreibung, Sie bringen das in Ihre Gremien.
- Bereitschaft, Standard-Antworten zu konsolidieren. Die KI kann Antworten vorschlagen, aber sie tut das auf Basis dessen, was bei Ihnen schon gut formuliert ist. Wenn es keine guten Vorlagen gibt, ist die erste Frucht des Projekts paradoxerweise eine aufgeräumte Wissensbasis.
Risiken & wann es NICHT passt
- Wenn Ihr Ticket-Volumen unter 10 pro Tag liegt und die Routine-Quote eher klein ist. Dann lohnt die Investition nicht, dann ist eine kleine Verbesserung an Vorlagen oder ein klareres Triage-Protokoll der bessere Hebel.
- Wenn das Ticket-System eine Black Box ist und kein API-Zugriff möglich. Dann zuerst das System klären, dann automatisieren.
- Wenn die Erwartung ist, dass KI das gesamte 1st-Level ersetzt. Sie ersetzt es nicht. Sie nimmt ihm Routine ab und macht den Job interessanter. Wer einsparen will, indem er Stellen abbaut, sollte ehrlich genug sein, das beim Projektstart zu sagen — und nicht nachher behaupten, „die KI hat es entschieden”.
- Wenn der Datenschutz-Rahmen für KI-gestützte Verarbeitung von Mitarbeitenden-Anfragen bei Ihnen nicht vorbereitet ist. Das ist klärbar, aber nicht in zwei Tagen — und nicht durch die IT allein.
So fängt das Gespräch an
30 Minuten Erstgespräch, kostenfrei, per Video oder Telefon. Was wir klären: Welches Ticket-System läuft bei Ihnen, wie viele Tickets pro Tag, wie ist das 1st-Level besetzt, welche Themen wiederholen sich am häufigsten gefühlt — und was ist der aktuelle Auslöser (Personalmangel, Beschwerden über Reaktionszeit, Wachstum)? Aus diesem Bild ergibt sich, ob ein Klassifikator-Projekt der richtige Schritt ist oder zuerst etwas Anderes — etwa Aufräumen der Standard-Antworten — mehr bringt.
Auf eine Anfrage reagieren wir remote sofort zu Servicezeiten. Ein Erstgespräch ist typischerweise in 3–5 Werktagen einrichtbar; den nächsten freien Termin bestätigen wir verbindlich nach Ihrer Anfrage.
Häufige Fragen
Was, wenn die KI ein Ticket falsch klassifiziert? In den ersten Wochen passiert das mit Sicherheit. Deshalb läuft in den ersten Wochen ein Mensch über die Klassifikationen drüber, korrigiert offensichtliche Fehler, und diese Korrekturen fließen in die Justierung zurück. Erst wenn die Trefferquote stabil über 90 Prozent für eine Kategorie liegt, lockern wir die Mensch-im-Loop-Pflicht für diese Kategorie. Andere Kategorien bleiben weiter unter menschlicher Aufsicht.
Lesen Microsoft oder OpenAI dann unsere Tickets mit? Bei Nutzung von Azure OpenAI in Ihrem eigenen Azure-Tenant gelten die Microsoft-Enterprise-Bedingungen: Ihre Daten werden nicht für das Trainieren von Modellen verwendet, sie bleiben in der gewählten Azure-Region. Tickets mit besonders sensiblem Inhalt (Personalsache, Gesundheitsdaten) lassen sich vor der KI-Verarbeitung filtern oder anonymisieren.
Brauchen wir dafür ein neues Ticket-System? Nein, wenn das vorhandene API- oder Webhook-fähig ist. Stellen Sie sich eine 100-Personen-Firma mit Jira Service Management oder Zammad vor — beides lässt sich anbinden, ohne das System auszutauschen. Wenn allerdings noch in einer geteilten Mailbox gearbeitet wird, ist das ein eigenes Vorgespräch wert: Erst Ticket-System, dann Triage-Automation.
Wie lange dauert es, bis sich das im Alltag bemerkbar macht? In den ersten 4–6 Wochen sind die Veränderungen klein und unter Beobachtung — bewusst. Spürbare Entlastung kommt typischerweise im zweiten bis dritten Monat, wenn der Klassifikator für die häufigsten Kategorien stabil läuft. Wer schon nach zwei Wochen „bahnbrechende Effizienz-Sprünge” verspricht, hat entweder kein Mensch-im-Loop oder kein realistisches Verständnis vom Mittelstand.