Tickets selbst lösen:
7 Phasen und ein Prompt für KI-Agenten

KI-Agent löst Tickets

7 Phasen, 1 Prompt

Foto: erwinbosman / Pixabay

Ein Backup-Laufwerk mit 1,9 TB läuft zum zweiten Mal voll, obwohl jemand aufgeräumt hat. Das Symptom war weg, die Ursache blieb. Sieben Phasen und zwei Prompts helfen, beides zu trennen.

Auf einen Blick

• Wissen steckt in Tickets, Anleitungen und Köpfen. Ein KI-Agent im Ticketsystem liest Ticket, Kommentare, Anhänge und verlinkte Dokumente und strukturiert sie.
• Der erste Prompt führt Techniker in sieben Phasen zur Lösung. Das Muster lautet: erst messen, dann handeln.
• Der zweite Prompt erzeugt für Teamleiter eine eigenständige HTML-Datei. Sie lässt sich per Mail, Ticketkommentar oder Wiki weitergeben und druckt auf A4.
• Der Mensch bleibt in der Schleife. Er prüft, führt aus und kontrolliert. Der Agent entscheidet nichts.

Das Problem: Wer vermutet, behebt das Symptom

Bei einer Aufgabe, die jemand zum ersten Mal macht, fehlt oft das Wissen. Es steckt in alten Tickets, in Installationsanleitungen und in Köpfen. Ein Beispiel ist die jährliche DNS-Domainvalidierung für einen Dienst zur Mailverschlüsselung. Wer sie nur einmal pro Jahr erledigt, sucht jedes Mal von vorn.

Dabei gibt es ein zweites, gefährlicheres Muster. Ein Backup-Laufwerk läuft voll, das Team räumt es auf, und ein paar Tage später ist es wieder voll. Wer vermutet statt misst, bekämpft das Symptom. Die Messung im Beispiel zeigte, dass 1,9 TB Platz nicht reichen, weil täglich 120 bis 190 GB unkomprimiert anfallen. Das ergibt 142 % der Kapazität bei 21 Tagen Aufbewahrung. Der Cleanup lief korrekt, die Ursache war die Datenmenge.

Die Architektur in vier Teilen

1. Ein KI-Agent im Ticketsystem liest Ticket, Kommentare, Anhänge und verlinkte Anleitungen.
2. Ein Prompt legt Rolle, Aufbau und Regeln fest.
3. Das Ergebnis ist eine eigenständige HTML-Datei mit Inline-CSS, ohne externe Ressourcen.
4. Human in the Loop: Der Techniker prüft, führt aus und kontrolliert.

Dafür sind die Voraussetzungen bescheiden. Der Agent braucht Lesezugriff auf das Ticketsystem, das Ticket eine saubere Beschreibung und die Referenzanleitung einen Verweis. Für Skripte genügt ein RMM-Editor oder die Ausführung direkt auf dem Zielserver. Geheimwerte gehören nie in den Prompt, nur ein Verweis auf den Passwort-Tresor.

Teil A: Techniker lösen ein Ticket in sieben Phasen

Der Prompt kennt sieben Phasen. Jede hat eine Leitfrage, und das Backup-Beispiel zeigt, wie die Antworten aussehen.

Damit ist die Tabelle der Kern. Phase 2 verhindert, dass jemand eine Vermutung als Ursache behandelt: Jede Annahme wird gelistet und als bestätigt oder widerlegt markiert. Der Prompt dafür lautet:

Begleite mich bei Ticket {{TICKETNUMMER}} nach dem 7-Phasen-Vorgehen.
Arbeite Phase für Phase, frage nach, wenn Fakten fehlen, und erfinde nichts.

1. Überblick: Ausgangslage und messbares Ziel (z. B. „21 Tage Aufbewahrung, tägliche Überwachung“).
2. Befunde und Zahlen: Fakten statt Annahmen. Liste jede Annahme und wie wir sie geprüft
   (bestätigt / widerlegt) haben.
3. Funktionsweise: Lösung so beschreiben, dass ein Kollege sie versteht.
4. Auswertung: wie werden Ergebnisse sichtbar (Abfrage, Report, Monitoring-Sensor)?
5. Installation: Schritt für Schritt, wiederholbar, mit Testlauf und typischen Fehlern.
6. Konfiguration: alle Schwellenwerte zentral, Formeln offengelegt, Beispielrechnung.
7. Stand und To-do: getrennt in Erledigt / Zu prüfen (wir kontrollieren selbst) / Offen
   (Entscheid beim Auftraggeber). Grenzen offen benennen.

Ausgabe: eine HTML-Dokumentation mit diesen 7 Kapiteln plus Kurzfassung
„Ablauf und Lernnotiz“.

Zudem begleiten vier Leitsätze aus der Praxis den Prompt: Erst messen, dann handeln. Deaktivieren ist umkehrbar, Löschen nicht. Erst die Ursache klären, dann bereinigen. Dokumentieren, solange es frisch ist. Die Ergebnisse hängt der Techniker als HTML ans Ticket.

Teil B: Teamleiter erklären einem Techniker ein Ticket

Der zweite Prompt dreht die Rolle um. Ein Teamleiter will einem Techniker ein Ticket verständlich erklären, etwa die jährliche Domainvalidierung. Dafür sucht er Ticketnummer und Referenzdokument heraus, füllt die Platzhalter und lässt den Agenten die Unterlage bauen. Der Aufbau ist fest:

