問い合わせ対応の優先順位の決め方｜急ぎと定型質問を分ける方法

## 問い合わせ対応の優先順位は、なぜ「急ぎ」だけで決めてはいけないのか 問い合わせ対応の優先順位は、問い合わせ文に含まれる「至急」「今すぐ」といった表現だけで決めないことが重要です。言葉の強さと、実際の顧客や業務への影響は一致しない場合があるためです。 例えば、強い口調で営業時間を確認する問い合わせは、顧客にとっては急ぎでも、他の顧客や店舗業務への影響が限定されていることがあります。一方、短い文面でも、決済が完了しない、予約を受け付けられない、安全に関わる申告があるといった問い合わせは、影響範囲が広い可能性があります。 この2つを同じ基準で処理すると、表現の強い問い合わせに対応が偏ります。その結果、影響の大きい障害や、期限のある相談が後回しになることがあります。 問い合わせ対応の優先順位を決めるときは、少なくとも次の3点を分けて確認します。 - いつまでに対応が必要かという緊急度 - 顧客や業務にどの程度影響するかという影響度 - 担当者の判断や確認が必要かどうか まずは担当者が同じ表で判定できる状態を作ります。運用が安定した後に、AIによる問い合わせ分類を補助として検討すると、分類条件や有人対応へ切り替える境界を説明しやすくなります。 ## 最初に確認する情報は何か｜優先度判定に必要な5項目 問い合わせを受けた直後に情報が不足していると、担当者は文面の印象だけで優先度を決めることになります。受付時の確認項目を固定すると、問い合わせ同士の優先度を比較しやすくなります。 最初に確認する情報は、次の5項目です。 ### 1. 問い合わせ内容 何が起きているのかを、事実として記録します。「使えない」「困っている」といった表現だけでなく、対象のサービス、画面、商品、予約、決済などを確認します。 同じ「使えない」という申告でも、特定の顧客だけに起きているのか、複数の顧客に共通しているのかで、影響度は変わります。可能であれば、表示されたメッセージや操作した手順も記録します。 ### 2. 発生時期 問題がいつから起きているかを確認します。現在も続いているのか、特定の時間だけ発生したのか、一度だけの事象なのかで、確認する範囲が変わります。 予約や決済のように利用予定が決まっている場合は、発生時期とあわせて利用予定の日時も確認します。期限が近い案件を見落とさないためです。 ### 3. 影響を受ける範囲 影響が一人の顧客に限られるのか、同じ店舗の複数顧客に及ぶのか、全店舗や複数の業務に関係するのかを確認します。影響範囲が分からない場合は、分からないこと自体を記録します。 同様の問い合わせが短時間に複数届いていないかも確認します。個別の問い合わせに見えても、共通する障害が隠れている可能性があるためです。 ### 4. 顧客が希望する期限 顧客がいつまでに回答や解決を求めているかを確認します。ただし、希望期限だけで優先度を確定しません。希望期限と実際の影響度は、別々に記録します。 「今日中に知りたい」という希望があっても、影響が一人に限られる場合があります。反対に、顧客が期限を明示していなくても、決済停止や予約障害が続いていれば、早い確認が必要です。 ### 5. 判断が必要かどうか 定型的な案内だけで回答できるのか、返金や契約変更など担当者の判断が必要なのかを確認します。判断が必要な案件は、緊急度が低くても自動回答だけで完了させない運用にします。 受付項目は、問い合わせ管理表や受付フォームにそのまま追加できる形にします。例えば「内容」「発生時期」「影響範囲」「希望期限」「判断要否」「担当者」「次回確認日」を記録欄として用意します。 確認できない項目を推測で埋めないことも大切です。「影響範囲は未確認」と記録すれば、後から追加確認が必要な案件として扱えます。情報が不足している問い合わせは通常案件に戻さず、確認待ちの状態として管理します。 ## 緊急度と影響度で問い合わせの優先順位を4分類する 問い合わせの優先度は、緊急度と影響度の2軸で整理すると判断しやすくなります。緊急度は対応期限に関する軸です。影響度は顧客、店舗、業務への広がりに関する軸です。 次の表は、問い合わせ対応の優先順位を決めるための基本形です。受付時間や返答期限は、各社の体制に合わせて設定してください。ここでは一般的な標準値として断定しません。 |分類|緊急度|影響度|対応の考え方|例| |---|---|---|---|---| |緊急・重要|高い|大きい|最初に事実を確認し、有人対応へ引き継ぐ|決済停止、予約受付の障害、安全に関わる申告| |重要だが緊急ではない|低い、または期限に余裕がある|大きい|担当範囲を決め、期限を記録して計画的に対応する|複数顧客に関係する設定変更、業務手順の見直し相談| |緊急だが影響範囲が限定的|高い|小さい|期限を確認し、対応可能な担当者へ割り当てる|一人の顧客の予約内容の確認、当日利用に関する個別相談| |通常|低い|小さい|定型回答や通常の担当者対応で処理する|営業時間、利用方法、一般的な案内の確認| この表で重要なのは、緊急度と影響度を別々に記録することです。例えば、当日中の利用に関わる問い合わせは緊急度が高くなります。しかし、一人の顧客に限られる場合は、影響度まで高いとは限りません。 反対に、問い合わせ文が短くても、複数顧客の決済や予約に影響している場合は、影響度が大きい可能性があります。受付時に同様の問い合わせが増えていないかを確認し、単独案件として扱うか、業務上の障害として扱うかを切り分けます。 優先度を4分類した後は、担当範囲を決めます。緊急・重要の案件は、受付担当者が回答を抱え込まず、責任者や専門担当者へ引き継ぎます。重要だが緊急ではない案件は、期限と確認事項を決めて保留します。通常案件は、定型回答やナレッジを使って処理します。 判断に迷った案件は、分類結果だけでなく、迷った理由も残します。後の見直しで、受付項目の不足や分類条件の曖昧さを特定しやすくなります。 ## 定型質問・判断が必要な相談・緊急案件はどう振り分けるか 問い合わせの優先度と、回答方法は別に管理します。優先度が高いから必ず有人対応になるとは限りません。逆に、優先度が通常でも、返金や契約変更のように担当者の判断が必要な案件は、自動回答だけで完了させません。 回答方法は、次の3種類に分けます。 ### 定型回答で処理する問い合わせ 営業時間、利用方法、対応している手続き、一般的な料金の確認など、あらかじめ内容を確認できる質問が該当します。回答文と根拠となる情報をナレッジとして整理します。 定型回答にする場合は、例外条件も記録します。通常の営業時間を案内できても、臨時休業や特別期間の扱いが別に定められているなら、その条件を確認してから回答します。定型回答の対象は、答えと適用条件が明確な質問に限定します。 ### 担当者の判断が必要な問い合わせ 返金、契約変更、個別の例外対応、規約の適用判断などが該当します。問い合わせの緊急度が低くても、承認できる人や確認する部署を決めてから回答します。 この分類では、AIやチャットボットが文章の候補を作れても、最終的な判断まで任せるかどうかを別に決めます。判断者、確認項目、記録方法が決まっていない場合は、担当者確認に切り替えます。 ### すぐに有人対応へ切り替える問い合わせ 決済停止、予約受付の障害、安全に関わる申告、個人情報の取り扱いに関する重大な相談などが該当します。受付担当者は原因を断定せず、発生時期、影響範囲、現在も続いているかを確認します。 有人対応へ引き継ぐときは、問い合わせ本文だけを転送しません。確認できた事実、未確認の項目、顧客が希望する期限、すでに案内した内容をまとめます。引き継ぎ先が同じ質問を聞き直す回数を減らせます。 定型質問と判断が必要な相談の境界を決めるときは、「回答文があるか」だけでなく、「例外が発生した場合に誰が判断するか」まで確認します。回答の根拠が更新されていない場合も、定型回答から外して確認待ちにします。 回答範囲や有人対応へ切り替える条件を社内ルールとして整理したい場合は、[チャットボットの運用ルールを決める方法](/usage/chatbot-operation-rules)も確認してください。定型回答の対象、更新担当、引き継ぎ条件を決めるときの補助になります。 ## すぐに解決できない問い合わせは、一次回答と再連絡をどう運用するか 問い合わせをすぐに解決できない場合は、保留にしたまま放置しないことが重要です。受け付けたことを伝え、現在確認している内容と、次に連絡する条件を記録します。 保留案件では、次の情報を一つの記録にまとめます。 - 問い合わせを受け付けた日時 - 顧客が求めていること - 現時点で確認できている事実 - 追加で確認する内容 - 担当者または引き継ぎ先 - 次回連絡の条件または期限 - 顧客へすでに案内した内容 一次回答では、解決したように受け取られる表現を避けます。「確認を受け付けたこと」「現在確認中のこと」「追加で確認が必要なこと」を分けて伝えます。解決時期を断定できない場合は、確定していない期限を約束しません。 例えば、決済に関する問い合わせで原因が確認できていない場合は、受付内容と確認中の項目を伝えます。担当者は、決済状況を確認する責任者と、次回連絡の条件を記録します。顧客から再度連絡が来るまで待つ運用にはしません。 再連絡の期限は、自社の営業時間、担当者の確認手順、顧客への影響を踏まえて決めます。数値を一律に設定するのではなく、優先度分類ごとに「いつまでに状況を確認するか」を自社で定めます。 保留案件には状態を付けます。例えば「受付済み」「確認中」「担当者判断待ち」「顧客確認待ち」「解決済み」といった状態です。状態の意味を担当者間で統一すると、誰が次に動くかを確認しやすくなります。 ## AIで問い合わせを分類するとき、どこまで任せてよいか AIは、問い合わせ内容をあらかじめ決めた分類へ振り分けたり、定型質問の候補を整理したりする補助に使えます。ただし、AIに任せる範囲は、最終判断の影響度を基準に決めます。 導入前には、人が作った優先度表を用意します。AIに「緊急かどうか」を自由に判断させるのではなく、緊急度、影響度、判断要否などの項目を入力条件として定義します。分類結果を担当者が確認できる状態にしておくことも必要です。 AI分類の対象にしやすいのは、次のような案件です。 - 営業時間や利用方法の確認 - 既存のナレッジで回答できる質問 - 問い合わせ内容の種類を仮分類する作業 - 担当部署へ振り分けるための候補整理 一方で、次の案件は担当者が最終確認します。 - 返金や契約変更 - 個別の例外対応 - 安全に関わる申告 - 個人情報や権利に関する相談 - 決済停止や予約受付障害など、影響範囲が広がる可能性がある案件 AIが通常案件と分類しても、影響範囲が未確認なら担当者が確認します。強い表現があるから緊急案件と決めることも、文面が短いから通常案件と決めることも避けます。分類結果に「判断要否」と「影響範囲の確認状況」を持たせると、有人対応へ切り替える条件を確認しやすくなります。 AI分類を始める場合は、まず過去の問い合わせを人が分類し、どの文面をどの分類に入れたかを確認します。分類の境界が担当者間で一致していない状態では、AIを加えても判定基準は安定しません。 問い合わせをAIで分類する際の入力項目や、担当者が確認する条件を詳しく整理したい場合は、[AIで問い合わせを分類する前に確認すること](/usage/ai-inquiry-classification-guide)を参照してください。AIへ渡す情報と、人が確認してから回答する情報を切り分けると、導入範囲を決めやすくなります。 ## 優先順位のルールを週次で見直す方法 問い合わせ対応の優先順位は、一度決めたら固定するものではありません。新しい商品、営業時間、決済方法、予約手順が加わると、定型回答や有人対応の境界も変わります。 週次の見直しでは、すべての問い合わせを詳細に分析する必要はありません。次の項目を確認し、ルール変更が必要な案件を拾います。 ### 誤分類が発生した問い合わせ 緊急ではないと分類した後に、実際には複数顧客へ影響していた案件を確認します。反対に、緊急案件として扱ったものの、影響範囲が限定されていた案件も確認します。 誤分類があった場合は、担当者の注意不足だけで終わらせません。受付項目が不足していなかったか、影響範囲の定義が曖昧ではなかったか、判断者が不明確ではなかったかを確認します。 ### 返信遅延や保留の長期化 返答が遅れた案件では、優先度が低く設定されていたのか、担当範囲が不明だったのか、確認待ちのまま止まっていたのかを分けて記録します。単に「遅れた」とだけ記録すると、次の改善策を決められません。 ### 同じ質問の繰り返し 同じ質問が繰り返される場合は、ナレッジの内容、表示場所、定型回答の対象範囲を確認します。回答文があるのに担当者が毎回作成しているなら、定型化の条件が不足している可能性があります。 ### 有人対応への引き継ぎ AIや定型回答から有人対応へ切り替わった案件を確認します。引き継ぎが適切だったかだけでなく、どの条件で切り替えたか、必要な情報がそろっていたかも確認します。 ルールを変更するときは、変更前の条件、変更理由、変更後の条件、確認する期間を記録します。変更後に誤分類や保留が増えていないかを確認すれば、印象だけでルールを戻す判断を避けられます。 優先順位の運用を始めた後に、返信遅延や有人引き継ぎの状況を確認する指標を整理したい場合は、[チャットボット運用で確認するKPI](/usage/chatbot-effect-measurement-kpi)を参考にしてください。数値を導入効果の保証として扱うのではなく、ルールを見直す材料として使います。 ## 問い合わせ対応の優先順位を決めるための実行手順 問い合わせ対応の優先順位は、次の順番で整備すると現場へ移しやすくなります。 1. 受付時に確認する5項目を決める 2. 緊急度と影響度の4分類表を作る 3. 定型回答、担当者判断、有人対応の境界を決める 4. 保留案件の担当者と次回連絡の条件を記録する 5. 週次で誤分類、返信遅延、繰り返し質問、引き継ぎを確認する 6. 分類が安定してからAIの補助利用を検討する 最初から細かい点数を設定する必要はありません。まずは「緊急・重要」「重要だが緊急ではない」「緊急だが影響範囲が限定的」「通常」の4分類で運用し、迷った案件を記録します。迷いが発生した箇所が、次にルールを具体化する場所です。 最終的に確認する項目は、次のとおりです。 - 問い合わせ内容と発生時期を記録できている - 影響範囲と顧客の希望期限を分けて確認している - 判断が必要な案件を定型回答から外している - 決済、予約、安全に関する案件の有人対応条件がある - 保留案件に担当者と再連絡の条件がある - ルール変更の理由を記録している - AIの分類結果を担当者が確認する条件がある 問い合わせ対応の優先順位は、急ぎという表現ではなく、影響度、対応期限、判断の必要性を分けて決めます。人が4分類と担当範囲を運用し、迷った案件を記録してからAI分類を補助に加えると、定型質問と有人対応が必要な案件を切り分けやすくなります。 自社の問い合わせを定型質問、判断が必要な相談、緊急案件に分け、有人対応の境界やAI分類の適用範囲を確認したい場合は、Socratesの導入相談・運用確認をご利用ください。現在の受付項目と担当範囲を確認しながら、自社の運用に合わせた分類条件を整理できます。 ## よくある質問 ### 問い合わせの優先度は、顧客の希望期限だけで決めてよいですか？ 希望期限だけで決めないでください。希望期限は緊急度を判断する材料ですが、顧客や業務への影響度とは別の情報です。期限と影響範囲を分けて記録し、4分類表で確認します。 ### 強い口調の問い合わせは、必ず緊急案件ですか？ 必ずしも緊急案件とは限りません。表現の強さではなく、対応期限、影響範囲、判断の必要性を確認します。ただし、強い不満の背景に障害や安全に関わる事象がないかは確認してください。 ### 返金や契約変更は、優先度が低くても有人対応にすべきですか？ 返金や契約変更は、優先度とは別に担当者の判断が必要な案件として扱います。緊急度が低くても、承認者や確認手順を決めたうえで回答します。 ### AIに問い合わせ対応の優先順位を任せられますか？ AIを使う場合も、分類条件と担当者の最終確認範囲を先に決めます。定型質問の候補整理や担当部署の振り分けは補助対象にできますが、返金、契約、安全、重大な障害などは担当者が確認します。