Eine Claude Skill, die eine Kundeneskalation in eine belastbare Ursachenanalyse (RCA) verwandelt: eine rekonstruierte Timeline jeder Ticket-Berührung und jedes Calls, eine benannte Ursache, die von ihren beitragenden Faktoren getrennt ist, und einen Maßnahmenplan mit Verantwortlichen und Terminen. Sie liest den Zendesk-Ticket-Thread plus alle verknüpften Geschwister-Tickets sowie die Gong-Calls, die im Eskalationsfenster mit dem Account verbunden sind, und erzeugt dann ein einziges Markdown-RCA, das der CSM bearbeitet und der Support Lead freigibt, bevor es zum Kunden oder in ein internes Post-Incident-Review geht. Das Artifact-Bundle liefert die SKILL.md plus drei Referenzdateien, die das Team einmal anpasst und für jede Eskalation wiederverwendet.

Das Artifact-Bundle liegt unter apps/web/public/artifacts/escalation-rca-skill/. Es enthält SKILL.md, references/1-rca-template.md (das Output-Skelett mit benannten Abschnitten), references/2-cause-taxonomy.md (die feste Liste der Ursachenkategorien, in die die Skill klassifizieren muss) und references/3-sample-rca.md (ein anonymisiertes ausgearbeitetes Beispiel, das der Tone-Match-Durchlauf nachahmt). Lesen Sie alle drei vor dem ersten Lauf.

Wann zu verwenden

Sie sind ein CSM oder ein Support Lead, bei dem gerade ein Account eskaliert ist — ein Sev-1-Ausfall, über den der Kunde verärgert ist, eine Reihe schlecht behandelter Tickets, eine den Renewal bedrohende Beschwerde — und Sie brauchen schnell ein schriftliches RCA, vor dem Postmortem-Meeting oder dem Entschuldigungs-Call beim Kunden. Die Skill ist für den Fall gebaut, in dem die Belege über einen Zendesk-Thread, drei oder vier von verschiedenen Personen auf Kundenseite geöffnete Geschwister-Tickets und zwei oder drei Gong-Calls verstreut sind, in denen der Frust tatsächlich an die Oberfläche kam. Diese Timeline von Hand zusammenzusetzen sind 60 bis 120 Minuten Tab-Wechseln; die Skill übernimmt den Zusammenbau und reicht Ihnen einen Entwurf, über den Sie nachdenken können.

Sie erzeugt den nützlichsten Output, wenn die Zendesk-Tickets verknüpft sind (über den Account oder einen expliziten problem/incident-Link) und konsistent getaggt sind, und wenn mindestens ein Gong-Call im Fenster ein Transkript hat. Sie ist auf ein einzelnes Eskalationsereignis mit einem begrenzten Fenster kalibriert — typischerweise die 14 bis 30 Tage rund um den auslösenden Incident — nicht auf eine quartalslange Musteranalyse.

Wann NICHT zu verwenden

Senden Sie den Output der Skill nicht unbearbeitet an den Kunden. Es ist eine Entwurfs-Engine. Die Ursache ist eine Hypothese, die der CSM und der Support Lead anhand ihres eigenen Wissens bestätigen, bevor jemand mit seinem Namen unterschreibt. Ein RCA, das mit einer falschen Ursache an einen verärgerten Kunden geschickt wird, richtet mehr Schaden an als gar kein RCA.

Verwenden Sie sie nicht, wenn die Timeline weniger als drei Ereignisse hat. Mit einem Ticket und keinem Call gibt es nichts zu rekonstruieren, und die Skill ist gebaut, um insufficient data zurückzugeben, statt ein Narrativ zu erfinden — aber nur, wenn Sie diese Verweigerung respektieren, anstatt einen Lauf zu erzwingen. Ein selbstsicheres RCA, das auf zwei Data Points aufbaut, liest sich autoritativ und führt jeden in die Irre, der danach handelt.

Verwenden Sie sie nicht für rechtliche oder vertragliche Streitigkeiten, Post-Mortems von Sicherheitsvorfällen oder alles, was auf eine SLA-Gutschriftsverhandlung zusteuert, bei der die Formulierung adversarial ist. Die Skill schreibt ein operatives RCA in einem neutralen, verantwortungsvollen Register; sie schreibt keine belastbare juristische Sprache und wird Haftung auf eine Weise unter- oder überbewerten, die ins Gewicht fällt, wenn Geld oder Vertragsbedingungen auf dem Spiel stehen. Leiten Sie diese an das Team weiter, das sie besitzt.

