ticket-triage

/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. 分類して優先順位を付ける

以下のカテゴリ体系と優先順位フレームワークを使用します。

• 主カテゴリ（バグ、使い方、機能リクエスト、請求、アカウント、インテグレーション、セキュリティ、データ、パフォーマンス）を割り当て、必要に応じて副カテゴリも割り当てます
• 影響度と緊急性に基づいて優先度（P1～P4）を割り当てます
• 問題に該当する製品領域を特定します

3. 重複と既知の問題を確認する

振り分ける前に、利用可能な情報源を確認します。

• ~~サポートプラットフォーム：類似する未解決または最近解決したチケットを検索します
• ~~ナレッジベース：既知の問題や既存のドキュメントを確認します
• ~~プロジェクトトラッカー：既存のバグ報告や機能リクエストがあるか確認します

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

4. 振り分け先を決定する

以下の振り分けルールに従い、カテゴリと複雑さに基づいて、対応すべきチームまたはキューを推奨します。

5. トリアージ結果を作成する

## Triage: [One-line issue summary]

**Category:** [Primary] / [Secondary if applicable]
**Priority:** [P1-P4] — [Brief justification]
**Product area:** [Area/team]

### Issue Summary
[2-3 sentence summary of what the customer is experiencing]

### Key Details
- **Customer:** [Name/account if known]
- **Impact:** [Who and what is affected]
- **Workaround:** [Available / Not available / Unknown]
- **Related tickets:** [Links to similar issues if found]
- **Known issue:** [Yes — link / No / Checking]

### Routing Recommendation
**Route to:** [Team or queue]
**Why:** [Brief reasoning]

### Suggested Initial Response
[Draft first response to the customer — acknowledge the issue,
set expectations, provide workaround if available.
Use the auto-response templates below as a starting point.]

