/customer-escalation

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

サポート課題を構造化されたエスカレーションブリーフにパッケージ化して、エンジニアリング、プロダクト、またはリーダーシップに提出します。コンテキストを収集し、再現手順を構造化し、ビジネスインパクトを評価し、適切なエスカレーション対象を特定します。

使い方

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

例:

• /customer-escalation API returning 500 errors intermittently for Acme Corp
• /customer-escalation Data export is missing rows — 3 customers reported this week
• /customer-escalation SSO login loop affecting all Enterprise customers
• /customer-escalation Customer threatening to churn over missing audit log feature

ワークフロー

1. 課題を理解する

入力を解析して以下を判断します:

• 何が壊れているか、または何が必要か: コア技術またはプロダクト課題
• 誰が影響を受けているか: 特定の顧客、セグメント、またはすべてのユーザー
• どのくらい長いか: いつ開始したか? 顧客はどのくらい待っているか?
• 何が試されたか: 試されたトラブルシューティングや回避策
• なぜ今エスカレートするのか: 通常のサポートを超えた対応が必要な理由

以下の「エスカレート vs サポートで対応」基準を使用して、エスカレーションが必要かを確認します。

2. コンテキストを収集する

利用可能なソースから関連情報を集めます:

• サポートプラットフォーム: 関連するチケット、コミュニケーション履歴、以前のトラブルシューティング
• CRM (接続されている場合): アカウント詳細、主要連絡先、以前のエスカレーション
• チャット: このアイステムに関する内部ディスカッション、他の顧客からの同様のレポート
• プロジェクトトラッカー (接続されている場合): 関連するバグレポートまたは機能リクエスト、エンジニアリングのステータス
• ナレッジベース: 既知の課題または回避策、関連ドキュメント

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. 次のステップを提案する

エスカレーションブリーフを生成した後:

• "Want me to post this in a ~~chat channel for the target team?"
• "Should I update the customer with an interim response?"
• "Want me to set a follow-up reminder to check on this?"
• "Should I draft a customer-facing update with the current status?"

---

エスカレート vs サポートで対応

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

• 課題に文書化されたソリューションまたは既知の回避策がある
• 設定またはセットアップの課題で、解決できるもの
• 顧客が修正ではなく、ガイダンスまたはトレーニングを必要とする
• 課題は既知の制限であり、ドキュメント化された代替手段がある
• 以前の同様のチケットはサポートレベルで解決された

エスカレートする場合:

• 技術的: バグが確認され、コード修正が必要、インフラストラクチャ調査が必要、データ破損または喪失
• 複雑性: 課題はサポートの診断能力を超えている、サポートが持たないアクセスが必要、カスタム実装が関係している
• インパクト: 複数の顧客が影響を受けている、本番システムがダウンしている、データ完全性がリスクにある、セキュリティ懸念がある
• ビジネス: 高価値の顧客がリスクにある、SLA 違反が切迫している、またはすでに発生している、顧客が実行役員の関与を要求している
• 時間: 課題が SLA を超えて開いている、顧客が不当に長く待っている、通常のサポートチャネルが進展していない
• パターン: 3 人以上の顧客から同じ課題が報告されている、修正されたはずの再発課題、時間とともに重大度が増加している

エスカレーションティア

L1 → L2 (サポートエスカレーション)

差出人: フロントラインサポート 受信者: シニアサポート / 技術サポートスペシャリスト タイミング: 課題がより深い調査、特殊なプロダクト知識、または高度なトラブルシューティングが必要 含める内容: チケットの概要、すでに試された手順、顧客コンテキスト

L2 → エンジニアリング

差出人: シニアサポート 受信者: エンジニアリングチーム (関連するプロダクト領域) タイミング: バグが確認されている、インフラストラクチャ課題、コード変更が必要、システムレベルの調査が必要 含める内容: 完全な再現手順、環境詳細、ログまたはエラーメッセージ、ビジネスインパクト、顧客タイムライン

L2 → プロダクト

差出人: シニアサポート 受信者: プロダクトマネジメント タイミング: 顧客の苦痛を引き起こすフィーチャーギャップ、デザイン決定が必要、ワークフローが顧客の期待と合致していない、競合する顧客ニーズが優先順位付けが必要 含める内容: 顧客のユースケース、ビジネスインパクト、リクエストの頻度、競争圧力 (既知の場合)

任意 → セキュリティ