Verwenden Sie sie nicht als Churn-Prädiktor oder als Health Score. Sie erklärt ein einzelnes vergangenes Ereignis. Der Composite-Health-Score-Workflow ist das auf vorausschauendes Retention-Risiko kalibrierte Werkzeug; die Schweregrad-Bewertung dieses RCA als Churn-Wahrscheinlichkeit zu lesen, wird Sie in die Irre führen.

Setup

Etwa 45 bis 60 Minuten beim ersten Mal, das meiste davon für die Anpassung der Cause Taxonomy in references/2-cause-taxonomy.md an die tatsächlichen Fehlermodi Ihres Teams.

Installieren Sie die Skill. Legen Sie das Bundle aus apps/web/public/artifacts/escalation-rca-skill/ in ~/.claude/skills/escalation-rca/ ab. Die Skill definiert einen einzigen Befehl, draft_rca(account_id, escalation_window, anchor_ticket_id), plus interne Helfer für den Zendesk-Pull, den Gong-Pull, den Timeline-Merge und die Zwei-Pass-Pipeline von Claude.
Verkabeln Sie die Credentials. Setzen Sie ZENDESK_SUBDOMAIN und ZENDESK_API_TOKEN (Lesezugriff auf Tickets, Ticket Comments und Ticket Audits — die Audits sind das, was Ihnen die Timestamps der Statusänderungen liefert) und GONG_API_KEY (Lesezugriff auf Calls und Transkripte). Die Skill schreibt in keines der beiden Systeme; sie ist per Design read-only, damit sie ohne Change-Control-Review gegen die Produktion laufen kann.
Passen Sie die Cause Taxonomy an. Öffnen Sie references/2-cause-taxonomy.md und ersetzen Sie die Platzhalter-Kategorien durch die echten Ihres Teams. Das Standardset ist product-defect, config-error, documentation-gap, process-breakdown, capacity-overload, communication-failure und third-party-dependency. Die Skill klassifiziert die Ursache in genau eine davon und listet den Rest als beitragende Faktoren auf, wo die Belege sie stützen; eine Freitext-Ursache ist der häufigste Grund, weshalb zwei RCAs desselben Incidents voneinander abweichen, daher ist die feste Taxonomy tragend, keine Dekoration.
Passen Sie das Template und das Voice-Sample an. Bearbeiten Sie references/1-rca-template.md so, dass die Abschnittsnamen dem entsprechen, was Ihr Postmortem-Prozess erwartet (manche Teams brauchen einen customer-impact-Abschnitt mit der Anzahl betroffener Nutzer; manche einen detection-Abschnitt). Ersetzen Sie das ausgearbeitete Beispiel in references/3-sample-rca.md durch zwei oder drei anonymisierte frühere RCAs, die Ihr Team geschrieben hat, damit der Tone-Match-Durchlauf Ihren Hausstil nachahmt statt des generischen Samples.
Führen Sie es für eine Eskalation aus. draft_rca(account_id="...", escalation_window="2026-05-20:2026-06-03", anchor_ticket_id="48213"). Die Skill schreibt eine Markdown-Datei: die rekonstruierte Timeline, den Ursachenabschnitt, die Liste der beitragenden Faktoren, die Maßnahmentabelle und eine kundengerichtete Zusammenfassung von einem Absatz, die der CSM übernehmen oder umschreiben kann.

Was die Skill tatsächlich tut

Die Skill pullt Zendesk und Gong parallel, weil sie unabhängige Systeme treffen und der Engpass die API-Latenz ist, nicht die Tokens von Claude. Aus Zendesk pullt sie das Anker-Ticket, jedes Geschwister-Ticket, das im Fenster mit demselben Account oder Problem verknüpft ist, und — entscheidend — das Audit-Log jedes Tickets, weil die Audits die Timestamps der Status- und Zuweisungsänderungen tragen, die der Kommentar-Thread allein nicht hat. Aus Gong pullt sie die Calls des Accounts im Fenster, begrenzt auf die sechs jüngsten, mit auf je 4.000 Zeichen gekürzten Transkripten. Wenn eines der Systeme leer zurückgibt, vermerkt die Skill den Gap in der Timeline, statt ihn zu füllen.

