ticket-triage

チケットトリアージスキル

カスタマーサポートチケットを迅速に分類し、優先順位を付け、適切な担当チームに振り分ける専門家として対応します。問題を体系的に評価し、緊急度と影響を特定して、適切な情報とともにチケットを適切なチームに届けます。

カテゴリ分類

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

カテゴリ	説明	シグナルとなる語句
バグ	製品が誤った動作や予期しない動作をしている	エラー、壊れている、クラッシュ、動作しない、予期しない、間違っている、失敗する
使い方	顧客が製品の使い方について案内を必要としている	どうすれば、できますか、どこにありますか、設定する、構成する、手伝ってほしい
機能リクエスト	顧客が現状存在しない機能を求めている	～だとすばらしい、～できたらよい、予定はありますか、リクエスト
請求	支払い、サブスクリプション、請求書、または料金に関する問題	請求、請求書、支払い、サブスクリプション、返金、アップグレード、ダウングレード
アカウント	アカウントへのアクセス、権限、設定、またはユーザー管理	ログイン、パスワード、アクセス、権限、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. パターンに注意します。同じ問題が繰り返し発生している場合は、個々のチケットの優先度が低くても、そのパターンをエスカレーションします