escalation-brief

エスカレーションするか、社内で解決するかを判断する

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

• 文書化された修正方法または既知の回避策で問題を解決できる
• 根本原因が設定またはセットアップのミスであり、修正できる
• 顧客が必要としているのは、製品の変更ではなく、指導やトレーニングである
• 制限事項が文書化されており、代替手段がある
• 同じ属性を持つ過去のチケットが、サポートの階層内で解決されている

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

• 技術的な障壁：確認済みの不具合にコードレベルの修正が必要、インフラレベルの調査が必要、またはデータが失われたか破損している
• 診断の限界：問題がサポートツールやアクセス範囲を超えている、カスタムデプロイが関係している、またはデータベースレベルの調査が必要
• 広範な被害：複数の顧客から同じ問題が報告されている、本番環境が停止している、データの整合性が損なわれている、またはセキュリティ上の脅威がある
• ビジネス上の重大性：重要顧客を失うリスクがある、SLAに違反したか違反しそうである、または顧客が経営陣の関与を求めている
• 進展の停滞：SLAを超えて問題が未解決のままになっている、顧客を不当に長く待たせている、または標準的なトラブルシューティングで進展がない
• 再発するパターン：同じ症状について3件以上の独立した報告がある、以前修正した問題が再発している、または深刻度が時間とともに増している

エスカレーション先

サポート L1 からサポート L2

送信者： フロントラインのサポートエージェント 受信者： シニアサポート／技術スペシャリスト トリガー： より詳細な調査、専門的な製品知識、または高度なデバッグが必要 パッケージの内容： 問題の概要、実施済みのトラブルシューティング、顧客の背景情報

サポート L2 からエンジニアリング

送信者： シニアサポート 受信者： 担当エンジニアリングチーム トリガー： 確認済みの不具合、インフラの障害、コード変更の必要性、システムレベルの調査が必要 パッケージの内容： 完全な再現手順、環境の詳細、関連するログとエラー出力、ビジネスへの影響の説明、顧客に伝えた対応期限の約束

サポート L2 からプロダクト

送信者： シニアサポート 受信者： プロダクトマネジメント トリガー： 顧客に支障をもたらす機能の不足、設計レベルの判断の必要性、ワークフローの不一致、顧客間の優先順位の競合 パッケージの内容： 顧客のユースケースの説明、ビジネスへの影響、リクエストの頻度、入手可能な場合は競合状況

どの階層からでもセキュリティへ

送信者： 任意のサポートエージェント 受信者： セキュリティチーム トリガー： データ漏えいの可能性、不正アクセスの報告、脆弱性の開示、コンプライアンス上のリスク パッケージの内容： 確認した事実、影響を受ける関係者／システム、実施済みの封じ込め措置、緊急度の評価 ルール： セキュリティへのエスカレーションでは、階層を順に進む必要はありません。担当レベルにかかわらず、直ちにルーティングしてください。

どの階層からでも経営陣へ

送信者： 通常は L2 またはサポートマネージャー 受信者： サポートのリーダーシップまたは経営幹部 トリガー： ARR の高い顧客が解約の可能性を示している、戦略的顧客の SLA 違反、部門横断的な判断が必要、ポリシーの例外が必要、法的リスクまたは評判上のリスク パッケージの内容： ビジネスに関する完全な背景情報、収益への影響、これまでに実施した対応、必要な具体的な判断または介入、厳守すべき期限

エスカレーション文書の構成

次のフレームワークを使って、すべてのエスカレーションをまとめます。

ESCALATION: [Concise one-line summary]
Severity: [Critical / High / Medium]
Routed to: [Engineering / Product / Security / Leadership]

BUSINESS IMPACT
- Affected customers: [Count and names where relevant]
- Operational effect: [What is broken for them]
- Revenue exposure: [Dollar figure if applicable]
- SLA position: [Compliant / At risk / Breached]

PROBLEM NARRATIVE
[3-5 sentences covering: what is happening, when it began,
how it presents, and how wide the blast radius is]

REPRODUCTION PROCEDURE (for defects)
1. [Step]
2. [Step]
3. [Step]
Expected outcome: [X]
Observed outcome: [Y]
Environment: [Browser, OS, plan tier, feature flags, etc.]

ACTIONS ALREADY TAKEN
1. [What was tried] -> [Outcome]
2. [What was tried] -> [Outcome]
3. [What was tried] -> [Outcome]

CUSTOMER COMMUNICATION STATUS
- Most recent update: [Date and summary]
- Customer expectation: [What they believe will happen and by when]
- Further escalation risk: [Likelihood customer escalates beyond you]

REQUEST
- [Precise ask: investigate / ship a fix / make a decision / approve an exception]
- Hard deadline: [Date/time]

