customer-escalation

/customer-escalation

見慣れないプレースホルダーがある場合や、どのツールが接続されているか確認する場合は、CONNECTORS.md を参照してください。

サポート案件を、エンジニアリング、プロダクト、またはリーダーシップ向けの構造化されたエスカレーション概要にまとめます。背景情報を集め、再現手順を整理し、ビジネスへの影響を評価して、適切なエスカレーション先を特定します。

使用方法

/customer-escalation <issue description> [customer name or account]

例：

• /customer-escalation Acme Corp で API が断続的に 500 エラーを返す
• /customer-escalation データエクスポートで行が欠落しています — 今週、3 社の顧客から報告がありました
• /customer-escalation すべての Enterprise 顧客で SSO ログインがループしています
• /customer-escalation 監査ログ機能がないことを理由に、顧客が解約をほのめかしています

ワークフロー

1. 問題を把握する

入力を解析して、次の点を特定します。

• 何が壊れているか、または何が必要か：技術面またはプロダクト面における中心的な問題
• 誰が影響を受けているか：特定の顧客、顧客セグメント、またはすべてのユーザー
• どのくらい続いているか：いつ始まったか。顧客はどのくらい待っているか
• これまでに試したこと：トラブルシューティングや回避策を試したか
• 今エスカレーションする理由：通常のサポート対応を超えて、今対処する必要がある理由

以下の「サポートで対応する場合とエスカレーションする場合」の基準を使って、エスカレーションが妥当か確認します。

2. 背景情報を集める

利用可能な情報源から、関連情報を集めます。

• ~~support platform：関連チケット、やり取りの経緯、過去のトラブルシューティング
• ~~CRM（接続されている場合）：アカウントの詳細、主要な連絡先、過去のエスカレーション
• ~~chat：この問題に関する社内での議論、他の顧客からの類似報告
• ~~project tracker（接続されている場合）：関連するバグ報告や機能リクエスト、エンジニアリングの対応状況
• ~~knowledge base：既知の問題や回避策、関連ドキュメント

3. ビジネスへの影響を評価する

以下の影響の観点から、影響を定量化します。

• 範囲：影響を受けている顧客／ユーザー数。増加しているか
• 深刻度：業務が完全に停止しているか、支障が生じている程度か
• 期間：どのくらい続いているか
• 収益：リスクにさらされている ARR はあるか。進行中の商談に影響があるか
• 時間的な切迫度：厳守すべき期限があるか

4. エスカレーション先を決める

以下のエスカレーションの段階を使って、適切な担当先（L2 サポート、エンジニアリング、プロダクト、セキュリティ、リーダーシップ）を特定します。

5. 再現手順を整理する（バグの場合）

問題がバグの場合は、以下の再現手順に関するベストプラクティスに従い、環境の詳細と証拠を含めて、明確な再現手順を記録します。

6. エスカレーション概要を作成する

## ESCALATION: [One-line summary]

