チャットボットから有人対応へ切り替える設計|引き継ぐ情報と判断条件
記事概要:チャットボットから有人対応へ切り替える条件を、顧客の希望、未回答回数、感情、本人確認、営業時間で設計します。会話履歴、顧客属性、用件、試行済み手順を引き継ぎ、同じ質問を繰り返させない方法を解説します。
本記事の目次
チャットボットの有人対応切り替えは、答えられなくなってから行うだけでは遅い場合があります。チャットボットエスカレーションでは、顧客の希望、問題の影響、認証、未回答、感情、営業時間を条件として設計します。
顧客が希望したら選択肢を出す
人と話したいという明示的な要求を無視してボットを続けないようにします。ただし混雑時には待ち時間、コールバック、フォーム、営業開始時刻を示し、顧客が方法を選べるようにします。
顧客が希望したら選択肢を出すの改善前には、対象件数、発生条件、顧客影響、担当者の追加作業を基準値として残します。チャット・コールセンター運用責任者が原因を一つに決めつけず、流入、導線、データ、権限、システムの順に切り分けると対策を選びやすくなります。

未回答と反復を検知する
同じ意図の言い換え、連続した低信頼回答、該当なし、エラー回数を条件にします。一回で転送する高影響用件と、再質問を許容する一般用件を分けます。
変更は対象用件や時間帯を限定して行い、前後で同じ指標を比較します。複数の設定を同時に変えると効果の理由が分からなくなるため、仮説、変更内容、観測期間、結果を一つの記録へ残します。
感情だけで自動判断しない
強い不満を示す言葉は優先条件になりますが、短文や皮肉を誤判定する可能性があります。用件、顧客属性、未解決回数と組み合わせ、担当者が優先度を変更できるようにします。
担当者の経験に依存する部分は、判断条件と例外を文章化し、ナレッジまたはシステム設定へ反映します。個別に解決した案件を共有するだけでなく、次回に同じ問題を早く処理できる形へ変えます。
| 切替条件 | 判定例 | 引継ぎ内容 |
| 顧客の希望 | 人・担当者を希望 | 希望チャネルと用件 |
| 未回答 | 連続未回答・低信頼 | 質問、候補、参照結果 |
| 高影響用件 | 返金、障害、解約、苦情 | 顧客、契約、影響、優先度 |
| 本人確認 | 個別情報や変更処理 | 認証状態と確認済み項目 |
| 営業時間 | 有人窓口の開閉 | 待ち時間、予約、代替手段 |
本人確認が必要な処理は人へ渡す
返金、契約変更、個人情報訂正など、認証と権限が必要な処理はボットで受付情報を集め、認証済み状態と確認項目を担当者へ渡します。チャット上で不要な情報を取りすぎないようにします。
数値が改善しても、別チャネルへの移動、再問い合わせ、訂正、顧客の諦めが増えていないかを確認します。チャットボットから有人対応へ切り替える設計の成果は部分最適ではなく、受付から問題完了までの総工数と顧客結果で判断します。
引き継ぐ情報を標準化する
会話全文だけでなく、顧客ID、用件、要約、入力値、参照FAQ、試行済み手順、エラー、希望結果を構造化します。担当者は原文へ戻れるようにし、AI要約だけで判断しません。
定例会では全件を読み上げず、変化が大きい用件と影響の大きい例外を選びます。原因が運用、製品、情報、需要のどこにあるかを分け、次回までの担当と確認値を決めます。
転送後のKPIを持つ
転送率だけでなく、待ち時間、再質問回数、転送後AHT、一次解決、顧客評価を確認します。転送率を下げるために顧客をボット内へ留める運用を避けます。
転送後のKPIを持つの変更後は、対象の指標だけでなく、再問い合わせ、訂正、別チャネルへの移動を同じ期間で確認します。改善が確認できなければ、仮説と実施内容を分けて記録し、次の変更で同じ原因を重ねて検証しないようにします。
有人切り替えの条件を具体化する
チャットボットから有人対応へ切り替える際は、回答不能、顧客からの希望、特定の問い合わせ内容など、転送条件をあらかじめ整理します。要件票には必須、希望、対象外とその理由、確認方法を記載し、例外時の処理や承認者まで決めておけば、担当者ごとに判断が変わることを避けられます。
UdeskのSony事例では、AIチャットボット、ライブチャット、統合ナレッジを連携して運用し、公開情報では問題マッチ率80%超、解決率70%超とされています。チャットボットだけで完結させるのではなく、同じナレッジを有人対応でも参照できる構成は、切り替え後に担当者が再び情報を探す負担を抑えるうえで参考になります。

転送後の結果と変更履歴を残す
本番後はチャットボットの利用件数だけでなく、有人転送率、転送後の再処理、顧客からの再問い合わせも確認します。利用数が増えていても、担当者が同じ内容を聞き直している場合は、転送条件や引き継ぐ情報、会話導線のどこを見直すべきかを切り分けます。
運用責任者は月次結果とともに変更前の基準値、対象期間、除外条件を残します。引き継ぎ資料には設定変更の権限、承認者、切り戻し手順を記載し、会話履歴や担当者操作など必要なログの保存期間と閲覧権限も決めておきます。
有人対応後の解決まで確認する
有人切り替えを滑らかにするには、ボットで確認した顧客の目的、入力済み情報、提示した回答、未解決の理由を担当者へ引き継ぐ必要があります。会話履歴だけを渡して担当者が最初から確認し直す運用では、顧客の手間を増やすことになります。
UdeskではAIチャットボットと有人チャット、問い合わせ管理、ナレッジを組み合わせられるため、ボットで完結できない問い合わせを有人対応へ引き継ぎ、その後の解決状況まで同じ顧客対応の流れとして確認できます。転送率だけでなく、転送後の対応時間や再問い合わせまで見ながら、切り替え条件を継続して見直す構成を検討できます。
FAQ
Q:何回未回答なら転送しますか
A:高影響用件は早く、一般用件は再質問を許容するなど用件別に決めます。
Q:営業時間外はどうしますか
A:受付フォーム、折返し予約、FAQ、緊急窓口を用件に応じて案内します。
Q:会話全文を担当者へ渡せば十分ですか
A:要約と構造化項目を併用し、原文へ戻れるようにします。
》》Udesk コールセンターの無料トライアルを開始するにはクリックし、メリットを実際にご体験ください
本記事はUdeskのオリジナルであり、転載する際は出典を明記してください:https://www.udesk.jp/blog/news/guide/6354/

Customer Service& Support Blog



