ticket-triage について
サポートチケットを分類し、優先度を設定して担当チームに振り分け、初回返信案を作成するスキルです。チケットの内容と顧客メタデータを使い、振り分けと返信の判断を支援します。
主な機能
- 01チケット本文の整形とエンティティ抽出
- 02意図と感情の判定
- 03請求・バグ・機能要望・使い方の分類
- 04P0〜P3の優先度設定
- 05文脈に応じたチームへの振り分け
- 06初回返信案の作成
活用シーン
- 01受信したサポートチケットの一括整理
- 02影響度に応じた本番障害のエスカレーション
- 03サポート担当者向け初回返信案の準備
- 04添付ファイルのみのチケットの確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/ / github.com/ seb1n/ awesome-ai-agent-skills --skill ticket-triageインストール後、Claude Code で/ticket-triageを入力して読み込まれたか確認します。
詳細
チケットのトリアージ
受信したカスタマーサポートチケットを自動的に分類、優先順位付けし、適切なチームに振り分けるとともに、最初の返信案を作成します。このスキルは生のチケットテキストを処理し、顧客の意図と主要なエンティティ(製品分野、アカウントの契約プラン、エラーコード)を特定して、カテゴリと優先度を割り当てます。その後、適切なチームに振り分け、共感のこもった初回返信を作成します。
ワークフロー
-
チケットを受け取り、解析する — 件名、本文、顧客のメタデータ(アカウントの契約プラン、プラン、利用期間)、添付ファイルやスクリーンショットを含む生のチケットを取り込みます。署名、引用された返信、定型文を削除してテキストを正規化します。注文 ID、エラーコード、URL などの構造化フィールドを抽出します。
-
意図とエンティティを抽出する — 整理済みのチケットテキストを分析し、顧客の主な意図(バグの報告、質問、機能の要望、請求への異議申し立て)を判断します。製品名、機能分野、API エンドポイント、具体的なエラーメッセージなどの固有表現を特定します。感情をポジティブ、ニュートラル、ネガティブ、または緊急としてタグ付けします。
-
カテゴリに分類する — 抽出した意図を、標準カテゴリのいずれかに割り当てます。
billing(請求、請求書、返金、プラン変更)、bug(エラー、クラッシュ、予期しない動作)、feature-request(新機能、インテグレーション、機能強化)、how-to(セットアップ、設定、使い方に関する質問)があります。複数のカテゴリにまたがるチケットには、主要カテゴリを割り当て、副次カテゴリを記録します。 -
影響度と緊急度に基づいて優先度を割り当てる — マトリックスを使って、優先度を P0 から P3 まで評価します。P0:複数の顧客に影響する本番環境の障害またはデータ損失。P1:単一のエンタープライズアカウントで主要な機能が動作しない。P2:回避策があるものの、利用体験が低下している。P3:一般的な質問または軽微な外観上の問題。アカウントの契約プランも考慮し、エンタープライズアカウントには優先度を 1 段階引き上げて割り当てます。
-
適切なチームに振り分ける — カテゴリと優先度をチームに対応付けます。請求に関するチケットは Finance Support キューに、バグは P0/P1 の場合は Engineering Triage に、P2/P3 の場合は Product Support に振り分けます。機能リクエストは Product Management に、使い方に関するチケットは Customer Education に振り分けます。関連するコンテキストと内部メモを添付します。
-
初回返信を作成する — 問題を認識し、優先度に応じた回答時間の目安を伝え、すぐに利用できるセルフサービスリソース(ナレッジベースの記事、ステータスページへのリンク)を含め、チケットの内容が曖昧な場合は確認事項を尋ねる最初の返信案を作成します。感情に合わせてトーンを調整し、不満を抱えた顧客には共感を示し、技術的なユーザーには簡潔に伝えます。
使用方法
サポートチケット(または複数のチケット)を提示し、エージェントにトリアージを依頼してください。優先度をより適切に割り当てるには、可能な場合は顧客のメタデータも含めてください。
Triage these support tickets and output a classification table with category,
priority, assigned team, and a draft first response for each.
例
例1:5件のチケットを一括トリアージ
入力: 過去1時間以内のサポートチケット5件。
出力:
| # | 件名 | カテゴリ | 優先度 | チーム | 推奨する返信 |
|---|---|---|---|---|---|
| 1 | "今朝からログインできません" | bug | P1 | Engineering Triage | "こんにちは、Sarahさん。アカウントにアクセスできないとのことで、申し訳ありません。エンジニアリングチームにエスカレーションし、現在調査中です。一時的な対処法として、ブラウザーのキャッシュをクリアするか、シークレットウィンドウをお試しください。2時間以内に状況をお知らせします。" |
| 2 | "データをCSVにエクスポートする方法を教えてください" | how-to | P3 | Customer Education | "こんにちは、Jamesさん。ご質問ありがとうございます。設定 → データ → エクスポートからCSVにエクスポートできます。手順はこちらをご覧ください:[link]。うまくいかない場合はお知らせください。" |
| 3 | "3月分が二重に請求されています" | billing | P2 | Finance Support | "こんにちは、Priyaさん。二重請求についてお詫び申し上げます。お客様のアカウントに確認のフラグを付けました。請求チームが3~5営業日以内に返金手続きを行います。確認メールをお送りします。" |
| 4 | "Slackとの連携があると嬉しいです" | feature-request | P3 | Product Management | "こんにちは、Tomさん。ご提案ありがとうございます。Slack連携については、多くのお客様からご要望をいただいています。機能トラッカーにご要望への投票を追加しました。ロードマップに追加された場合はお知らせします。" |
| 5 | "組織全体でダッシュボードが停止しています" | bug | P0 | Engineering Triage | "こんにちは、Alexさん。現在、最優先で対応しています。オンコールのエンジニアリングチームに通知し、現在調査中です。最新情報は status.example.com でご確認ください。30分以内に状況をお知らせします。" |
例2:本番環境での重大な障害の緊急エスカレーション
入力: "緊急:14:32 UTC以降、すべてのAPIリクエストで500エラーが返されています。本番環境に影響しています。エンドユーザー5万人以上に影響が出ています。エンタープライズプランです。"
出力:
- カテゴリ: bug
- 優先度: P0(本番環境の障害、複数のエンドユーザー、エンタープライズアカウント)
- チーム: Engineering Triage → オンコールSREに即時通知
- エスカレーション経路: VP of Engineering、担当CSM、アカウントエグゼクティブに自動通知
- SLAの計測: 最初の応答は15分以内、状況更新は1時間ごと
- 返信の下書き: "こんにちは。最優先事項として対応しています。SREチームに通知し、14:32 UTCに発生した500エラーを調査中です。15分以内に最初の状況報告をお送りします。リアルタイムの更新は status.example.com でご確認ください。問題が解決するまで、私が窓口を担当します。"
ベストプラクティス
- 優先度を割り当てる前に、必ず顧客アカウントのプランを確認してください。本番環境に影響があるエンタープライズ顧客の優先度をP1未満にしてはいけません。
- 請求とバグの両方にまたがるチケット(例:「動作しない機能に対して請求されました」)には、2つ目のカテゴリタグを使用して、両チームが状況を把握できるようにしてください。
- 抽出したエンティティをナレッジベースのインデックスと照合し、関連するKB記事へのリンクを最初の返信にあらかじめ含めてください。
- 顧客から1時間以内に返信があったチケットは再トリアージしてください。追加情報によってカテゴリや優先度が変わることがよくあります。
- トリアージの判断とその理由を記録し、人間のレビュー担当者による修正をモデルのファインチューニングに活用してください。
- 自動エスカレーションルールを設定してください。15分以内に確認されないP0は、オンコールマネージャーに通知してください。
エッジケース
- 複数の意図を含むチケット — 1つのチケットにバグ報告と請求に関する異議申し立ての両方が含まれています。優先度の高い意図に分類し、二次的な問題についてリンクされたチケットを作成します。
- スパムまたはベンダーからの営業連絡 — サポート経由で送られてきたマーケティングメールやベンダーからの売り込みに該当するチケットです。
spamに分類して自動的にクローズし、SLA 指標から除外します。 - 英語以外のチケット — 言語を検出してトリアージ用に翻訳し、該当する言語別のサポートキューがあれば、そこに振り分けます。内部メタデータに元の言語を記録します。
- 同じ顧客からの繰り返しチケット — 24時間以内の重複チケットやフォローアップチケットを検出します。新しいトリアージ項目を作成する代わりに、既存のスレッドに統合します。
- 添付ファイルのみのチケット — 本文が空でスクリーンショットやログファイルが添付されている場合は、信頼度の低い自動分類を行わず、手動レビューの対象としてフラグを付けます。