**Severity:** [Critical / High / Medium]
**Target team:** [Engineering / Product / Security / Leadership]
**Reported by:** [Your name/team]
**Date:** [Today's date]

### Impact
- **Customers affected:** [Who and how many]
- **Workflow impact:** [What they can't do]
- **Revenue at risk:** [If applicable]
- **Time in queue:** [How long this has been an issue]

### Issue Description
[Clear, concise description of the problem — 3-5 sentences]

### What's Been Tried
1. [Troubleshooting step and result]
2. [Troubleshooting step and result]
3. [Troubleshooting step and result]

### Reproduction Steps
[If applicable — follow the format below]
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

### Customer Communication
- **Last update to customer:** [Date and what was communicated]
- **Customer expectation:** [What they're expecting and by when]
- **Escalation risk:** [Will they escalate further if not resolved by X?]

### What's Needed
- [Specific ask — "investigate root cause", "prioritize fix",
  "make product decision on X", "approve exception for Y"]
- **Deadline:** [When this needs resolution or an update]

### Supporting Context
- [Related tickets or links]
- [Internal discussion threads]
- [Documentation or logs]

7. 次のステップを提案する

エスカレーションを作成した後：

• 「対象チームの ~~chat チャンネルに投稿しますか？」
• 「顧客に暫定的な回答を送りますか？」
• 「状況を確認するためのフォローアップリマインダーを設定しますか？」
• 「現在の状況を伝える、顧客向けの更新文を作成しますか？」

---

サポートで対応する場合とエスカレーションする場合

サポートで対応する場合：

• 文書化された解決策または既知の回避策がある
• 解決可能な設定またはセットアップの問題である
• 顧客が求めているのは修正ではなく、案内やトレーニングである
• 文書化された代替策がある既知の制限である
• 過去の類似チケットがサポートレベルで解決されている

エスカレーションする場合：

• 技術面：バグが確認されており、コード修正が必要である。インフラの調査が必要である。データの破損や消失が発生している
• 複雑さ：サポートでは診断できない。サポートにないアクセス権が必要である。カスタム実装が関係している
• 影響：複数の顧客が影響を受けている。本番システムが停止している。データの整合性が脅かされている。セキュリティ上の懸念がある
• ビジネス：価値の高い顧客が離脱するリスクがある。SLA 違反が差し迫っている、または発生した。顧客が幹部の関与を求めている
• 時間：SLA の期限を超えて未解決である。顧客が不合理なほど長く待っている。通常のサポートチャネルで進展がない
• 傾向：3 社以上の顧客から同じ問題が報告されている。修正済みとされていた問題が再発している。時間の経過とともに深刻度が増している

エスカレーションの段階

L1 → L2（サポートのエスカレーション）

差出人： 一次サポート 宛先： シニアサポート／テクニカルサポートのスペシャリスト タイミング： より詳細な調査、専門的な製品知識、または高度なトラブルシューティングが必要な場合 含める内容： チケットの概要、すでに試した手順、顧客の状況

L2 → エンジニアリング

差出人： シニアサポート 宛先： エンジニアリングチーム（関連する製品領域） タイミング： バグが確認された場合、インフラストラクチャの問題、コード変更が必要な場合、システムレベルの調査が必要な場合 含める内容： 詳細な再現手順、環境の詳細、ログまたはエラーメッセージ、ビジネスへの影響、顧客の経緯

L2 → プロダクト

差出人： シニアサポート 宛先： プロダクトマネジメント タイミング： 機能の不足が顧客の不満を招いている場合、設計上の判断が必要な場合、ワークフローが顧客の期待に合わない場合、顧客間のニーズが競合し優先順位付けが必要な場合 含める内容： 顧客のユースケース、ビジネスへの影響、要望の頻度、競合上の圧力（把握している場合）

任意のサポート階層 → セキュリティ

差出人： 任意のサポート階層 宛先： セキュリティチーム タイミング： データ漏えいの可能性、不正アクセス、脆弱性の報告、コンプライアンス上の懸念がある場合 含める内容： 確認した事象、影響を受ける可能性のある人や対象、実施した初動の封じ込め措置、緊急度の評価 注： セキュリティへのエスカレーションは通常の階層移行を経ず、担当者のレベルにかかわらず直ちにエスカレーションします。

任意の階層 → リーダーシップ

差出人： 任意の階層（通常はL2またはマネージャー） 宛先： サポート部門のリーダーシップ、経営陣 タイミング： 大口顧客が解約を示唆している場合、重要顧客でSLA違反が発生した場合、部門横断の判断が必要な場合、ポリシーの例外が必要な場合、広報または法務上のリスクがある場合 含める内容： ビジネス状況の全容、リスクにさらされている売上、これまでに試したこと、必要な判断または対応の具体的な内容、期限

ビジネスへの影響の評価

エスカレーションする際は、可能な範囲で影響を数値化します。

影響の側面

側面	確認する質問
範囲	影響を受ける顧客／ユーザーは何人ですか？増加していますか？
深刻度	どの程度の影響を受けていますか？業務が停止していますか、それとも不便が生じているだけですか？
期間	どのくらい続いていますか？重大な問題になるまで、あとどのくらいですか？
売上	リスクにさらされているARRはいくらですか？影響を受ける商談は進行中ですか？
評判	公になり得る問題ですか？リファレンス顧客ですか？
契約上の義務	SLAに違反していますか？契約上の義務はありますか？

重大度の略記

• 重大：本番環境の停止、データのリスク、セキュリティ侵害、または複数の高価値顧客への影響が発生しています。即時対応が必要です。
• 高：主要な機能が動作せず、重要顧客の業務が停止し、SLAが危機に瀕しています。当日中の対応が必要です。
• 中：回避策はあるものの重大な問題で、重要ではあるが緊急ではないビジネス上の影響があります。今週中の対応が必要です。

再現手順の記述

適切な再現手順は、バグのエスカレーションにおいて最も価値のある情報です。次の方法に従ってください。

1. クリーンな状態から始める：開始時の状態（アカウントの種類、構成、権限）を記述します
2. 具体的に記述する：「エクスポートを試す」ではなく、「ダッシュボードページ右上のエクスポートボタンをクリックする」と記述します
3. 正確な値を含める：「データを入力する」ではなく、具体的な入力値、日付、IDを使用します
4. 環境を記録する：ブラウザー、OS、アカウントの種類、フィーチャーフラグ、プランのレベル
5. 発生頻度を記録する：常に再現しますか？断続的ですか？特定の条件下でのみ発生しますか？
6. 証拠を含める：スクリーンショット、エラーメッセージ（正確な文面）、ネットワークログ、コンソール出力
7. 除外した原因を記録する：「ChromeとFirefoxでテストし、同じ動作を確認」「アカウント固有の問題ではなく、テストアカウントでも再現」

エスカレーション後のフォローアップ頻度

エスカレーションしたまま放置しないでください。顧客との関係は引き続き責任を持って管理します。

重大度	社内フォローアップ	顧客への状況報告
Critical	2 時間ごと	2〜4 時間ごと（または SLA に従う）
High	4 時間ごと	4〜8 時間ごと
Medium	毎日	1〜2 営業日ごと

フォローアップの対応

• 引き継ぎ先のチームに進捗を確認します
• 新しい情報がない場合でも顧客に状況を報告します（「引き続き調査中です。現時点で分かっていることをお知らせします」）
• 状況が変化した場合は、重大度を見直します（改善または悪化）
• 監査証跡として、すべての更新内容をチケットに記録します
• 解決したら、顧客に確認し、社内の追跡情報を更新して、学びを記録することで、対応を完了します

エスカレーションの解除

エスカレーションを常に継続する必要はありません。次の場合は解除します。

• 根本原因が特定され、サポートで解決できる問題である
• 顧客の作業を再開できる回避策が見つかった
• 問題が自然に解決した（ただし、根本原因は記録します）
• 新しい情報により重大度の評価が変わった

エスカレーションを解除する際は、次の対応を行います。

• エスカレーション先のチームに通知します
• 解決内容をチケットに記載します
• 解決したことを顧客に伝えます
• 今後の参考として、得られた知見を記録します

エスカレーションのベストプラクティス

1. 影響を必ず定量化します。曖昧なエスカレーションは優先度が下げられます
2. バグには再現手順を含めます。これはエンジニアリングチームにとって最も重要な情報です
3. 必要な対応を明確にします。「調査」「修正」「判断」は、それぞれ異なる依頼です
4. 期限を設定して伝えます。期限のない緊急性は曖昧です
5. 技術的な問題をエスカレーションした後も、顧客との関係は引き続き責任を持って管理します
6. 先回りしてフォローアップします。引き継ぎ先のチームから連絡が来るのを待たないでください
7. すべてを記録します。エスカレーションの記録は、パターンの検出やプロセスの改善に役立ちます