Summarizing Sysadmin Tickets
YAML--- name: summarizing-sysadmin-tickets description: Analyzes long sysadmin support tickets and extracts the core problem, required actions, and relevant technical details into a concise summary. Writes ticket comments and work log entries as terse bullet-point notes, and drafts professional emails to colleagues or customers based on ticket content. Use when a ticket description is too long to quickly act on, when documenting completed work on a ticket, or when a status update/email needs to be sent to a customer or colleague. --- # Summarizing Sysadmin Tickets
Paste the raw ticket text. Output three things depending on what's needed:
- Ticket Summary (what's wrong, what to do)
- Stichpunkte for the comment/worklog field
- Email draft (only if requested)
Example trigger: "Fass dieses Ticket zusammen: [langer Text]"
Progress:
- Read full ticket text, identify noise (greetings, repeated history, signatures, auto-replies)
- Extract: problem/symptom, affected system, priority/urgency signals, who reported it, what was already tried
- Produce short summary (max 5-8 lines) answering: "Was ist los? Was muss ich tun?"
- If asked for comment/worklog: convert actions into terse bullet points (Stichworte), not full sentences
- If asked for email: pick tone (colleague = informal/technical, customer = formal/clear) and draft short email
- Present output, ask if tone/length needs adjustment only if ambiguous
1. Ticket Summary
Strip boilerplate (Ticket-IDs, mail headers, "Mit freundlichen Grüßen", disclaimers). Keep:
- Symptom/Fehlerbild
- Betroffenes System/Service
- Seit wann / wie oft
- Bereits unternommene Schritte
- Dringlichkeit (explizit oder abgeleitet, z.B. "Produktivsystem down")
Format as:
Problem: ...
System: ...
Bisher versucht: ...
Nächster Schritt: ...
2. Stichpunkte für Kommentar/Leistung
Convert actions into fragment style, no full sentences, no subject pronouns:
- Server neu gestartet
- Logs geprüft (auth.log, syslog)
- Ursache: Speicherplatz voll (/var 100%)
- Alte Logs bereinigt, 15 GB freigegeben
- Monitoring-Schwelle angepasst
Use verbs in past participle or infinitive, one action per line, no filler words.
3. Email Draft
- Colleague: short, direct, technical jargon okay, no formal Anrede needed if context is chat-like, otherwise brief "Hi [Name],"
- Customer: formal Anrede ("Sehr geehrte/r..." or "Hallo Herr/Frau X,"), avoid technical jargon unless necessary, explain impact and resolution in plain language, close with next steps and formal Grußformel
Default structure for customer email:
Anrede,
kurze Bestätigung des Problems,
was wurde unternommen / ist der Status,
was ist der nächste Schritt (für Kunde oder für uns),
Grußformel
Example 1: Input: Langes Ticket mit Mail-Verlauf über VPN-Verbindungsabbrüche bei einem Mitarbeiter, inkl. mehrerer Zwischenantworten und Signaturen.
Output:
Problem: VPN-Verbindung bricht bei Mitarbeiter [Name] mehrfach täglich ab
System: Fortinet VPN Client, Windows 11 Notebook
Bisher versucht: Client neu installiert, keine Besserung
Nächster Schritt: Firewall-Logs auf Serverseite prüfen, MTU-Einstellung testen
Example 2: Input: "Fass das in Stichpunkte für den Leistungseintrag: Ich habe den Drucker neu eingerichtet, Treiber aktualisiert, Testdruck durchgeführt, Nutzer informiert."
Output:
- Drucker neu eingerichtet
- Treiber aktualisiert
- Testdruck durchgeführt
- Nutzer informiert
Example 3: Input: "Schreib dazu eine Email an den Kunden."
Output:
Sehr geehrte Frau Müller,
der gemeldete Druckerfehler wurde behoben. Der Treiber wurde aktualisiert
und ein Testdruck erfolgreich durchgeführt. Sie können den Drucker ab
sofort wieder normal nutzen.
Bei weiteren Problemen melden Sie sich gerne jederzeit.
Mit freundlichen Grüßen
[Name]
- Immer zuerst Problem, dann Lösung/Status, dann nächster Schritt – diese Reihenfolge einhalten
- Stichpunkte: keine Artikel/Füllwörter, max. 1 Zeile pro Punkt
- Bei unklarer Dringlichkeit nicht raten – im Summary als "Dringlichkeit unklar" kennzeichnen
- Kundenmails immer ohne interne Details (Servernamen, interne Tickets-IDs, Fehlercodes ohne Erklärung)
- Kollegen-Mails dürfen technische Details und Abkürzungen enthalten
- Wenn Ticket bereits kurz ist, keine unnötige Zusammenfassung erzwingen – direkt sagen "Ticket ist bereits kurz genug"
- Nicht die komplette Mail-Historie in die Zusammenfassung übernehmen
- Keine Vermutungen als Fakten darstellen (z.B. Ursache nicht erfunden, nur wenn im Text genannt)
- Stichpunkte nicht als ganze Sätze mit "Ich habe..." schreiben
- Kundenmails nicht zu technisch oder zu lang formulieren
- Nicht automatisch senden – immer nur Entwurf liefern, Versand macht der Admin selbst