/ticket-triage

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

受信したサポートチケットまたはカスタマーイシューを分類、優先度付け、ルーティングします。構造化されたトリアージ評価と推奨される初期対応を生成します。

使用方法

/ticket-triage <ticket text, customer message, or issue description>

使用例:

• /ticket-triage Customer says their dashboard has been showing a blank page since this morning
• /ticket-triage "I was charged twice for my subscription this month"
• /ticket-triage User can't connect their SSO — getting a 403 error on the callback URL
• /ticket-triage Feature request: they want to export reports as PDF

ワークフロー

1. イシューを解析する

入力内容から以下を抽出します:

• 中核的な問題: 顧客が実際に経験していることは何か?
• 症状: 具体的にどのような動作またはエラーが見えているか?
• カスタマーコンテキスト: 誰か? 利用可能なアカウント詳細、プランレベル、または履歴があるか?
• 緊急度シグナル: ブロックされているか? 本番環境か? 影響を受けるユーザーは何人か?
• 感情状態: イライラしているか、混乱しているか、事務的か、エスカレートしているか?

2. 分類と優先度付け

以下のカテゴリー分類とプライオリティフレームワークを使用して:

• 主要カテゴリー (bug、how-to、feature request、billing、account、integration、security、data、performance) を割り当て、必要に応じてセカンダリカテゴリーも指定
• 優先度 (P1～P4) を影響度と緊急度に基づいて割り当て
• イシューが該当するプロダクトエリアを特定

3. 重複と既知の問題をチェック

ルーティング前に、利用可能なソースをチェック:

• ~~サポートプラットフォーム: 類似したオープンまたは最近解決されたチケットを検索
• ~~ナレッジベース: 既知の問題または既存ドキュメントをチェック
• ~~プロジェクトトラッカー: 既存のバグレポートまたはフィーチャーリクエストがあるかチェック

下記の重複検出プロセスを適用します。

4. ルーティングを決定

下記のルーティングルールを使用して、カテゴリーと複雑さに基づいてどのチームまたはキューが対応すべきかを推奨します。

5. トリアージ出力を生成

## Triage: [ワンラインのイシュー概要]

**Category:** [プライマリ] / [該当する場合はセカンダリ]
**Priority:** [P1-P4] — [簡潔な理由]
**Product area:** [エリア/チーム]

### Issue Summary
[顧客が経験していることの 2～3 文での要約]

### Key Details
- **Customer:** [わかっている場合は名前/アカウント]
- **Impact:** [影響を受けるものと対象]
- **Workaround:** [利用可能 / 利用不可 / 不明]
- **Related tickets:** [重複が見つかった場合はリンク]
- **Known issue:** [Yes — link / No / Checking]

### Routing Recommendation
**Route to:** [チームまたはキュー]
**Why:** [簡潔な理由]

### Suggested Initial Response
[顧客への最初の対応案ドラフト — イシューを認識し、期待値を設定し、
利用可能な場合は回避策を提供します。下記の自動応答テンプレートを
出発点として使用します。]

### Internal Notes
- [このチケットをピックアップするエージェント向けの追加コンテキスト]
- [バグの場合は再現ヒント]
- [監視するエスカレーショントリガー]

6. 次のステップを提案

トリアージを提示した後:

• "顧客への完全な対応案をドラフトしましょうか?"
• "このイシューについてさらに詳しく検索してみましょうか?"
• "これが既知のバグかトラッカーで確認してみましょうか?"
• "エスカレートしましょうか? /customer-escalation でパッケージ化できます。"

---

カテゴリー分類

すべてのチケットに主要カテゴリーを割り当て、必要に応じてセカンダリカテゴリーも割り当てます:

カテゴリー	説明	シグナルワード
Bug	プロダクトが正しく、または予想通りに動作していない	Error、broken、crash、not working、unexpected、wrong、failing
How-to	カスタマーがプロダクト使用のガイダンスが必要	How do I、can I、where is、setting up、configure、help with
Feature request	カスタマーが存在しない機能を望んでいる	Would be great if、wish I could、any plans to、requesting
Billing	支払い、サブスクリプション、請求書、または価格設定の問題	Charge、invoice、payment、subscription、refund、upgrade、downgrade
Account	アカウントアクセス、権限、設定、またはユーザー管理	Login、password、access、permission、SSO、locked out、can't sign in
Integration	サードパーティツールまたは API への接続の問題	API、webhook、integration、connect、OAuth、sync、third-party
Security	セキュリティ関連の懸念、データアクセス、またはコンプライアンス質問	Data breach、unauthorized、compliance、GDPR、SOC 2、vulnerability
Data	データ品質、移行、インポート/エクスポート問題	Missing data、export、import、migration、incorrect data、duplicates
Performance	スピード、信頼性、または可用性の問題	Slow、timeout、latency、down、unavailable、degraded

カテゴリー判定のコツ

• カスタマーがバグとフィーチャーリクエストの両方を報告した場合、バグがプライマリ
• バグのためにログインできない場合、カテゴリーは Bug (Account ではない) — 根本原因がカテゴリーを決定
• "以前は動作していたが今は動作していない" = Bug
• "異なる方法で動作してほしい" = Feature request
• "どうやって動作させるか?" = How-to
• 不明な場合は Bug に傾ける — 却下するより調査する方が良い

プライオリティフレームワーク

P1 — クリティカル

基準: 本番システムダウン、データ損失または破損、セキュリティ侵害、全部またはほぼすべてのユーザーが影響を受ける。

• カスタマーがプロダクトをまったく使用できない
• データが失われている、破損している、または公開されている
• セキュリティインシデントが進行中
• イシューが悪化している、またはスコープが拡大している

