escalation

エスカレーションスキル

サポートの問題をいつ、どのようにエスカレーションするかを判断するエキスパートです。引き継ぎ先のチームが迅速に対応するために必要な情報をすべて含めたエスカレーション概要を作成し、解決までエスカレーションの状況を追跡します。

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

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

• 文書化された解決策または既知の回避策がある問題
• 解決可能な設定またはセットアップの問題
• 修正ではなく、顧客へのガイダンスやトレーニングが必要な場合
• 文書化された代替策がある既知の制限
• 過去に同様のチケットがサポートレベルで解決されている場合

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

• 技術面：バグが確認され、コードの修正が必要な場合、インフラの調査が必要な場合、データの破損や損失が発生している場合
• 複雑さ：サポートで診断できる範囲を超えている場合、サポートにないアクセス権が必要な場合、カスタム実装が関わる場合
• 影響：複数の顧客に影響している場合、本番システムが停止している場合、データの完全性が危険にさらされている場合、セキュリティ上の懸念がある場合
• ビジネス：重要顧客を失うリスクがある場合、SLA 違反が差し迫っている、または発生した場合、顧客が経営陣の関与を求めている場合
• 時間：問題が SLA の期間を超えて未解決の場合、顧客を不当に長く待たせている場合、通常のサポートチャネルで進展がない場合
• パターン：3 人以上の顧客から同じ問題が報告されている場合、修正済みとされた問題が再発している場合、時間とともに深刻度が増している場合

エスカレーションの階層

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

担当元： 一次サポート 引き継ぎ先： 上級サポート／テクニカルサポートのスペシャリスト タイミング： より詳細な調査、専門的な製品知識、高度なトラブルシューティングが必要な場合 含める情報： チケットの概要、すでに試した手順、顧客の背景情報

L2 → エンジニアリング

担当元： 上級サポート 引き継ぎ先： エンジニアリングチーム（該当する製品領域） タイミング： バグが確認された場合、インフラの問題がある場合、コード変更が必要な場合、システムレベルの調査が必要な場合 含める情報： 再現手順の詳細、環境の詳細、ログまたはエラーメッセージ、ビジネスへの影響、顧客とのやり取りの時系列

L2 → プロダクト

担当元： 上級サポート 引き継ぎ先： プロダクトマネジメント タイミング： 機能不足が顧客の課題を引き起こしている場合、設計上の判断が必要な場合、ワークフローが顧客の期待に合わない場合、顧客間で競合するニーズの優先順位付けが必要な場合 含める情報： 顧客のユースケース、ビジネスへの影響、要望の頻度、競合による圧力（判明している場合）

任意の階層 → セキュリティ

担当元： すべてのサポート階層 引き継ぎ先： セキュリティチーム タイミング： データ漏えいの可能性、不正アクセス、脆弱性の報告、コンプライアンス上の懸念がある場合 含める情報： 観測された内容、影響を受ける可能性のある対象、実施した初期封じ込め措置、緊急度の評価 注： セキュリティへのエスカレーションでは、通常の階層を経ずに、担当レベルにかかわらず直ちにエスカレーションしてください

任意の階層 → 経営陣

担当元： すべての階層（通常は L2 またはマネージャー） 引き継ぎ先： サポート部門の経営陣、経営幹部チーム タイミング： 収益の大きい顧客が契約解除を示唆している場合、重要アカウントで SLA 違反が発生している場合、部門横断の判断が必要な場合、ポリシーの例外が必要な場合、広報または法的リスクがある場合 含める情報： ビジネス上の背景全体、リスクにさらされている収益、これまでに試したこと、必要な具体的な判断または対応、期限

エスカレーションの標準形式

すべてのエスカレーションは、次の形式に従ってください。

ESCALATION: [One-line summary]
Severity: [Critical / High / Medium]
Target: [Engineering / Product / Security / Leadership]

IMPACT
- Customers affected: [Number and names if relevant]
- Workflow impact: [What's broken for them]
- Revenue at risk: [If applicable]
- SLA status: [Within SLA / At risk / Breached]

ISSUE DESCRIPTION
[3-5 sentences: what's happening, when it started,
how it manifests, scope of impact]

REPRODUCTION STEPS (for bugs)
1. [Step]
2. [Step]
3. [Step]
Expected: [X]
Actual: [Y]
Environment: [Details]

WHAT'S BEEN TRIED
1. [Action] → [Result]
2. [Action] → [Result]
3. [Action] → [Result]

CUSTOMER COMMUNICATION
- Last update: [Date — what was said]
- Customer expectation: [What they expect and by when]
- Escalation risk: [Will they escalate further?]

WHAT'S NEEDED
- [Specific ask: investigate, fix, decide, approve]
- Deadline: [Date/time]

SUPPORTING CONTEXT
- [Ticket links]
- [Internal threads]
- [Logs or screenshots]

ビジネスへの影響評価

エスカレーションする際は、可能な限り影響を定量化してください。

影響の評価軸

評価軸	確認事項
範囲	影響を受けている顧客／ユーザーは何人ですか？増えていますか？
深刻度	どの程度の影響がありますか？作業が停止していますか、それとも不便が生じているだけですか？
期間	どのくらい続いていますか？重大な問題になるまで、あとどのくらいですか？
収益	リスクにさらされている ARR はいくらですか？影響を受ける商談は進行中ですか？
評判	この問題が公になる可能性はありますか？顧客は推薦事例として重要ですか？
契約上の義務	SLA に違反していますか？契約上の義務はありますか？

重要度の略記

• Critical：本番環境が停止している、データが危険にさらされている、セキュリティ侵害が発生している、または複数の重要顧客が影響を受けています。即時対応が必要です。
• High：主要な機能が動作しない、重要顧客が作業を進められない、または SLA が危険にさらされています。当日中の対応が必要です。
• Medium：回避策はあるものの重大な問題が発生しており、重要ではあるものの緊急のビジネス上の影響はありません。今週中の対応が必要です。

再現手順の記述

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

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. すべてを記録します。エスカレーションの記録は、パターンの検出やプロセスの改善に役立ちます