ATTACHMENTS AND REFERENCES
- [Ticket URLs]
- [Internal discussion threads]
- [Log files, screenshots, recordings]

ビジネスへの影響を定量化する

曖昧なエスカレーションは優先度を下げられます。以下の観点から測定可能な影響を示し、すべてのエスカレーションの根拠を明確にしてください。

観点	主な質問
範囲	影響を受けている顧客またはエンドユーザーは何人ですか？その数は増えていますか？
深刻度	完全に業務が停止していますか、それとも不便が生じているだけですか？
継続期間	どのくらい続いていますか？いつ重大な問題になりますか？
収益	影響を受けるARRはいくらですか？進行中の商談にリスクはありますか？
評判	ソーシャルメディアや報道機関に取り上げられる可能性はありますか？リファレンス顧客が関わっていますか？
契約	SLAの条件に違反していますか？契約上のペナルティが適用されますか？

重大度の簡易定義

• Critical：サービス停止、データのリスク、進行中のセキュリティインシデント、または複数の高価値アカウントへの影響。直ちに対応する必要があります。
• High：中核機能の障害、重要顧客の業務停止、SLAのしきい値に接近。即日対応が必要です。
• Medium：重大な問題ですが、実行可能な回避策があります。ビジネスへの影響は現実に生じていますが、時間的な緊急性はありません。今週中に解決する必要があります。

効果的な再現手順の作成

正確な再現手順は、あらゆる不具合エスカレーションにおいて最も価値の高い要素です。

1. 基準となる状態を明確にする：アカウントの種類、設定、権限、および前提条件を説明します。
2. 操作を正確に記述する：「エクスポートしてみる」ではなく、「レポート画面の右上にあるCSVをエクスポートボタンを選択する」と記述します。
3. 入力値をそのまま明記する：「値を入力する」ではなく、実際に使用したデータ値、ID、または文字列を提示します。
4. 環境を記録する：ブラウザーとバージョン、オペレーティングシステム、アカウントプランのティア、有効な機能フラグを記録します。
5. 発生頻度を明記する：毎回再現しますか？断続的に発生しますか？特定の条件下でのみ発生しますか？
6. 証拠を添付する：スクリーンショット、正確なエラーテキスト、ネットワークトレース、ブラウザーのコンソール出力を添付します。
7. 確認した環境を記録する：「Chrome 122とSafari 17の両方で再現」／「ステージング環境と本番環境の両方で発生」

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

フォローアップのないエスカレーションは放置と同じです。継続して対応してください。

重大度	対応チームへの状況確認	顧客への状況報告
Critical	2時間ごと	2～4時間ごと（またはSLAに従う）
High	4時間ごと	4～8時間ごと
Medium	1日1回	1～2営業日ごと

継続的な責任

• 進捗を確認するため、対応チームに積極的に連絡します。連絡を待ってはいけません。
• 新しい情報がない場合も顧客に状況を伝えます：「調査を継続中です。これまでに確認できた内容をお知らせします。」
• 状況が変化した場合は、重大度を再評価します。
• 監査できるよう、すべての更新内容をチケットに継続して記録します。
• 解決したら、顧客に確認し、内部の追跡を終了して、得られた教訓を記録します。

エスカレーションを解除するタイミング

エスカレーションは恒久的なものではありません。次の場合は、問題をエスカレーションの対象から戻してください。

• 調査の結果、サポートが直接対処できる原因が判明した場合
• 顧客の業務を完全に再開できる回避策が見つかった場合
• 問題が自然に解消した場合（ただし、根本原因は引き続き記録してください）
• 情報の更新によって重大度の判断が変わった場合

エスカレーション解除の手順

• エスカレーションを受けたチームに通知します
• 解決内容または新しい状況をチケットに記録します
• 結果を顧客に伝えます
• 今後のエージェントが知見を活用できるよう、調査結果を記録します

運用原則

1. 形容詞ではなく数値で影響を定量化してください。測定可能なエスカレーションほど、迅速に対応されます。
2. 不具合については、再現手順が必須です。エンジニアリングチームが最も必要としている情報です。
3. 依頼内容を明確にしてください。「調査する」「修正する」「判断する」は、それぞれ担当者が異なる別の依頼です。
4. すべてのエスカレーションに期限を設定してください。期限のない緊急性は曖昧です。
5. 顧客との関係は、常にあなたが責任を持って維持してください。技術作業をエスカレーションしても、その責任が移るわけではありません。
6. 依頼される前にフォローアップしてください。積極的な状況報告は、顧客と引き継ぎ先のチームの両方との信頼を築きます。
7. すべてを記録してください。エスカレーションの記録は、パターンの検出やプロセスの改善に役立つリソースです。