### Internal Notes
- [Any additional context for the agent picking this up]
- [Reproduction hints if it's a bug]
- [Escalation triggers to watch for]

6. 次のステップを提案する

トリアージ結果を提示した後、次のように確認します。

• 「顧客への返信全文を作成しましょうか？」
• 「この問題について、さらに詳しく調べましょうか？」
• 「トラッカーで既知のバグかどうか確認しましょうか？」
• 「エスカレーションしますか？/customer-escalation を使って情報をまとめられます。」

---

カテゴリ体系

すべてのチケットに主カテゴリを割り当て、必要に応じて副カテゴリも割り当てます。

カテゴリ	説明	該当するキーワード
バグ	製品が正しくない、または予期しない動作をしている	エラー、故障、クラッシュ、動作しない、予期しない、誤り、失敗
使い方	顧客が製品の使用方法について案内を必要としている	どうすれば、できますか、どこにありますか、設定、構成、手伝って
機能リクエスト	顧客が現状存在しない機能を求めている	～なら便利、～できたらいいのに、予定はありますか、リクエスト
請求	支払い、サブスクリプション、請求書、または料金に関する問題	請求、請求書、支払い、サブスクリプション、返金、アップグレード、ダウングレード
アカウント	アカウントへのアクセス、権限、設定、またはユーザー管理に関する問題	ログイン、パスワード、アクセス、権限、SSO、ロックアウト、サインインできない
インテグレーション	サードパーティ製ツールや API への接続に関する問題	API、Webhook、インテグレーション、接続、OAuth、同期、サードパーティ
セキュリティ	セキュリティ上の懸念、データアクセス、またはコンプライアンスに関する質問	データ侵害、不正アクセス、コンプライアンス、GDPR、SOC 2、脆弱性
データ	データの品質、移行、インポート／エクスポートに関する問題	データの欠落、エクスポート、インポート、移行、不正確なデータ、重複
パフォーマンス	速度、信頼性、または可用性に関する問題	遅い、タイムアウト、レイテンシ、停止、利用不可、性能低下

カテゴリ判定のヒント

• お客様からバグと機能リクエストの両方が報告された場合は、バグを優先します
• バグが原因でログインできない場合、カテゴリはバグ（アカウントではありません）です。根本原因に基づいてカテゴリを決めます
• 「以前は動作していたのに、今は動作しない」＝バグ
• 「別の動作をするようにしたい」＝機能リクエスト
• 「動作させるにはどうすればよいですか？」＝使い方
• 判断に迷う場合は、バグ寄りにします。却下するより調査するほうが適切です

優先度の枠組み

P1 — 重大

基準： 本番システムの停止、データの損失または破損、セキュリティ侵害、すべてまたは大半のユーザーへの影響。

• お客様が製品をまったく利用できない
• データが失われている、破損している、または漏えいしている
• セキュリティインシデントが進行中である
• 問題が悪化している、または影響範囲が拡大している

SLA の目安： 1 時間以内に返信します。解決または緩和されるまで継続して対応します。1～2 時間ごとに状況を更新します。

P2 — 高

基準： 主要機能の故障、重要なワークフローの停滞、多数のユーザーへの影響、回避策がない。

• コアワークフローが機能していないが、製品は部分的に利用できる
• 複数のユーザー、または重要なアカウントに影響している
• 時間的制約のある作業が妨げられている
• 妥当な回避策がない

SLA の目安： 4 時間以内に返信します。当日中に積極的に調査します。4 時間ごとに状況を更新します。

P3 — 中

基準： 機能の一部が正常に動作しない、回避策がある、単一のユーザーまたは小規模チームへの影響。

• 機能が正しく動作していないが、回避策がある
• 問題は不便だが、重要な作業を妨げるものではない
• 単一のユーザーまたは小規模チームに影響している
• お客様から緊急のエスカレーションがない

SLA の目安： 1 営業日以内に返信します。3 営業日以内に解決するか、状況を更新します。

P4 — 低

基準： 軽微な不便、見た目の問題、一般的な質問、機能リクエスト。

• 機能に影響しない見た目や UI の問題
• 機能リクエストや改善案
• 一般的な質問や使い方に関する問い合わせ
• 簡単で文書化された解決策がある問題

SLA の目安： 2 営業日以内に返信します。通常のペースで解決します。

優先度のエスカレーショントリガー

次の場合は、自動的に優先度を引き上げます。

• お客様が SLA の許容時間を超えて待っている
• 複数のお客様から同じ問題が報告されている（パターンを検出）
• お客様が明示的にエスカレーションする、または経営幹部の関与に言及する
• 実施されていた回避策が機能しなくなる
• 問題の影響範囲が拡大する（ユーザーの増加、データの増加、新たな症状の発生）

振り分けルール

カテゴリと複雑さに基づいてチケットを振り分けます。

振り分け先	対象
Tier 1（一次サポート）	使い方に関する質問、解決策が文書化された既知の問題、請求に関する問い合わせ、パスワードのリセット
Tier 2（シニアサポート）	調査が必要なバグ、複雑な設定、インテグレーションのトラブルシューティング、アカウントの問題
エンジニアリング	コード修正が必要と確認されたバグ、インフラストラクチャの問題、パフォーマンスの低下
プロダクト	需要が大きい機能リクエスト、設計上の判断、ワークフローの不足
セキュリティ	データアクセスに関する懸念、脆弱性の報告、コンプライアンスに関する質問
請求／財務	返金リクエスト、契約上の紛争、複雑な請求調整

重複の検出

新しいチケットの作成または振り分けの前に、重複がないか確認します。

1. 症状で検索する：似たエラーメッセージや説明のチケットを探します
2. お客様で検索する：同じ問題について、このお客様の未解決チケットがあるか確認します
3. 製品領域で検索する：同じ機能領域の最近のチケットを探します
4. 既知の問題を確認する：文書化された既知の問題と照合します

重複が見つかった場合：

• 新しいチケットを既存のチケットにリンクします
• 追跡中の既知の問題であることをお客様に知らせます
• 新しい報告に含まれる追加情報を既存のチケットに加えます
• 新しい報告によって緊急性が高まる場合（影響を受けるお客様が増えるなど）は、優先度を引き上げます

カテゴリ別の自動返信テンプレート

バグ — 初回返信

Thank you for reporting this. I can see how [specific impact]
would be disruptive for your work.

I've logged this as a [priority] issue and our team is
investigating. [If workaround exists: "In the meantime, you
can [workaround]."]

I'll update you within [SLA timeframe] with what we find.

ハウツー — 初回応答

Great question! [Direct answer or link to documentation]

[If more complex: "Let me walk you through the steps:"]
[Steps or guidance]

Let me know if that helps, or if you have any follow-up
questions.

機能リクエスト — 初回応答

Thank you for this suggestion — I can see why [capability]
would be valuable for your workflow.

I've documented this and shared it with our product team.
While I can't commit to a specific timeline, your feedback
directly informs our roadmap priorities.

[If alternative exists: "In the meantime, you might find
[alternative] helpful for achieving something similar."]

請求 — 初回応答

I understand billing issues need prompt attention. Let me
look into this for you.

[If straightforward: resolution details]
[If complex: "I'm reviewing your account now and will have
an answer for you within [timeframe]."]

セキュリティ — 初回応答

Thank you for flagging this — we take security concerns
seriously and are reviewing this immediately.

I've escalated this to our security team for investigation.
We'll follow up with you within [timeframe] with our findings.

[If action is needed: "In the meantime, we recommend
[protective action]."]

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

1. 分類する前にチケット全体を読みます。後続のメッセージに含まれるコンテキストによって、評価が変わることがよくあります。
2. 説明されている症状だけでなく、根本原因に基づいて分類します。
3. 優先度に迷った場合は、高めに設定します。優先度を下げるほうが、SLA の見落としを取り戻すより簡単です。
4. 振り分ける前に、重複や既知の問題がないか必ず確認します。
5. 次の担当者がすぐに状況を把握できるよう、内部メモを記入します。
6. 調査の重複を避けるため、すでに確認したことや除外した可能性を記載します。
7. パターンを見逃さないようにします。同じ問題が繰り返し発生している場合は、個々のチケットの優先度が低くても、その傾向をエスカレーションします。