1. Kopfbereich mit Titel, Ticket, Kunde, Zweck in einem Satz, Techniker und Referenzdokument mit Version und Kapitel.
2. Hintergrund: warum, wer fordert an, welche Frist gilt.
3. Sollwerte als Code-Liste mit einem «Achtung»-Kasten für typische Tippfehler.
4. Ein kommentiertes PowerShell-Skript in nummerierten Schritten.
5. Eine Hinweistabelle mit Quelle des Schlüssels, Nebenwirkungen, Standardwerten und Frist.
6. Eine Checkliste zum Abschluss.
7. Fusszeile mit Referenz und Datum.

So halten zwei Regeln im Prompt die Qualität hoch. Geheimwerte erscheinen nur als Platzhalter wie HIER_KEY_EINFUEGEN. Fehlt im Ticket etwas, steht dort «im Ticket nicht belegt, prüfen», statt dass der Agent einen Wert erfindet.

Du bist IT-Trainer für Service-Techniker.
Lies das Ticket {{TICKETNUMMER}} inklusive aller Kommentare und Anhänge
und das Referenzdokument {{REFERENZDOKUMENT}} (Kapitel {{KAPITEL}}).

Erstelle daraus eine Schulungsunterlage als EINE eigenständige HTML-Datei
(inline CSS, keine externen Ressourcen, druckbar auf A4).

Sprache: Deutsch (Schweiz, ss statt ß), kurz, praxisnah, für einen Techniker,
der das Thema zum ersten Mal macht. Nur Fakten aus Ticket und Referenzdokument.
Wenn etwas fehlt, als „(im Ticket nicht belegt, prüfen)“ markieren.

Dazu ergänzt die Variante für Teamleiter am Anfang einen Abschnitt «Was du danach kannst» mit drei Punkten und am Ende «Typische Fehler» mit höchstens fünf Einträgen. Das Ergebnis speichert er als .html, öffnet es im Browser und liest es fachlich gegen, vor allem die Löschschritte. Danach geht es per Mail an den Techniker, eine Kopie landet im Ticketkommentar.

Das Lehrstück: Ein Befehl, der zu viel löscht

Deshalb ist das Gegenlesen keine Förmlichkeit. Ein typischer Schritt bei der DNS-Validierung lautet dnscmd /recorddelete <Zone> "@" TXT /f. Er löscht alle TXT-Records der Zone, auch den SPF-Eintrag. Wer ihn blind ausführt, legt den Mailversand lahm. Der Prompt verlangt deshalb Warnkommentare an gefährlichen Schritten und den Hinweis, was vorher zu prüfen ist. Wie ein SPF-Eintrag zusammen mit DKIM und DMARC wirkt, beschreibt der Artikel DMARC in der Praxis: Versandquellen finden vor dem Reject.

Typische Fehler

• Pauschales Löschen: Befehle mit /f lassen sich nicht rückgängig machen. Vorher prüfen, was betroffen ist.
• Geheimwerte im Prompt oder im Ticketkommentar: Sie gehören in den Tresor.
• Dünnes Ticket: Der Agent füllt Lücken mit Annahmen. Die Regel «nicht belegt, prüfen» muss im Prompt bleiben.
• Nur das Symptom behoben: Phase 2 wurde übersprungen.

Grenzen

Dabei sieht der Agent nur, was im Ticket und in den verlinkten Dokumenten steht. Die Verantwortung bleibt beim Techniker. Die Prompts sind ein Startpunkt und müssen an den eigenen Agenten angepasst werden. Wie sich mehrere Agenten sinnvoll organisieren lassen, beschreibt der Artikel KI-Sub-Agenten orchestrieren.

Einordnung: Was das für Service-Teams und IT-Dienstleister heisst

So verkürzt die Schulungsunterlage für Teamleiter die Einarbeitung bei seltenen Aufgaben von Stunden auf Minuten, solange das Ticket gut gepflegt ist. Zudem gewinnen Techniker eine Struktur, die sie auch ohne KI nutzen können: Ziel, Fakten, Lösung, Auswertung, Installation, Konfiguration, Stand. Der Nutzen liegt weniger im Tempo als in der Qualität der Entscheidung, denn die sieben Phasen zwingen zu Messungen vor jeder Massnahme. Planen solltest du Zeit für das fachliche Gegenlesen ein. Ohne diesen Schritt wandert ein Fehler des Agenten ungeprüft in die Praxis.

Fazit

Ein KI-Agent im Ticketsystem macht aus verstreutem Wissen eine strukturierte Lösung und eine druckbare Schulungsunterlage. Die sieben Phasen sorgen dafür, dass Messungen vor Massnahmen stehen. Der Mensch liest gegen, führt aus und bleibt verantwortlich. Probiere die beiden Prompts an einem abgeschlossenen Ticket aus und vergleiche das Ergebnis mit der damaligen Lösung.

Quellen: Prompts und Beispiele aus eigener Praxis, gekürzt und anonymisiert. Microsoft Learn zu dnscmd, Atlassian Jira Dokumentation. Zuletzt geprüft: 24. Oktober 2026.

Geschrieben von Andreas Brauckmann