Anschließend fügt sie alles zu einer einzigen chronologischen Timeline zusammen, die auf UTC-Timestamps verschlüsselt ist. Der Merge ist ein deterministischer Schritt, kein Claude-Schritt, weil die Timestamp-Ordnung genau die Art von Sache ist, die ein Sprachmodell subtil falsch macht und ein Sort nicht. Jedes Ereignis trägt seine Quelle (zendesk-comment, zendesk-status-change, gong-call), seinen Akteur und eine einzeilige Zusammenfassung. Diese zusammengeführte Timeline ist das Rückgrat des gesamten RCA, und sie steht wörtlich im Output, damit der Leser jede nachgelagerte Behauptung daran prüfen kann.

Dann zwei Claude-Durchläufe. Durchlauf eins ist die Kausalanalyse: Claude liest die zusammengeführte Timeline und die Cause Taxonomy und erzeugt eine einzige benannte Ursache, eine getrennte Liste beitragender Faktoren und die spezifischen Timeline-Ereignisse, die jeden stützen. Die Ursache in einem dedizierten Durchlauf von den beitragenden Faktoren zu trennen ist wichtig, weil der häufigste RCA-Fehler darin besteht, die beiden zu verwechseln — das lauteste Symptom als Ursache zu bezeichnen. Der Durchlauf ist angewiesen, Timeline-Ereignisse für jede Kausalbehauptung per Timestamp zu zitieren und insufficient data zurückzugeben, falls weniger als drei Ereignisse im Fenster existieren.

Durchlauf zwei ist der Maßnahmenplan und der Tone-Match. Claude nimmt die bestätigte Ursache plus beitragende Faktoren und schlägt eine Maßnahmentabelle vor — jede Zeile eine Maßnahme, eine verantwortliche Rolle (keine benannte Person; das Team weist Namen zu), ein Fälligkeits-Offset und der beitragende Faktor, den sie schließt. Dann schreibt er das gesamte RCA in der Stimme des Teams um, unter Verwendung der Samples in references/3-sample-rca.md, und schreibt die kundengerichtete Zusammenfassung von einem Absatz in einem konservativeren Register, das Impact und Behebung benennt, ohne eine Haftung einzugestehen, die das Team nicht vereinbart hat. Maßnahmen und Ton in einen eigenen Durchlauf zu trennen hält das Kausal-Reasoning aus Durchlauf eins frei von der Abmilderung, die die kundengerichtete Zusammenfassung erfordert.

Kostenrealität

Ein vollständiger Lauf kostet auf Claude Sonnet etwa 15.000 bis 30.000 Input-Tokens und 2.000 bis 4.000 Output-Tokens — nennen wir es 6 bis 12 Cent pro RCA zu den aktuellen Sonnet-Preisen. Die dominierende Input-Variable ist das Volumen der Gong-Transkripte; ein stark eskalierter Account mit sechs protokollierten Calls im Fenster landet nahe der Obergrenze, eine reine Ticket-Eskalation ohne Calls nahe der Untergrenze. Das Zwei-Pass-Design teilt den Präfix-Kontext, daher ist der zweite Durchlauf günstiger als der erste.

Die Wanduhrzeit beträgt zwei bis vier Minuten, dominiert von den Audit-Log-Pulls von Zendesk (ein zusätzlicher API-Call pro Ticket) und dem Fetch der Gong-Transkripte. Die beiden Claude-Durchläufe fügen 40 bis 70 Sekunden hinzu, nachdem der parallele Pull abgeschlossen ist.

Ein CSM oder Support Lead, der ein RCA von Grund auf schreibt, verbringt typischerweise 60 bis 120 Minuten — Tickets pullen, Audits lesen, Calls erneut anhören, die Timeline rekonstruieren und dann schreiben. Die Skill bringt das auf 20 bis 35 Minuten Bearbeitung, die Ersparnis beträgt also rund eine Stunde pro Eskalation. Eine Support-Organisation mit 15 bis 25 formalen Eskalationen pro Quartal gewinnt 15 bis 25 Stunden Zeit von Senior-ICs zurück, und das ist der Punkt, an dem die Kosten am stärksten spürbar sind, weil Eskalationen bei den erfahrensten Leuten landen.

