Use Case · KI Studio
Hersteller-Hinweise zu Tickets
Die Mail, die jeder bekommt und keiner bearbeitet: Aus End-of-Life-, Wartungs- und Abkündigungshinweisen der Hersteller werden geprüfte Tickets im eigenen Ticketsystem, mit Frist, Priorität und Zuständigkeit.
01 · Auftrag
Der Engpass ist nicht die Entscheidung, sondern der Weg dorthin.
Jeder Betrieb kennt diese Mail. Ein Hersteller kündigt eine Version ab, ein Zertifikat läuft aus, eine Prüffrist rückt näher. Die Mail ist höflich, nennt ein Datum weit in der Zukunft und verlangt nichts Konkretes. Man liest sie, findet sie wichtig, und bearbeitet sie nicht. Denn zwischen „das müssten wir mal angehen“ und einer Aufgabe, die jemand anpacken kann, liegt eine halbe Stunde Recherche, die vormittags niemand übrig hat.
Wer in DevOps arbeitet, kennt das im Wochentakt. Ob überhaupt etwas zu tun ist, steht in der Mail nicht. Also klickt man sich durch Konsolen und Kontolisten und stellt nach einer Viertelstunde fest: Das betroffene System ist ein Altbestand, den seit zwei Jahren niemand mehr anfasst. Nichts zu tun. Die Viertelstunde ist trotzdem weg.
Der Auftrag, so wie er im eigenen Betrieb an einem Morgen um 09:12 Uhr hereinkam, ein Satz, Tippfehler inklusive: „diese Tage kommen immer wieder E-Mails von unserem Hosting-Anbieter rein, bezüglich umzustellender Produkte wegen End of Life. Gibt es dazu schon Tickets? Wenn nicht bitte entsprechend anlegen.“ Kein System genannt, keine Frist, kein Empfänger, kein Wort dazu, wo die Tickets hingehören. Der Agent hat trotzdem keine Rückfrage gestellt.
02 · Was das Team tut
Was in den sechs Minuten passierte.
Das Postfach sortiert
Der Agent hat die Mails der letzten vier Monate durchgesehen und die relevanten vollständig gelesen. Dabei kam heraus: Es geht nicht um ein Thema, sondern um vier. Plattform-Stack, Cache-Dienst, Datenbank und Nachrichten-Cluster, jedes mit eigener Frist.
Im Ticketsystem nachgesehen, was es schon gibt
Mehrere Suchbegriffe, offene und geschlossene Tickets, Jahre zurück. Ein Thema war längst erfasst und in Arbeit. Dieses Ticket hat er komplett gelesen, samt aller Kommentare, um zu wissen, wo die Sache steht und wer sie macht, statt ein zweites danebenzustellen.
Beim Hosting nachgesehen, was wirklich läuft
Über die Schnittstelle des Anbieters hat er sich alle Anwendungen auflisten lassen und für die betroffenen die Erweiterungen und Tarife geprüft. An die Versionsnummern kam er nicht heran, das durfte sein Zugang nicht lesen. Also stehen sie im Ticket als das, was sie sind: Angaben aus der Mail, mit dem Befehl daneben, mit dem der Bearbeiter sie in zehn Sekunden selbst prüft.
Gesagt, wer was tun muss
Aus alten Tickets wusste er, was auf der kritischsten Instanz läuft: eine Echtzeit-Anzeige, an der bei zahlenden Kunden Umsatz hängt. Deshalb steht im Ticket nicht „Zwangs-Upgrade droht“, sondern was ein unangekündigter Neustart mitten am Tag anrichtet. Drei Personen hat er angesprochen, jede mit dem, was von ihr gebraucht wird: Entscheidung über das Wartungsfenster, Umsetzung im eigenen Bereich, Kenntnisnahme für die Planung.
03 · Ablauf
Wie der Agent vorgeht.
Vier Minuten bis zum ersten fertigen Ticket, sechs Minuten bis zur vollständigen Rückmeldung. Drei Minuten später hatte die Teamleitung das Ticket an den Zuständigen weitergegeben, ohne eine einzige Rückfrage. Daran misst sich, ob eine Zuarbeit etwas taugt.
Schritt 01
Lesen
Postfach durchsehen, Themen und Fristen aus den Mails ziehen.
Schritt 02
Abgleichen
Ticket-Historie prüfen: Was ist schon erfasst, in Arbeit oder erledigt?
Schritt 03
Prüfen
Laufende Anlage über die Schnittstelle des Anbieters gegenlesen: Was ist tatsächlich betroffen?
Schritt 04
Anlegen
Ticket mit Frist, Priorität, Zuständigkeit und Begründung. Oder begründet kein Ticket.
04 · Aus der Praxis
Zwei Tickets, die er nicht geschrieben hat, und ein Fehler, den er selbst meldete.
Der Nachrichten-Cluster brauchte kein Ticket.
Vier Themen, aber nur zwei neue Tickets. Eines gab es schon. Und beim vierten zeigte der Blick in die laufende Anlage: Der Anbieter hatte die Version längst selbst angehoben, der Cluster läuft. Also kein Ticket, mit Begründung. Das ist der Unterschied zwischen einem Automatismus, der pro Mail ein Ticket erzeugt, und einer Zuarbeit, der man glaubt.
Die Lücke hat er gemeldet, nicht gefüllt.
In dem bestehenden Ticket stand, dass drei Anwendungen ausdrücklich an ein anderes Team verwiesen wurden. Ob dieses Team ein Ticket dafür hat, konnte er nicht sehen, in dessen Projekt darf er nicht hinein. Genau das hat er dazugeschrieben, statt die Lücke größer zu machen, als er sie belegen kann. Angelegt hat er nichts, sondern gefragt.
Der Fehler, den er selbst gemeldet hat.
Bei einem der beiden Tickets sollte er den Bearbeiter nachträglich eintragen. Das Ticketsystem quittierte den Schreibvorgang zweimal mit „erfolgreich“ und tat nichts. Weil er nach jedem Schreibvorgang nachliest und vergleicht, ist es aufgefallen. In seiner Rückmeldung stand deshalb nicht „erledigt“, sondern: Hat nicht gegriffen, bitte von Hand nachtragen.
05 · Ergebnis
Was dabei herauskam.
Aus einem Postfach voller höflicher Mails wird ein Backlog mit datierten Fristen, gesetzter Priorität und benannten Zuständigen. Die Entscheidung fällt auf geprüften Angaben statt auf einer überflogenen Mail.
Prüfbar ist der Weg, nicht nur das Ergebnis: Wo kein Ticket geschrieben wurde, steht die Begründung dabei, ein verlinktes Ticket oder ein Blick in die laufende Anlage.
- Themen und Fristen aus den Mails gezogen, gegen die Ticket-Historie abgeglichen.
- Nur dort ein Ticket, wo wirklich etwas zu tun ist, mit Begründung.
- Zuständigkeiten aus der Historie abgeleitet, Empfänger direkt angesprochen.
- Eigene Fehler gemeldet statt „erledigt“ gemeldet.
06 · Systeme und Rechtestufen
Welche Zugänge dafür nötig waren.
Ein einziger Zugang darf schreiben, und der steht auf der niedrigsten Stufe, die die Aufgabe zulässt. An den Systemen selbst wurde nichts ausgerollt, nichts umkonfiguriert und keine Mail verschickt.
| System | Wofür | Rechtestufe |
|---|---|---|
| Postfach | Hersteller-Hinweise finden und lesen | nur lesen |
| Hosting-Anbieter | Anwendungen, Erweiterungen, Tarife | nur lesen · Versionsdaten nicht einsehbar |
| Ticketsystem, lesend | Ticket-Historie, Zuständigkeiten, Querverweise | nur lesen |
| Ticketsystem, schreibend | Tickets und Kommentare anlegen, mit Labels, Status, Bearbeiter | Gast-Rolle, nur dieses eine Projekt · kein Code, kein Deploy |
| Eigener Arbeitsbereich | Hilfsskripte und Notizen | schreiben nur dort, nichts in Produktivsystemen |
07 · Grenzen
Wo die Grenzen liegen.
Der Agent hat die Sache aufbereitet, nicht gelöst. Die betroffenen Instanzen laufen bis zum Wartungsfenster weiter. Aber sie laufen jetzt sichtbar: Die Fristen stehen datiert im Ticket, die Priorität ist gesetzt. Damit liegt die Sache im Backlog statt in einem Postfach.
Das ist ein Fall, keine Quote. Er war für einen Agenten günstig geschnitten: Quellen maschinell lesbar, Fristen im Klartext, eine Ticket-Historie, aus der sich Zuständigkeiten ableiten ließen. Wo das Wissen nur in Köpfen steckt, kommt bei gleichem Vorgehen deutlich weniger heraus.
Daraus folgt: Wer Ticket-Historie, Zuständigkeiten und Fristen schriftlich führt, macht seinen Betrieb überhaupt erst auswertbar. Und ein Durchlauf, der sechs Minuten dauert, gehört nicht auf Zuruf, sondern in den Kalender: einmal die Woche, über alle Postfächer, in denen solche Mails auflaufen.
Häufige Fragen
Häufige Fragen zu diesem Use Case.
Funktioniert das auch mit Mails anderer Anbieter, etwa zu Zertifikaten oder Cloud-Diensten?
Ja. Das Vorgehen ist unabhängig vom Absender: Mails lesen, Themen und Fristen extrahieren, gegen Ticket-Historie und laufende Anlage abgleichen, Ticket anlegen oder begründet nicht. Der Zuschnitt auf Ihre Anbieter ist Teil des Piloten.
Läuft das automatisch?
Im ersten Schritt auf Zuruf, im zweiten zeitgesteuert: einmal die Woche über alle Postfächer, in denen solche Mails auflaufen. Dann lautet die Frage nicht mehr, ob jemand die Mail gelesen hat, sondern nur noch, ob das Ticket stimmt.
Was braucht der Agent dafür?
Lesezugriff auf das Postfach und die Anlage beim Anbieter, Lese- und eingeschränkten Schreibzugriff auf das Ticketsystem. Jedes maschinell erzeugte Ticket trägt in der ersten Zeile den Menschen, der es ausgelöst hat.
Weitere Use Cases
Verwandte Anwendungsfälle.
Marketing
Performance-Marketing end-to-end. Analyse, Kreation und Ausrollung in einem System, Mensch am Gate.
Energie-Management
Lastspitzen erkennen, Verbrauch verstehen, Kosten steuern, bevor sie auf der Rechnung stehen.
Finanzen & Controlling
Konsolidierte Abschlüsse, automatischer Zahlungsabgleich und Liquiditäts-Frühwarnung, auf Knopfdruck.
Klingt nach Ihrer Situation?
Im ersten Gespräch schauen wir gemeinsam auf Ihre Prozesse und skizzieren, wo ein Agenten-Team den größten Unterschied macht. Kostenfrei und unverbindlich.