差出人: 任意のサポートティア 受信者: セキュリティチーム タイミング: 潜在的なデータ露出、不正アクセス、脆弱性レポート、コンプライアンス懸念 含める内容: 何が観察されたか、誰/何が潜在的に影響を受けているか、実施された即座の封じ込め手順、緊急度評価 注: セキュリティエスカレーションは通常のティア進行をバイパスします — あなたのレベルに関わらず即座にエスカレートしてください

任意 → リーダーシップ

差出人: 任意のティア (通常は L2 またはマネージャー) 受信者: サポートリーダーシップ、エグゼクティブチーム タイミング: 高収益顧客がチャーン脅迫、重要アカウントの SLA 違反、クロスファンクショナルな決定が必要、ポリシー例外が必要、PR またはリーガルリスク 含める内容: 完全なビジネスコンテキスト、リスク下の収益、 試されたもの、必要な特定の決定または行動、期限

ビジネスインパクト評価

エスカレートするときは、可能な限りインパクトを定量化します:

インパクト評価軸

評価軸	回答すべき質問
広さ	何人の顧客/ユーザーが影響を受けているか? 増加しているか?
深さ	どの程度深刻な影響を受けているか? ブロックされているか、不便なだけか?
期間	どのくらい長く続いているか? どのくらい長くすると重大になるか?
収益	リスク下の ARR は何か? 保留中のディールが影響を受けているか?
評判	これは公開されるようになる可能性があるか? リファレンス顧客であるか?
契約上	SLA が違反されているか? 契約上の義務があるか?

重大度の短縮表現

• Critical: 本番がダウンしている、データがリスクにある、セキュリティ侵害がある、または複数の高価値顧客が影響を受けている。即座の対応が必要。
• High: 主要機能が壊れている、重要な顧客がブロックされている、SLA がリスクにある。同じ日の対応が必要。
• Medium: 重大な課題があるが回避策がある、重要だがそこまで急ではないビジネスインパクト。今週中の対応が必要。

再現手順を書く

良い再現手順はバグエスカレーションで最も価値のあるものです。以下のプラクティスに従います:

1. クリーンな状態から始める: 開始点を説明します (アカウントタイプ、設定、権限)
2. 具体的である: 「Dashboard ページの右上の Export ボタンをクリック」「export を試す」ではなく
3. 正確な値を含める: 「いくつかのデータを入力」ではなく、特定の入力、日付、ID を使用
4. 環境をメモする: ブラウザ、OS、アカウントタイプ、フィーチャーフラグ、プランレベル
5. 頻度をキャプチャする: 常に再現可能か? 散発的か? 特定の条件下でのみか?
6. 証拠を含める: スクリーンショット、エラーメッセージ (正確なテキスト)、ネットワークログ、コンソール出力
7. 除外したものをメモする: 「Chrome と Firefox でテスト — 同じ動作」「アカウント固有ではない — テストアカウントで再現」

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

エスカレートして忘れてはいけません。顧客関係の所有権を保持します。

重大度	内部フォローアップ	顧客更新
Critical	2 時間ごと	2～4 時間ごと (または SLA に従う)
High	4 時間ごと	4～8 時間ごと
Medium	毎日	1～2 営業日ごと

フォローアップアクション

• 受信チームに進捗を確認
• 新しい情報がなくても顧客を更新 (「まだ調査中です — 現在ここまで知っていることを知っています」)
• 状況が変わった場合 (改善または悪化)、重大度を調整
• 監査証跡のためにすべての更新をチケットに文書化
• 解決したらループを閉じる: 顧客と確認、内部トラッキングを更新、学習を取得

エスカレーション解除

すべてのエスカレーションがエスカレートされたままになるわけではありません。以下の場合にエスカレーション解除します:

• 根本原因が見つかり、サポートで解決可能な課題である
• 顧客をアンブロックする回避策が見つかった
• 課題が自然に解決した (ただし根本原因を文書化する)
• 新しい情報が重大度評価を変更する

エスカレーション解除する場合:

• エスカレートしたチームに通知
• 解決方法でチケットを更新
• 顧客に解決を通知
• 将来の参考のために学んだことを文書化

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

1. 常にインパクトを定量化 — 曖昧なエスカレーションは優先順位が低下される
2. バグの再現手順を含める — これはエンジニアリングが最も必要とするもの
3. 必要な内容を明確に — 「調査」vs「修正」vs「決定」は異なる要求
4. 期限を設定して伝える — 期限のない緊急度は曖昧
5. エスカレーション後も顧客関係の所有権を保持 — 技術課題がエスカレートされた場合でも
6. プロアクティブにフォローアップ — 受信チームが対応するのを待たない
7. すべてを文書化 — エスカレーションの証跡はパターン検出と プロセス改善に価値がある