Wie Erfolg aussieht

Verfolgen Sie die Zeit von „Eskalation erklärt” bis „RCA zum internen Sign-off zirkuliert”. Die Skill sollte den Median im ersten Quartal der Nutzung unter 90 Minuten ziehen, gegenüber einer From-Scratch-Baseline von einem halben Tag oder mehr. Verfolgen Sie auch die Rate, mit der die vorgeschlagene Ursache das Review des Support Lead unverändert übersteht — zielen Sie auf 60 % oder mehr. Niedriger und die Cause Taxonomy muss neu geschnitten werden, damit sie zu der Art passt, wie Ihre Incidents tatsächlich scheitern; höher als 85 % und der Lead stempelt wahrscheinlich ab, statt zu prüfen, was die Human-in-the-Loop-Garde aushebelt.

Eine zweite Zahl, die es wert ist, beobachtet zu werden: der Anteil der Maßnahmen aus vergangenen RCAs, die tatsächlich zu ihrem Fälligkeitstermin geschlossen wurden. Die Skill erzwingt das nicht — sie schlägt die Maßnahmen nur vor — aber wenn dieser Anteil unter 50 % bleibt, ist der RCA-Prozess Theater, und eine schnellere Entwurfs-Engine wird das nicht beheben. Die Metrik sagt Ihnen, ob die Organisation auf Ursachen reagiert oder sie nur dokumentiert.

Gegenüber den Alternativen

Gegenüber einem manuellen RCA in einem Google Doc. Der Status quo der meisten Teams. Manuelle RCAs sind von höherer Treue, wenn der Autor persönlich im Loop des Incidents war, weil sie Kontext tragen, den die Systeme nie aufgezeichnet haben — den Slack-Thread, das Flurgespräch, das Bauchgefühl zur echten Beschwerde des Kunden. Der Kompromiss ist die gut eine Stunde Timeline-Zusammenbau, der reine mechanische Plackerei ist, die die Skill eliminiert. Verwenden Sie manuell für die seltene Eskalation auf Board-Ebene, bei der jedes Wort gewogen wird; verwenden Sie die Skill für das stetige Volumen operativer Eskalationen, bei denen die Beschränkung die Zeit von Senior-ICs ist, nicht die erzählerische Handwerkskunst. Selbst für den Board-Fall ist die rekonstruierte Timeline der Skill ein nützliches Start-Artifact.

Gegenüber den nativen Ticket-Merge- und Side-Conversation-Funktionen von Zendesk. Zendesk kann verwandte Tickets verknüpfen und mergen und eine vereinheitlichte Ansicht aufzeigen, und wenn alles, was Sie brauchen, die konsolidierte Ticket-Historie ist, ist das weniger Aufwand als eine Skill zu installieren. Aber Zendesk zeigt die Tickets auf; es rekonstruiert keine systemübergreifende Timeline, die Gong-Calls einschließt, und es benennt keine Ursache und schlägt keine Maßnahmen vor. Es gibt Ihnen das Rohmaterial; die Skill schreibt die Analyse. Verwenden Sie das Linking von Zendesk, um die Geschwister-Tickets auffindbar zu halten — die Skill stützt sich auf dieses Linking, um sie zu finden — und die Skill, um das verknüpfte Set in ein RCA zu verwandeln.

Gegenüber einem dedizierten Incident-Management-Tool (einem incident.io oder einem FireHydrant). Diese sind exzellent für engineering-geführte Incident-Response mit On-Call-Rotationen, Status Pages und automatisiertem Postmortem-Gerüst. Wenn Ihre Eskalationen Infrastruktur-Incidents sind und Sie bereits eines betreiben, verwenden Sie dessen Postmortem-Flow. Aber diese Tools sind rund um den Engineering-Incident-Lebenszyklus gebaut, nicht den der Kundenbeziehung; sie lesen Ihre Gong-Calls nicht und schreiben nicht in der kundengerichteten Stimme Ihres CSM-Teams. Für eine vom CS verantwortete Eskalation, bei der es ebenso um eine Beziehung wie um einen Defekt geht, passt diese Skill in die Naht, die diese Tools offen lassen.

