必須ではありませんが、先に目を通しておくとスムーズに進められるレッスンがあります。
atom.cs-automator.priority-scoring
優先度スコアリングの基準を設計する
優先度スコアリングの基準を設計する カスタマーサポートに届く問い合わせは、すべてが同じ緊急度ではありません。「今すぐ対応しないとお客さまが困る」ものと「来週でも大丈夫」なものを見分ける仕組みがあれば、チーム全体の対...
成果物成果物このレッスンが終わったとき、あなたの手元に残る具体的な成果物です(例: 公開済みの Web ページ、動作するフォームなど)。
証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。
メディアメディアレッスン内に出てくる図や動画のスロットです。実際の画面やイメージで理解を補助します。
レッスン本文
優先度スコアリングの基準を設計する
カスタマーサポートに届く問い合わせは、すべてが同じ緊急度ではありません。「今すぐ対応しないとお客さまが困る」ものと「来週でも大丈夫」なものを見分ける仕組みがあれば、チーム全体の対応スピードが上がります。
たとえるなら、病院のトリアージ(=患者さんの症状に応じて診察の順番を決めること)と同じ考え方です。重症の方を先に、軽症の方はあとで――この「振り分けルール」をカスタマーサポート向けに AI と一緒に作るのが、この Atom のゴールです。
理解する:優先度スコアリングとは何か
優先度スコアリングとは、問い合わせ 1 件ごとに「どれくらい急ぎか」を数値で表す仕組みです。数値が高いほど先に対応する、というルールをチームで共有すると、判断のブレが減ります。
スコアリングなしの場合、担当者の経験と勘で優先順位が決まります。これだと人によってバラつきが出たり、新人メンバーが判断に迷ったりします。
知る:スコアリング基準に使う 4 つの軸
優先度を決めるとき、よく使われる軸は次の 4 つです。
| 軸 | 意味 | 例 |
|---|---|---|
| 緊急度 | 対応が遅れるとお客さまに実害が出るか | サービスが使えない → 高、使い方の質問 → 低 |
| 影響範囲 | 困っている人が何人いるか | 全ユーザー影響 → 高、1 人だけ → 低 |
| 顧客属性 | 契約プランや利用歴 | 有料プラン → 高、無料トライアル → 中 |
| 感情シグナル | お客さまの文面から読み取れる温度感 | 怒り・焦り → 高、穏やか → 低 |

すべての軸を使う必要はありません。あなたのチームに合った 2〜3 軸を選ぶのがコツです。
準備する:スコアリングシートのテンプレートを作る
まず、AI にスコアリング基準のたたき台を作ってもらいます。以下のプロンプトをそのままコピーして、Claude や ChatGPT に貼り付けてください。
AI に送るプロンプト例 1:基準のたたき台を作る
あなたはカスタマーサポートの業務改善コンサルタントです。
以下の条件でお問い合わせの優先度スコアリング基準を設計してください。
【条件】
- 対象サービス:(あなたのサービス名を入れる)
- 問い合わせチャネル:メール、チャット
- 現在のチーム人数:(人数を入れる)
- よくある問い合わせ上位3つ:(箇条書きで入れる)
【出力形式】
- スコアリングに使う軸を2〜3つ選び、各軸の配点(1〜5点)と判定基準を表形式で出してください
- 合計スコアと対応優先度(高・中・低)の対応表もつけてください
- 判定に迷いそうなグレーゾーンの例を2つ挙げてください
AI の出力を見て、「うちのチームだとこの軸は使わないな」「この基準はもう少し細かくしたい」と思ったら、続けて修正を依頼します。
AI に送るプロンプト例 2:基準を修正する
ありがとうございます。以下の点を修正してください。
- 「顧客属性」の軸は不要なので削除してください
- 「緊急度」の判定基準に「決済エラー」を最高優先度の例として追加してください
- グレーゾーンの例をもう1つ追加してください
作成する:スコアリング基準書を完成させる
AI が出力した基準を元に、以下の構成でスコアリング基準書(Markdown ドキュメント)を仕上げます。
基準書に含める項目
- 目的:なぜスコアリングを導入するのか(1〜2 文)
- スコアリング軸と配点表:AI が作った表をそのまま使うか、手直しする
- 合計スコアと優先度の対応:例)12 点以上 → 高、8〜11 点 → 中、7 点以下 → 低
- グレーゾーン対応ルール:判断に迷ったときの指針
- 運用メモ:誰がいつ見直すか
良い基準書の例
緊急度(1〜5 点)
- 5 点:サービス全体が停止している
- 4 点:決済エラーで購入できない
- 3 点:一部機能が動かない
- 2 点:表示崩れ・軽微な不具合
- 1 点:使い方の質問・要望
このように、各点数に具体的な状況が紐づいているのがポイントです。
悪い基準書の例
緊急度:高・中・低で判断
これだけだと「中と高の境目はどこ?」と迷ってしまいます。数値と具体例がないとチーム内で判断がバラつきます。
検証する:基準書をテストケースで試す
作った基準書が本当に使えるかを確認するため、過去の問い合わせ 5〜10 件を基準書に当てはめてみましょう。AI にテストケースの生成を頼むこともできます。
AI に送るプロンプト例 3:テストケースを生成する
以下のスコアリング基準表を使って、テスト用の問い合わせ例を5件作ってください。
各例について、スコアリング結果(各軸の点数と合計)と優先度判定も出してください。
判断が微妙なグレーゾーンの例を2件含めてください。
(↑ここに作った基準表を貼り付ける)
出力されたテストケースを見て、以下をチェックします。
- チームメンバーが見ても同じスコアをつけられるか?
- グレーゾーンのケースで基準書のルールで判断できるか?
- 明らかにおかしい判定結果がないか?
もしズレがあれば、基準書の配点や判定基準を調整して、もう一度テストします。
つまずきやすいポイント
「軸を増やしすぎてしまう」
軸が 4 つ以上になると、1 件の判定に時間がかかりすぎます。最初は 2 軸で始めて、運用しながら必要に応じて追加しましょう。
「点数の幅が広すぎて迷う」
1〜10 点のような幅広い配点だと、3 点と 4 点の違いを説明しづらくなります。1〜5 点(または 1〜3 点)で十分です。
「全部の問い合わせに当てはまる基準を作ろうとする」
100% カバーは目指さなくて OK です。8 割の問い合わせをカバーできれば十分。残り 2 割は「判断に迷ったらリーダーに確認」というルールで運用します。
完了チェック
以下がそろったら、この Atom は完了です。
- スコアリング基準書(Markdown)が手元にある
- 基準書に「軸・配点・判定基準・優先度対応表」が含まれている
- テストケース 5 件以上で試して、チーム内でスコアがブレないことを確認した
- 基準書のスクリーンショットを撮った
この基準書は、次の Atom「ルーティングルールを設定する」で自動振り分けのルールに組み込んでいきます。
種類: markdown_doc
検証: basic_manual_check_v1
証跡証跡成果物が正しく作れたことを確認するためのチェックリストです(例: ブラウザで動作する、フォーム送信で値が保存される)。
メディア