リクエストの要約と分類 (チケットのトリアージ)

利益:

• 長く散在する顧客リクエストを構造化された実用的な要約に変換する能力
• 固定スキーマを使用して、カテゴリ、緊急度、顧客感情に従ってリクエストを分類する機能
• 一括チケット処理の自動化に適した一貫した出力形式 (JSON/テーブル) を定義する機能

サポート チームの朝を想像してください。一晩で 220 枚の新しいチケット (チケット) が蓄積されました。 「パスワードを忘れました」という 1 行の内容もあれば、3 段落にわたる怒りの苦情もあれば、実際に販売機会を提供するものもあります。この山を読み、それぞれを正しいカテゴリに割り当て、緊急度を判断し、適切な担当者に指示する (これはトリアージと呼ばれます。救急治療室で優先順位に従って患者を分類するのと同じロジックです) と、1 日の最初の 2 時間を費やします。

人工知能 (AI) はこの仕事を数秒で一貫して実行できます。しかし、魔法は「このリクエストを要約してください」と言うことではありません。カテゴリの固定リスト、明確な緊急度、および不変の出力形式をモデルに課します。この単元では、自動化対応の方法で 1 つのリクエストの処理から数百のリクエストのラベル付けまでを行うトリアージ システムを確立します。

注: AI によって生成されたカテゴリと緊急度のラベルは、事前のスクリーニング ツールです。特に、「緊急」および「苦情」とラベル付けされたリクエストは、処理される前に人間によって確認される必要があります。

なぜ構造化された要約なのか?

無料の概要 (「顧客が荷物に問題を抱えています」) は、検索、並べ替え、自動化できません。ただし、サポート マネージャーの必要性は、次の点から明らかです。

• このリクエストはどのカテゴリに分類されますか? (発送、返品、支払い、技術、製品情報、苦情、販売機会)
• どれくらい緊急ですか? (重大 / 高 / 中 / 低)
• 顧客の心理状態はどのようなものですか? (怒り / 失望 / 中立 / 満足)
• その一文の本質とは何でしょうか？
• 次のステップは何でしょうか?

これらの質問を事前に定義し、スキーマ (定数フィールドと可能な値) としてモデルに与えると、220 個のリクエストすべてが同じ形式で比較可能になり、フィルター可能になります。

ステップバイステップ: トリアージスキームの確立

1. カテゴリリストを固定します。モデルを当てはめてはいけません。閉じたリストを与えてください。
2. 緊急性の基準を定義します。 「重大」が何を意味するかを具体的に説明します: サービスが完全に停止した、支払いの損失、セキュリティ リスク。
3. 感情のラベルを特定します。限定的で明確なセットを使用してください。
4. 出力形式をインポートします。バッチ処理の場合は JSON (フィールドと値のペアで構成される機械読み取りデータ形式) が適しており、単一のリクエストの場合はテーブルが適しています。
5. 「よくわからない場合はチェックを入れる」ルールを作りましょう。モデルがカテゴリを不明な場合は、「不明」と言って人間が調べます。
6. 確認する。最初のバッチでは、ラベルの精度を手動でチェックし、プロンプトを設定します。

コピー可能なプロンプト

単一のリクエストを構造化された概要に変換する基本的なプロンプト:

役割: あなたは、経験豊富なサポートトリアージスペシャリストです。以下の顧客リクエストを分析します。コメントを追加します。本文の内容を信頼してください。次のフィールドに入力してください:- 概要: (最大 1 文)- カテゴリ: [送料 |戻る |お支払い |技術 |製品情報 |苦情 |販売機会] - 緊急度: [重大 |高 |中 |低い]- 感情: [怒り |失望 |ニュートラル |満足]- next_step: (単一の文、具体的なアクション)- 不明: (カテゴリ/緊急度が不明瞭な場合は「はい」、そうでない場合は「いいえ」) リクエスト:"""{{ request_text }}""

バッチ処理の場合、プロンプトは複数のリクエストを一度に JSON 配列に変換します。

以下の番号付きリクエストを処理します。次のスキーマを使用してそれぞれの JSON オブジェクトを生成し、それらをすべて JSON 配列として返します。スキームの外に出る: { "id": ""、"summary": ""、"category": ""、"urgency": ""、"emotion": ""、"next_step": ""、"I'm not some": "" }カテゴリのみ: 配送、返品、支払い、技術、製品情報、苦情、販売機会。リクエスト: {{numbered_request_list }}

緊急性の基準を明確にし、モデルに「クリティカル」の定義を教えるプロンプト:

次のルールに従って緊急度を決定します。 - 重大: サービスが完全に利用できない、支払いの損失、セキュリティ/データのリスク、法的脅威。 - 高: 重要な機能は壊れていますが、回避策は存在します。怒っている顧客。- 中: 特異な問題、ワークフローは停止していない。- 低: 情報の要求、提案、一般的な質問。 「urgency_reason」欄に決定理由を一文で書きます。

販売機会を捉え、サポート/販売ブリッジを確立するプロンプト:

リクエストを処理する際、顧客が新しい製品/パッケージ/サプリメントの購入に興味を示した場合 (例: 「もっと大きなパッケージはありますか」、「ユーザーは何人必要ですか」)、カテゴリを「販売機会」にし、「sales_note」フィールドに営業チーム向けの 1 文のヒントを追加します。

弱いプロンプト / 強いプロンプト

プロンプトが弱い

強力なプロンプト

「このリクエストを要約して分類してください」

クローズドカテゴリリスト + 緊急度定義 + 固定 JSON スキーマ

毎回異なるラベルを生成します

同じリクエストには常に同じラベルを付けます

彼は「緊急」という言葉を自分の希望に従って使っています。

「重大」の具体的な基準を適用する

彼は曖昧なことをでっち上げます

emin_degilim: 「はい」と言って、その人に任せてください

ここでは一貫性が黄金律です。同じ苦情が 2 つの異なる日に同じカテゴリに分類されない場合、レポートや自動化は信頼できません。

ミニケース3個

ケース 1 — 機密の評論家。 SaaS (インターネットレンタルソフトウェア) 会社では、「ログインできません。チーム全体で 40 人を待っています」というメッセージは、長さが短いため普通に思えました。トリアージ プロンプトでは、緊急性ルール (「サービスが完全に利用不可」基準) のおかげで、「緊急」とマークされました。リクエストはキューで 2 時間待つ代わりに 6 分で処理されました。 SLA (サービス レベル アグリーメント、つまり約束された応答時間) 違反が防止されました。

ケース 2 — 怒りの優先順位付け。ある日、180件のリクエストのAIタグを調べたところ、「怒り」の感情を持つ14件のリクエストが別のキューに入れられていることが判明した。これらのリクエストは経験豊富な代表者に向けられたもので、その週のネガティブな調査スコア (CSAT、つまり顧客満足度スコア) は前週に比べて大幅に改善されました。

ケース 3 — サポートから販売への橋渡し。 「現在のパッケージは 5 ユーザー用ですが、20 名まで増やす必要がありますが、可能ですか?」 AI はメッセージに「販売機会」のタグを付け、販売メモを追加しました。リクエストは自動的に営業チームに渡されました。標準サポートのキューに埋もれていれば気づかれなかったであろうアップセルの機会が得られるようになりました。

ヒント: カテゴリ リストはできるだけ短く、個別のものにしてください。 20 のカテゴリがあると、モデル (およびチーム) が混乱します。 6 ～ 8 個の明確なカテゴリは、より一貫してラベル付けされており、レポートで意味を持ちます。よく混同される 2 つのカテゴリを組み合わせます。

オートメーションへの接続

構造化された JSON 出力の本当の威力は、次のステップに自動的に進むことです。「重要」というラベルの付いたリクエストはすぐにマネージャーに通知され、「販売機会」は CRM (顧客関係管理ソフトウェア) に入り、「返品」はセルフサービス フローに入ります。ただし、自動化の最初のルール: 影響の大きいアクション (払い戻し、口座閉鎖) は、AI タグのみに基づいてトリガーされることはありません。人間の承認が得られる場合もあります。

注意: センチメント分析は予測であり、正確な測定ではありません。モデルが「中立」と呼ぶ顧客は、実際には静かに非常に怒っている可能性があります。感情タグを使用して優先順位を付けます。ただし、これだけに頼って「この顧客はすでに満足している」などの最終的な結論を導き出さないでください。

よくある間違い

• カテゴリ リストはモデルに任せます。毎回異なる、互換性のないラベルが取得されます。
• 「緊急」のような相対的な単語を未定義のままにする。皆さんの要望は緊急です。
• 出力フォーマットが固​​定されていない。 JSON の代わりに段落が表示されることもあれば、リストが表示されることもあります。
• 不確実性のために出口のドアを提供しません（確信はありません）。
• 人間の承認なしに、影響の大きいトランザクション (払い戻し、口座閉鎖) を AI タグにリンクします。
• 最初のバッチを手動で検証することなく、フロー全体を自動化します。

要約すると

• トリアージは、大量の受信リクエストをカテゴリ、緊急度、感情ごとに迅速に分類します。
• 一貫性の鍵: 閉じられたカテゴリのリスト、具体的な緊急性の定義、固定された出力形式 (JSON)。
• 緊急性と感情のラベルにより、優先順位付けが迅速化されます。それは批判的で怒りに満ちた要求を提起します。
• 構造化された出力は自動化 (通知、ルーティング、CRM) に直接リンクできます。
• 影響の大きい行為や曖昧なラベルは、常に人間による検証を受ける必要があります。

アプリケーションタスク

上記の JSON 配列プロンプトを使用して、5 つの異なる顧客リクエスト (またはサンプル) をバッチ処理します。次に、出力を手動で確認します。 (1) 各カテゴリは正しいか? (2) 「緊急」とマークされたものは実際にサービスを停止しますか? (3) 私は確かに正しい場所で「はい」と言ったでしょうか?適合しないタグを修正し、それに応じてプロンプト (特にカテゴリ定義と緊急性ルール) を更新します。この演習では、スキーマを自分の現実に合わせて調整する習慣を築きます。

チェックリスト

• [ ] カテゴリの閉じた離散リストを定義しました。
• [ ] 緊急度のレベルを具体的な対策とともに説明しました。
• [ ] 出力形式(JSON/テーブル)を修正しました。
• [ ] 不確実性のために出口ドアを追加しました (I'm_unsure)。
• [ ] 最初のバッチを手動で検証し、プロンプトを調整しました。
• [ ] 影響力の高い行動には人間による承認のレイヤーを置きます。