Einrichtung
Ein Plugin ausprobieren
Das Operations-Plugin wird mit /runbook und /status-report als Ausgangspunkt geliefert, bereits so strukturiert, dass es durch einen War Room führt und die Kundenauswirkung einordnet. In Schritt 3 speicherst du deine eigene Version als /incident-review. Wenn dein Admin Plugins verwaltet und es noch nicht verfügbar ist, überspringe dies; nichts im Folgenden erfordert es.
/runbookCreate or update an operational runbook for a recurring task or procedure./status-reportGenerate a status report with KPIs, risks, and action items.Verbinde deine Tools
Claude Cowork ist leistungsfähiger, wenn es direkt mit deinen Systemen arbeitet. Du kontrollierst Berechtigungen und Zugriff. Erfahre mehr über den Tool-Zugriff(öffnet in neuem Tab).
Navigiere in Cowork zu Customize → Connectors, um die Einrichtung vorzunehmen.
Richte deinen Arbeitsordner ein
Ziehe die Dateien, die du verwenden wirst (deine Kunden-Postmortem-Vorlage, einen Export des War Rooms, die Ticket-CSV), in einen Ordner und richte Cowork darauf aus. Cowork liest die Vorlage von dort und schreibt den Entwurf, die Liste der betroffenen Kunden und den Abhilfe-Tracker zurück dorthin. Erstelle ein Cowork-Projekt(öffnet in neuem Tab) aus deinem Incident-Reviews-Ordner, damit die Vorlage, der Tonfall-Leitfaden und die SLA-Definitionen verknüpft bleiben.
Der Prompt
Kopiere dies in Claude Cowork
Entwerfe den kundenseitigen Incident-Review für INC-4417. Ziehe den War-Room-Thread, Tickets aus dem Auswirkungsfenster, Deploys der vorangegangenen 24 Stunden und direkte Kundenzitate. Rekonstruiere die Zeitleiste, quantifiziere, wie viele Kunden betroffen waren und für wie lange, und schreibe den ersten Entwurf in unserer Vorlage mit empfohlenen Verantwortlichen für Abhilfemaßnahmen.
Warum das funktioniert
Nenne die Zielgruppe von Anfang an. Der Ton ändert sich; dies ist das Dokument, das deine CSMs weiterleiten, nicht das Engineering-Retro.
Quantifiziere die Auswirkung. „Wie viele, für wie lange" erzwingt eine Zahl, die du in das Gespräch über SLA-Gutschriften einbringen kannst.
Frage nach direkten Zitaten. Die Stimme der betroffenen Kunden ist der Teil, auf den die Führungsebene achtet; frage explizit danach.
Lege einen Zeitraum fest. Tickets und Deploys werden durch die Zeitstempel des Incidents begrenzt, sodass die Liste der Verdächtigen kurz und relevant bleibt.
Einen besseren Entwurf erhalten
Trenne Internes von Externem. Füge hinzu: „Schreibe einen internen Anhang mit den verdächtigen Deploys; beschränke das Kundendokument auf Auswirkung und Abhilfe", damit ein Durchlauf beides erzeugt.
Füge ein passendes Beispiel hinzu. Lege einen früheren Review, auf den du stolz warst, in den Ordner, und Cowork passt die Struktur und den Entschuldigungston an, den deine Marke verwendet.
Lass Cowork für dich arbeiten
Ein Plugin-Skill ist ein Ausgangspunkt — passe ihn mit deinen eigenen Praktiken und deinem Fachwissen an. Ein paar Minuten Unterhaltung, und er läuft von da an nach deinen Standards.
Mache das, was wir in dieser Aufgabe bisher gemacht haben, zu einem Skill, oder bearbeite den Skill /incident-review mit meinem Feedback.
Mach es wiederholbar
Führe es aus, wenn der War Room geschlossen wird
Das Kundendokument sollte existieren, bevor der erste CSM danach fragt. Gib /schedule im Prompt ein, oder öffne Scheduled in der Cowork-Seitenleiste, und der angepasste Skill achtet auf geschlossene War Rooms und schreibt den ersten Entwurf.
/schedule Prüfe jeden Wochentag um 9 Uhr, ob ein #inc--Channel in den letzten 24 Stunden als gelöst markiert wurde, führe /incident-review darauf aus und schreibe den Entwurf nach Support/Incidents/<incident-id>/customer-review.md.
Täglich um 9 Uhr werden War Rooms gefunden, die in den letzten 24 Stunden gelöst wurden, /incident-review wird auf jeden davon ausgeführt, und der kundenseitige Entwurf wird in den Incident-Ordner geschrieben.
Teile es mit deinen Teammitgliedern
Dein angepasstes /incident-review trägt jetzt deine Vorlage, deinen Tonfall-Leitfaden und deine SLA-Gutschrift-Formulierungen. Teile es, damit jeder Incident das gleiche Kundendokument erhält, egal welcher Support-Lead im Dienst war.
Was sich nach einem Incident ändert
Der kundenseitige Incident-Review wird aus dem Quelldatensatz entworfen, mit quantifizierter Auswirkung und zugewiesener Abhilfe — bereit zum Bearbeiten und Versenden, statt von Grund auf geschrieben zu werden.
Du hast das für einen Incident gemacht. Der gleiche Ansatz deckt interne Retros, Status-Page-Updates und SLA-Gutschrift-Zusammenfassungen ab — jeder davon wird zu einem Skill, den dein Team auf die gleiche Weise ausführt.
Weiter: Verwandle den Thread in ein Entscheidungsdokument(öffnet in neuem Tab)