エンジニアリング、プロダクト、またはリーダーシップチームへ、全体的な背景を含めて課題をエスカレーション（上位者への報告）する際に使用します。 次のような場合に使用: - バグが通常のサポート範囲を超えた対応が必要な場合 - 複数の顧客が同じ問題を報告している場合 - 顧客が契約解除をほのめかしている場合 - 問題が対応期限（SLA）を超えて未解決のままになっている場合
Package an escalation for engineering, product, or leadership with full context. Use when a bug needs engineering attention beyond normal support, multiple customers report the same issue, a customer is threatening to churn, or an issue has sat unresolved past its SLA.
見慣れないプレースホルダーが含まれている場合や、接続中のツールを確認したい場合は、CONNECTORS.md を参照してください。
サポートの問題を、エンジニアリング・プロダクト・リーダーシップ向けの構造化されたエスカレーションブリーフにまとめるコマンドです。 コンテキストの収集、再現手順の整理、ビジネスインパクトの評価、適切なエスカレーション先の特定を行います。
/customer-escalation <問題の説明> [顧客名またはアカウント]
例：
/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入力内容を解析し、以下を明確にします：
後述の「エスカレーションすべき場合とサポートで対応すべき場合の判断基準」を参照し、エスカレーションが妥当かどうかを確認してください。
利用可能なソースから関連情報を集めます：
後述のインパクト指標を参考に、以下を定量的に把握します：
後述のエスカレーションティアを参照し、適切な対象を特定します： L2サポート、エンジニアリング、プロダクト、セキュリティ、またはリーダーシップ。
問題がバグである場合は、後述の再現手順のベストプラクティスに従い、環境情報やエビデンスを含めた明確な再現手順を記載します。
## ESCALATION: [一文でまとめた概要]
**Severity（深刻度）:** [Critical / High / Medium]
**Target team（対象チーム）:** [Engineering / Product / Security / Leadership]
**Reported by（報告者）:** [自分の名前・チーム]
**Date（日付）:** [今日の日付]
### Impact（インパクト）
- **Customers affected（影響を受けた顧客）:** [誰が・何人]
- **Workflow impact（業務への影響）:** [何ができなくなっているか]
- **Revenue at risk（収益リスク）:** [該当する場合]
- **Time in queue（待機時間）:** [問題が発生してからの経過時間]
### Issue Description（問題の説明）
[問題の明確・簡潔な説明 — 3〜5文程度]
### What's Been Tried（試みた対応）
1. [トラブルシューティングの手順と結果]
2. [トラブルシューティングの手順と結果]
3. [トラブルシューティングの手順と結果]
### Reproduction Steps（再現手順）
[該当する場合 — 以下のフォーマットに従うこと]
1. [手順]
2. [手順]
3. [手順]
Expected（期待される動作）: [X]
Actual（実際の動作）: [Y]
Environment（環境）: [詳細]
### Customer Communication（顧客とのコミュニケーション）
- **Last update to customer（顧客への最終連絡）:** [日時と伝えた内容]
- **Customer expectation（顧客の期待）:** [何をいつまでに期待しているか]
- **Escalation risk（さらなるエスカレーションのリスク）:** [X日までに解決しなければ顧客が上位にエスカレーションするか？]
### What's Needed（必要な対応）
- [具体的な依頼内容 — 例：「根本原因の調査」「修正の優先対応」
「Xに関するプロダクト上の意思決定」「Yの例外承認」]
- **Deadline（期限）:** [解決またはアップデートが必要な日時]
### Supporting Context（補足情報）
- [関連チケットやリンク]
- [社内ディスカッションのスレッド]
- [ドキュメントやログ]
エスカレーションブリーフ生成後、以下を提案します：
From: フロントラインサポート To: シニアサポート / テクニカルサポートスペシャリスト 次のような場合に使用: 深い調査、専門的なプロダクト知識、高度なトラブルシューティングが必要な場合 含めるべき情報: チケットの概要、試みた手順、顧客のコンテキスト
From: シニアサポート To: エンジニアリングチーム（関連するプロダクト領域） 次のような場合に使用: バグが確認された場合、インフラの問題、コード変更が必要な場合、システムレベルの調査が必要な場合 含めるべき情報: 完全な再現手順、環境の詳細、ログまたはエラーメッセージ、ビジネスインパクト、顧客のタイムライン
From: シニアサポート To: プロダクトマネジメント 次のような場合に使用: 顧客の課題となっている機能ギャップがある、設計上の意思決定が必要、ワークフローが顧客の期待と合っていない、優先順位の決定が必要な顧客ニーズの競合がある 含めるべき情報: 顧客のユースケース、ビジネスインパクト、リクエストの頻度、競合状況（把握している場合）
From: 任意のサポートティア To: セキュリティチーム 次のような場合に使用: データ漏洩の可能性、不正アクセス、脆弱性の報告、コンプライアンス上の懸念がある場合 含めるべき情報: 観察された事象、潜在的な影響範囲（誰・何が影響を受けるか）、実施済みの初期封じ込め措置、緊急度の評価 注意: セキュリティのエスカレーションは通常のティア進行をバイパスします。自分のレベルに関わらず、直ちにエスカレーションしてください。
From: 任意のティア（通常はL2またはマネージャー） To: サポートリーダーシップ、エグゼクティブチーム 次のような場合に使用: 高収益顧客が解約を示唆している、重要アカウントでSLA違反が発生した、クロスファンクショナルな意思決定が必要、ポリシーの例外承認が必要、PRまたは法的リスクがある場合 含めるべき情報: ビジネス上の全コンテキスト、収益リスク、試みた対応、必要な具体的意思決定または行動、期限
エスカレーション時は、可能な限りインパクトを定量化してください。
| 指標 | 確認すべき質問 |
|---|---|
| 範囲（Breadth） | 何人の顧客・ユーザーが影響を受けているか？拡大しているか？ |
| 深刻度（Depth） | どの程度深刻な影響か？業務が完全に止まっているか、不便を感じている程度か？ |
| 期間（Duration） | どのくらい続いているか？いつ頃クリティカルになるか？ |
| 収益（Revenue） | ARRへのリスクは？商談中の案件への影響は？ |
| 評判（Reputation） | 公になる可能性はあるか？リファレンス顧客か？ |
| 契約（Contractual） | SLAが違反されているか？契約上の義務はあるか？ |
適切な再現手順は、バグエスカレーションで最も価値ある情報です。以下のベストプラクティスに従ってください：
If you see unfamiliar placeholders or need to check which tools are connected, see CONNECTORS.md.
Package a support issue into a structured escalation brief for engineering, product, or leadership. Gathers context, structures reproduction steps, assesses business impact, and identifies the right escalation target.
/customer-escalation <issue description> [customer name or account]
Examples:
/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 featureParse the input and determine:
Use the "When to Escalate vs. Handle in Support" criteria below to confirm this warrants escalation.
Pull together relevant information from available sources:
Using the impact dimensions below, quantify:
Using the escalation tiers below, identify the right target: L2 Support, Engineering, Product, Security, or Leadership.
If the issue is a bug, follow the reproduction step best practices below to document clear repro steps with environment details and evidence.
## 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]
After generating the escalation:
From: Frontline support To: Senior support / technical support specialists When: Issue requires deeper investigation, specialized product knowledge, or advanced troubleshooting What to include: Ticket summary, steps already tried, customer context
From: Senior support To: Engineering team (relevant product area) When: Confirmed bug, infrastructure issue, needs code change, requires system-level investigation What to include: Full reproduction steps, environment details, logs or error messages, business impact, customer timeline
From: Senior support To: Product management When: Feature gap causing customer pain, design decision needed, workflow doesn't match customer expectations, competing customer needs require prioritization What to include: Customer use case, business impact, frequency of request, competitive pressure (if known)
From: Any support tier To: Security team When: Potential data exposure, unauthorized access, vulnerability report, compliance concern What to include: What was observed, who/what is potentially affected, immediate containment steps taken, urgency assessment Note: Security escalations bypass normal tier progression — escalate immediately regardless of your level
From: Any tier (usually L2 or manager) To: Support leadership, executive team When: High-revenue customer threatening churn, SLA breach on critical account, cross-functional decision needed, exception to policy required, PR or legal risk What to include: Full business context, revenue at risk, what's been tried, specific decision or action needed, deadline
When escalating, quantify impact where possible:
| Dimension | Questions to Answer |
|---|---|
| Breadth | How many customers/users are affected? Is it growing? |
| Depth | How severely are they impacted? Blocked vs. inconvenienced? |
| Duration | How long has this been going on? How long until it's critical? |
| Revenue | What's the ARR at risk? Are there pending deals affected? |
| Reputation | Could this become public? Is it a reference customer? |
| Contractual | Are SLAs being breached? Are there contractual obligations? |
Good reproduction steps are the single most valuable thing in a bug escalation. Follow these practices:
Don't escalate and forget. Maintain ownership of the customer relationship.
| Severity | Internal Follow-up | Customer Update |
|---|---|---|
| Critical | Every 2 hours | Every 2-4 hours (or per SLA) |
| High | Every 4 hours | Every 4-8 hours |
| Medium | Daily | Every 1-2 business days |
Not every escalation stays escalated. De-escalate when:
When de-escalating:
原文・著作権は Anthropic および各プラグイン作者に帰属します。日本語訳は Claude API による自動翻訳です。