顧客のエスカレーションを擁護可能な根本原因分析 (RCA) に変える Claude Skill です。すべてのチケット対応とコールを再構築したタイムライン、寄与要因から切り分けて名指しした根本原因、担当者と日付を伴う是正アクション計画を生成します。Zendesk のチケットスレッドに加え、リンクされた兄弟チケットと、エスカレーションの期間内にそのアカウントに紐づく Gong のコールを読み込み、CSM が編集し support lead が承認してから顧客または社内のポストインシデントレビューに回す単一の Markdown RCA を生成します。artifact バンドルには SKILL.md と、チームが一度適応させればすべてのエスカレーションで再利用できる 3 つのリファレンスファイルが含まれます。
artifact バンドルは apps/web/public/artifacts/escalation-rca-skill/ にあります。SKILL.md、references/1-rca-template.md (名前付きセクションを持つ output のスケルトン)、references/2-cause-taxonomy.md (Skill が分類すべき根本原因カテゴリの固定リスト)、references/3-sample-rca.md (tone-match パスが模倣する匿名化済みの作業例) が含まれます。最初の実行前に 3 つすべてを読んでください。
いつ使うか
あなたは CSM または support lead で、アカウントが今まさにエスカレーションした —顧客が怒っている sev-1 の障害、対応を誤ったチケットの連続、renewal を脅かすクレーム— ところで、ポストモーテムの会議や顧客への謝罪コールの前に、書面の RCA を素早く必要としています。Skill は、証拠が Zendesk のスレッド、顧客側の異なる人物が開いた 3 つか 4 つの兄弟チケット、そして不満が実際に表面化した 2 つか 3 つの Gong のコールに散在しているケースのために作られています。そのタイムラインを手作業で組み立てるのはタブを切り替える 60 分から 120 分の作業です。Skill は組み立てを行い、あなたが推論できる下書きを渡します。
Zendesk のチケットがリンクされ (アカウント経由または明示的な problem/incident リンク経由)、一貫してタグ付けされており、期間内の少なくとも 1 件の Gong コールに文字起こしがある場合に、最も有用な output を生成します。これは区切られた期間を持つ単一のエスカレーションイベント —典型的にはトリガーとなったインシデントの前後 14 日から 30 日— に向けて調整されており、四半期にわたるパターン分析向けではありません。
いつ使わないか
Skill の output を未編集で顧客に送らないでください。これは下書きエンジンです。根本原因は、誰かが名前で署名する前に CSM と support lead が自身の知識に照らして確認する仮説です。誤った根本原因を載せた RCA を怒っている顧客に送ることは、RCA がないことより大きな損害を与えます。
タイムラインに 3 件未満のイベントしかない場合は使わないでください。1 件のチケットでコールがなければ再構築するものは何もなく、Skill は物語をでっち上げるのではなく insufficient data を返すように作られています —ただしそれは、実行を強制せずその拒否を尊重した場合に限ります。2 つのデータポイント上に構築された自信ありげな RCA は権威を持って読まれ、それに基づいて行動するすべての人を誤らせます。
法的または契約上の紛争、セキュリティインシデントのポストモーテム、または文言が敵対的になる SLA クレジット交渉に向かうものには使わないでください。Skill は中立的で responsible な registry で運用上の RCA を書きます。擁護可能な法的文言は書かず、金銭や契約条件がかかっているときに重要となる形で責任を過小または過大に述べます。それらはそれを所有するチームにルーティングしてください。
churn の予測子や health score としては使わないでください。これは過去の 1 件のイベントを説明します。composite health score のワークフローが将来を見据えた retention リスク向けに調整されたツールです。この RCA の重大度評価を churn 確率として読むと誤ります。
セットアップ
初回はおおよそ 45 分から 60 分で、その大半は references/2-cause-taxonomy.md の cause taxonomy をチームの実際の障害モードに適応させることに費やします。
- Skill をインストールします。
apps/web/public/artifacts/escalation-rca-skill/のバンドルを~/.claude/skills/escalation-rca/に配置します。Skill は単一のコマンドdraft_rca(account_id, escalation_window, anchor_ticket_id)と、Zendesk の pull、Gong の pull、タイムラインのマージ、Claude の 2 パスパイプライン向けの内部ヘルパーを定義します。 - 認証情報を接続します。
ZENDESK_SUBDOMAINとZENDESK_API_TOKEN(Tickets、Ticket Comments、Ticket Audits への読み取りアクセス —audits がステータス変更の timestamp を与えるものです)、そしてGONG_API_KEY(calls と文字起こしへの読み取りアクセス) を設定します。Skill はどちらのシステムにも書き込みを行いません。設計上 read-only であり、変更管理レビューなしで本番環境に対して実行できます。 - cause taxonomy を適応させます。
references/2-cause-taxonomy.mdを開き、placeholder のカテゴリをチームの実際のものに置き換えます。デフォルトのセットはproduct-defect、config-error、documentation-gap、process-breakdown、capacity-overload、communication-failure、third-party-dependencyです。Skill は根本原因をこれらのうち正確に 1 つに分類し、証拠が裏付ける範囲で残りを寄与要因として列挙します。自由記述の根本原因は、同じインシデントの 2 つの RCA が食い違う最も一般的な理由なので、固定の taxonomy は装飾ではなく構造を担います。 - テンプレートとボイスサンプルを適応させます。
references/1-rca-template.mdを編集し、セクション名がポストモーテムプロセスの期待に合うようにします (一部のチームは影響を受けたユーザー数を伴うcustomer-impactセクションを必要とし、一部はdetectionセクションを必要とします)。references/3-sample-rca.mdの作業例を、チームが書いた匿名化済みの過去 RCA 2、3 件に置き換え、tone-match パスが汎用サンプルではなく自社のスタイルを模倣するようにします。 - 1 件のエスカレーションで実行します。
draft_rca(account_id="...", escalation_window="2026-05-20:2026-06-03", anchor_ticket_id="48213")。Skill は 1 つの Markdown ファイルを書き出します。再構築したタイムライン、根本原因のセクション、寄与要因のリスト、是正アクションの表、そして CSM がそのまま使うか書き直せる 1 段落の顧客向け要約です。
Skill が実際に行うこと
Skill は Zendesk と Gong を並列に pull します。独立したシステムに当たり、ボトルネックは Claude のトークンではなく API のレイテンシだからです。Zendesk からはアンカーチケット、期間内に同じアカウントまたは problem にリンクされた各兄弟チケット、そして —決定的に— 各チケットの audit log を pull します。audits がステータス変更と担当者変更の timestamp を持っており、コメントスレッド単独ではそれがないからです。Gong からは期間内のアカウントのコールを、直近の 6 件までに制限し、それぞれ 4,000 文字に切り詰めた文字起こしとともに pull します。いずれかのシステムが空を返した場合、Skill はそれを埋めるのではなくタイムラインに gap を記録します。
次に、UTC の timestamp をキーとした単一の時系列タイムラインにすべてをマージします。マージは Claude のステップではなく決定論的なステップです。timestamp の順序付けは、言語モデルが微妙に誤りソートが誤らない、まさにその種のものだからです。各イベントはそのソース (zendesk-comment、zendesk-status-change、gong-call)、その actor、そして 1 行の要約を持ちます。このマージされたタイムラインは RCA 全体の背骨であり、読者が下流のあらゆる主張をそれに照らして監査できるよう、output に verbatim で入ります。
その後 Claude の 2 パスです。パス 1 は因果分析です。Claude はマージされたタイムラインと cause taxonomy を読み、単一の名指しした根本原因、切り分けた寄与要因のリスト、そしてそれぞれを裏付ける具体的なタイムラインイベントを生成します。専用のパスで根本原因を寄与要因から切り分けることが重要なのは、最も一般的な RCA の失敗が両者を混同すること —最も騒がしい症状を原因と呼ぶこと— だからです。このパスは、すべての因果的主張についてタイムラインイベントを timestamp で引用し、期間内に 3 件未満のイベントしか存在しない場合は insufficient data を返すよう指示されています。
パス 2 は是正アクション計画と tone-match です。Claude は確認済みの根本原因と寄与要因を取り、是正アクションの表を提案します —各行は 1 つのアクション、責任を負う役割 (名指しした人物ではない。チームが名前を割り当てます)、期限のオフセット、そしてそれが閉じる寄与要因です。次に references/3-sample-rca.md のサンプルを使って RCA 全体をチームのボイスで書き直し、チームが合意していない責任を認めることなく影響と是正を名指しする、より保守的な registry で 1 段落の顧客向け要約を書きます。アクションとトーンを独自のパスに分けることで、顧客向け要約が必要とする軟化によってパス 1 の因果推論が汚染されないようにします。
コストの実際
完全な 1 回の実行は、Claude Sonnet でおおよそ入力 15,000 から 30,000 トークン、出力 2,000 から 4,000 トークンのコストがかかります —現在の Sonnet 価格で RCA 1 件あたり 6 から 12 セントと考えてください。支配的な入力変数は Gong の文字起こしの量です。期間内に 6 件のコールが記録された激しくエスカレーションしたアカウントは上限近くに、コールのないチケットのみのエスカレーションは下限近くに着地します。2 パス設計はプレフィックスのコンテキストを共有するので、2 回目のパスは 1 回目より安価です。
実時間は 2 分から 4 分で、Zendesk の audit log の pull (チケットあたり API コール 1 回追加) と Gong の文字起こしの fetch が支配します。2 つの Claude パスは並列 pull の完了後に 40 から 70 秒を追加します。
CSM または support lead が RCA をゼロから書く場合、典型的に 60 分から 120 分を費やします —チケットを pull し、audits を読み、コールを聞き直し、タイムラインを再構築し、それから書きます。Skill はそれを 20 分から 35 分の編集にします。つまり節約はエスカレーションあたりおおよそ 1 時間です。四半期に 15 件から 25 件の正式なエスカレーションを処理するサポート組織は、15 時間から 25 時間のシニア IC の時間を回収します。エスカレーションは最も経験豊富な人に降りかかるため、コストが最も感じられるのはそこです。
成功指標
「エスカレーション宣言」から「社内 sign-off に向けて RCA を回付」までの時間を追跡します。Skill は利用の最初の四半期内に、ゼロからの基準である半日以上に対して、中央値を 90 分未満に引き下げるはずです。提案された根本原因が support lead のレビューを変更なしで通過する率も追跡してください —60% 以上を目指します。それより低ければ cause taxonomy をインシデントの実際の失敗の仕方に合わせて切り直す必要があります。85% より高ければ lead はおそらくレビューではなく追認しており、human-in-the-loop のガードを無効にしています。
追跡する価値のある 2 つ目の数字は、過去の RCA の是正アクションのうち、期限までに実際に閉じられた割合です。Skill はこれを強制しません —アクションを提案するだけです— が、その割合が 50% を下回り続けるなら、RCA プロセスは演劇であり、より速い下書きエンジンでは直りません。この指標は、組織が根本原因に対して行動しているのか、それとも単に文書化しているだけなのかを教えてくれます。
代替案との比較
Google Doc での手書き RCA との比較。 多くのチームの status quo です。手書きの RCA は、著者がインシデントの loop に個人的にいた場合に忠実度が高くなります。システムが決して記録しなかったコンテキスト —Slack のスレッド、廊下での会話、顧客の本当の不満に対する直感的な読み— を持つからです。トレードオフはタイムライン組み立ての 1 時間超で、これは Skill が排除する純粋に機械的な労苦です。1 語 1 語が吟味される稀な board レベルのエスカレーションには手書きを使い、制約が物語の技巧ではなくシニア IC の時間である運用上のエスカレーションの定常的な量には Skill を使ってください。board レベルのケースでも、Skill の再構築したタイムラインは有用な出発点の artifact です。
Zendesk のネイティブなチケットマージと side-conversation 機能との比較。 Zendesk は関連チケットをリンクおよびマージし、統一されたビューを表面化でき、必要なのが統合されたチケット履歴だけなら、それは Skill をインストールするより少ない作業です。しかし Zendesk はチケットを表面化します。Gong のコールを含むクロスシステムのタイムラインを再構築せず、根本原因を名指しせず、是正アクションを提案しません。それは原材料を与えます。Skill が分析を書きます。兄弟チケットを発見可能に保つために Zendesk のリンクを使い —Skill はそれらを見つけるためにそのリンクに依存します— リンクされたセットを RCA に変えるために Skill を使ってください。
専用のインシデント管理ツール (incident.io や FireHydrant) との比較。 これらは、on-call ローテーション、status page、自動化されたポストモーテムの足場を備えた、エンジニアリング主導のインシデント対応に優れています。エスカレーションがインフラのインシデントで、すでに 1 つ運用しているなら、そのポストモーテムフローを使ってください。しかしそれらのツールは顧客関係のライフサイクルではなくエンジニアリングのインシデントライフサイクルを中心に作られています。あなたの Gong のコールを読まず、CSM チームの顧客向けボイスで書きません。欠陥と同じくらい関係についてでもある CS が所有するエスカレーションには、この Skill がそれらのツールが残す隙間に収まります。
注意点
- 因果パスにおける後知恵バイアス。 既知の悪い結果からタイムラインを逆向きに読むと、それ以前のあらゆる決定が明白な誤りに見え、ガードがなければ Claude はそのように語ります。ガード: パス 1 は各イベントで知り得たことを後知恵でのみ知り得ることから区別し、後知恵に依存するあらゆる主張に印を付けるよう指示されています。また期間内に 3 件未満のタイムラインイベントしか存在しないときは推測するのではなく
insufficient dataを返します —物語を支えるには薄すぎる基盤の上に物語は構築されません。 - audit log の欠落がタイムラインを崩壊させる。 Zendesk のトークンに audit 読み取りの scope がない場合、Skill は静かにステータス変更の timestamp なしでコメントを取得し、タイムラインは「チケットが 9 日間 pending に留まった」イベントを失います。それがしばしば本当の物語です。ガード: Skill はセットアップ検証中にアンカーチケットの audit アクセスをチェックし、最も重要なイベントを省くタイムラインを生成するのではなく
ZENDESK_AUDIT_SCOPE_MISSINGエラーで実行を拒否します。 - 根本原因が最も騒がしい症状と混同される。 顧客が最も苦情を言ったイベントが根本原因であることはまれです。通常それは下流の症状です。ガードのないモデルは volume にアンカーします。ガード:
references/2-cause-taxonomy.mdの cause taxonomy は単一の分類されたカテゴリを強制し、パス 1 は原因が作用していた最も早い時点である具体的なタイムラインイベントを引用しなければなりません —最も騒がしいものではなく、最も早いものです。後から来た症状は寄与要因として整理されます。 - 薄い文字起こしでの Gong センチメントの過剰な読み取り。 文字起こしが 90 秒のボイスメールであるとき、1 件の短いコールが「顧客は激怒している」として過剰に重み付けされます。ガード: Skill は因果パスにおける Gong の影響を裏付け証拠に制限します —コールはタイムラインイベントを裏付けられますが、それ単独で名指しした根本原因にはなれません。記録された苦情は症状であって原因ではないからです。200 語未満の文字起こしは低信頼としてフラグされ、センチメントの読み取りから除外されます。
- チームが合意していない責任を認める顧客向け要約。 パス 2 は顧客が読む可能性のある要約を書き、自身の registry に任された LLM は会社が所有すると決めていないことについて謝罪します。ガード: 顧客向け要約のプロンプトは影響と是正のみを名指しし、責めの割り当てや補償の約束を明示的に禁じ、CSM が手で取り除かなければならない
REVIEW BEFORE SENDINGマーカーを段落の先頭に付けます —顧客向けのテキストが人間の手を介さずに Skill から出る経路はありません。
スタック
- Zendesk —チケットスレッド、兄弟チケット、そしてステータス変更の timestamp を持つ audit log (REST API、read-only)
- Gong —エスカレーション期間内のアカウントのコールの文字起こしとメタデータ (Gong API、read-only)
- Claude —2 パス分析: taxonomy に対する因果分析、その後の是正アクション計画と tone-match (コストのため Sonnet 推奨。顧客向け要約が異例の機微を帯びる場合のみ Opus)