Worauf zu achten ist

Rückschaufehler im Kausal-Durchlauf. Eine Timeline rückwärts von einem bekannt schlechten Ergebnis zu lesen lässt jede frühere Entscheidung wie einen offensichtlichen Fehler erscheinen, und Claude wird sie ohne Garde so erzählen. Garde: Durchlauf eins ist angewiesen, das zu jedem Ereignis Wissbare von dem zu unterscheiden, was nur im Rückblick wissbar ist, und jede Behauptung zu markieren, die vom Rückblick abhängt. Sie gibt außerdem insufficient data zurück, statt zu raten, wenn weniger als drei Timeline-Ereignisse im Fenster existieren — kein Narrativ wird auf einem Fundament gebaut, das zu dünn ist, um eines zu tragen.
Fehlende Audit-Logs lassen die Timeline kollabieren. Wenn dem Zendesk-Token der Audit-Lesescope fehlt, erhält die Skill stillschweigend Kommentare ohne Statusänderungs-Timestamps, und die Timeline verliert die Ereignisse „das Ticket lag neun Tage in pending”, die oft die eigentliche Geschichte sind. Garde: die Skill prüft den Audit-Zugriff auf das Anker-Ticket während der Setup-Verifikation und verweigert den Lauf mit einem ZENDESK_AUDIT_SCOPE_MISSING-Fehler, statt eine Timeline zu erzeugen, die die wichtigsten Ereignisse auslässt.
Ursache mit dem lautesten Symptom verwechselt. Das Ereignis, über das sich der Kunde am meisten beschwert hat, ist selten die Ursache; es ist meist ein nachgelagertes Symptom. Ein Modell ohne Garde verankert sich am Volumen. Garde: die Cause Taxonomy in references/2-cause-taxonomy.md erzwingt eine einzige klassifizierte Kategorie, und Durchlauf eins muss das spezifische Timeline-Ereignis zitieren, das der früheste Punkt ist, an dem die Ursache im Spiel war — nicht das lauteste, das früheste. Symptome, die später kamen, werden als beitragende Faktoren abgelegt.
Gong-Sentiment auf dünnen Transkripten überinterpretiert. Ein einzelner kurzer Call wird als „der Kunde ist wütend” überbewertet, wenn das Transkript eine 90-Sekunden-Voicemail ist. Garde: die Skill begrenzt den Einfluss von Gong im Kausal-Durchlauf auf bestätigende Belege — ein Call kann ein Timeline-Ereignis stützen, kann aber nicht für sich allein die benannte Ursache sein, weil eine aufgezeichnete Beschwerde ein Symptom ist, keine Ursache. Transkripte unter 200 Wörtern werden als geringe Konfidenz markiert und aus der Sentiment-Lesung ausgeschlossen.
Kundengerichtete Zusammenfassung gesteht eine Haftung ein, die das Team nicht vereinbart hat. Durchlauf zwei schreibt eine Zusammenfassung, die der Kunde lesen kann, und ein LLM, das seinem eigenen Register überlassen wird, entschuldigt sich für Dinge, die das Unternehmen nicht zu verantworten beschlossen hat. Garde: der Prompt der kundengerichteten Zusammenfassung benennt nur Impact und Behebung, verbietet ausdrücklich, Schuld zuzuweisen oder Kompensation zu versprechen, und stellt dem Absatz einen REVIEW BEFORE SENDING-Marker voran, den der CSM von Hand entfernen muss — es gibt keinen Pfad, auf dem kundengerichteter Text die Skill ohne menschliche Berührung verlässt.

Stack

Zendesk — Ticket-Thread, Geschwister-Tickets und die Audit-Logs, die die Statusänderungs-Timestamps tragen (REST API, read-only)
Gong — Transkripte und Metadata der Calls des Accounts im Eskalationsfenster (Gong API, read-only)
Claude — Zwei-Pass-Analyse: Kausalanalyse gegen die Taxonomy, dann Maßnahmenplan plus Tone-Match (Sonnet aus Kostengründen empfohlen; Opus nur, wenn die kundengerichtete Zusammenfassung ungewöhnliche Sensibilität trägt)

Diese Seite auf GitHub bearbeiten