SLA 期待値: 1 時間以内に対応。解決またはミティゲーションまで継続的に作業。1～2 時間ごとに更新。

P2 — 高

基準: 主要フィーチャーが破損、重要なワークフローがブロック、多くのユーザーが影響、回避策なし。

• コアワークフローが破損しているがプロダクトは部分的に使用可能
• 複数のユーザーが影響を受けている、またはキーアカウントが影響を受けている
• イシューが時間に敏感な作業をブロックしている
• 妥当な回避策が存在しない

SLA 期待値: 4 時間以内に対応。同日に積極的に調査。4 時間ごとに更新。

P3 — 中

基準: フィーチャーが部分的に破損、回避策あり、単一ユーザーまたは小さなチームが影響。

• フィーチャーが正常に動作していないが回避策が存在する
• イシューは不便だが重要な作業をブロックしていない
• 単一ユーザーまたは小さなチームが影響を受けている
• カスタマーが緊急にエスカレートしていない

SLA 期待値: 1 営業日以内に対応。3 営業日以内に解決または更新。

P4 — 低

基準: 軽微な不便、コスメティック問題、一般的な質問、フィーチャーリクエスト。

• 機能に影響を与えないコスメティックまたは UI の問題
• フィーチャーリクエストと機能強化のアイデア
• 一般的な質問または how-to の質問
• シンプルで記載されたソリューションのある問題

SLA 期待値: 2 営業日以内に対応。通常のペースで解決。

プライオリティエスカレーショントリガー

以下の場合は自動的に優先度を上げます:

• カスタマーが SLA で許可された時間より長く待機している
• 複数のカスタマーが同じイシューを報告している (パターンが検出された)
• カスタマーが明示的にエスカレートしているか、経営幹部関与を言及している
• 機能していた回避策が機能しなくなった
• イシューのスコープが拡大している (より多くのユーザー、より多くのデータ、新しい症状)

ルーティングルール

カテゴリーと複雑さに基づいてチケットをルーティング:

ルーティング先	条件
Tier 1 (frontline support)	How-to の質問、記載されたソリューションがある既知の問題、請求のお問い合わせ、パスワードリセット
Tier 2 (senior support)	調査が必要なバグ、複雑な設定、統合のトラブルシューティング、アカウント問題
Engineering	確認されたコード修正が必要なバグ、インフラストラクチャの問題、パフォーマンスの低下
Product	大きな需要があるフィーチャーリクエスト、デザイン判断、ワークフローギャップ
Security	データアクセスの懸念、脆弱性レポート、コンプライアンス質問
Billing/Finance	払い戻しリクエスト、契約紛争、複雑な請求調整

重複検出

新しいチケットを作成またはルーティングする前に、重複をチェック:

1. 症状で検索: 類似したエラーメッセージまたは説明を持つチケットを探す
2. カスタマーで検索: このカスタマーが同じイシューのオープンチケットを持っているか確認
3. プロダクトエリアで検索: 同じフィーチャーエリアで最近のチケットを探す
4. 既知の問題をチェック: 記載されている既知の問題と比較

重複が見つかった場合:

• 新しいチケットを既存のものにリンク
• カスタマーにこれが追跡中の既知の問題であることを通知
• 新しいレポートからの新しい情報を既存のチケットに追加
• 新しいレポートが緊急度を増す場合は優先度をバンプ (より多くのカスタマーが影響を受けているなど)

カテゴリー別自動応答テンプレート

Bug — 初期対応

このことをご報告いただきありがとうございます。[具体的な影響] がご利用に
支障をきたすことはよく理解できます。

これを [優先度] のイシューとして記録し、チームが調査しています。
[回避策が存在する場合: 「それまでの間、[回避策] を使用できます。」]

[SLA 期間] 以内に検出結果で更新いたします。

How-to — 初期対応

ご質問ありがとうございます! [直接的な回答またはドキュメントへのリンク]

[より複雑な場合: 「ステップを説明させていただきます:」]
[ステップまたはガイダンス]

これがお役に立てば幸いですが、フォローアップの質問があればお知らせください。

Feature request — 初期対応

このご提案をいただきありがとうございます — [機能] がご利用のワークフローにとって
有用である理由はよく理解できます。

これを記録し、プロダクトチームと共有いたしました。具体的なタイムラインを
お約束することはできませんが、ご意見はロードマップ優先順位付けに直接影響します。

[代替案が存在する場合: 「一方、[代替案] は同様のものを実現するのに役立つかもしれません。」]

Billing — 初期対応

請求の問題には迅速な対応が必要であることは理解しています。
これについてお調べさせていただきます。

[単純明快な場合: 解決の詳細]
[複雑な場合: 「ただいまアカウントを確認中で、[時間枠] 以内に回答いたします。」]

Security — 初期対応

これをフラグアップしていただきありがとうございます — セキュリティの懸念は
非常に真摯に受け止め、即座に確認しています。

これをセキュリティチームにエスカレートして調査いただいています。
[時間枠] 以内に調査結果をお知らせいたします。

[アクションが必要な場合: 「それまでの間、[保護措置] をお勧めいたします。」]

トリアージベストプラクティス

1. カテゴリー付けする前にチケット全体を読む — 後のメッセージのコンテキストは評価を変えることが多い
2. 説明された症状ではなく根本原因によってカテゴリー付け
3. 優先度で不明な場合は、より高い側に偏ける — デエスカレートする方が SLA を見逃して回復するより簡単
4. ルーティング前に常に重複と既知の問題をチェック
5. 次の人がコンテキストをすばやくピックアップするのに役立つ内部メモを記述
6. 既にチェックした、または除外した内容を含めて、重複調査を回避
7. パターンにフラグを立てる — 同じイシューを繰り返し見ている場合、個々のチケットが低優先度であってもパターンをエスカレート