AIからオペレーターへ渡すべきものは、会話の全文ではありません。オペレーターが次の一言を選べる短い引き継ぎです。転送理由を先頭に置き、本人確認の状態と確認済みの事実を分けます。AIが試した回答と相手の反応も続けて表示してください。

この設計は、転送条件と転送先を決めた後に行います。この記事では、有人転送の成否やCRMへの長期保存ではなく、通話を受けた瞬間の画面に何を出すかを扱います。

転送理由を一文で先に出す

オペレーターが最初に知りたいのは、なぜ自分へ転送されたのかです。「契約変更」のような分類名だけでは、次の質問を選べません。「住所変更を希望しているが、本人確認が完了していないため転送」のように、用件と引き継ぎ理由を一文にします。

その下には、相手がいま求めていることを置きます。AIが判断したカテゴリではなく、本人が述べた希望を短く残してください。「料金を知りたい」と「請求額に納得できない」は、同じ料金関連でも応対の始め方が変わります。

Amazon Connect Customerの公式ドキュメントでは、通話開始時に問い合わせ属性を詳細画面へ表示するスクリーンポップが案内されています。画面を開けるだけでは足りません。担当者が通話を受けた時点で、転送理由と現在の希望が読める配置にします。

全文の文字起こしは確認用として残せますが、最初に読ませる情報にはしません。会話中に過去の発言を探す構成では、相手を待たせます。短い引き継ぎから原文を開ける順番が扱いやすいです。

本人確認済みと未確認を分ける

顧客名や契約番号が取得できても、本人確認が済んだとは限りません。画面には「確認済み」「候補あり」「未確認」を分けて表示します。確認に使った質問と結果も分かれば、オペレーターが同じ確認を繰り返さずに済みます。

Amazon Connect Customerの顧客プロファイルでは、電話番号などで候補を検索できます。初期設定では、本人確認後に担当者が問い合わせと顧客プロファイルを関連付けます。複数候補が見つかった場合も、担当者が一件を選ぶ仕組みです。番号の一致を本人確認済みとして扱わない考え方が分かります。

未確認の段階では、画面へ出す情報も制限します。住所や契約内容を先に表示すると、オペレーターが会話の中で不用意に読み上げるおそれがあります。候補の検索結果と、本人へ開示してよい情報を同じ欄に置かないようにしてください。

本人確認に失敗した場合は、入力値をそのまま引き継ぐより「確認未完了」と理由を残します。認証に使った秘密情報を会話要約やスクリーンポップへ複製する必要はありません。

AIが試した回答と相手の反応を残す

AIが回答を提示した後に人へ切り替わる通話では、用件だけを渡すと同じ案内を繰り返します。引き継ぎには、AIが何を案内し、相手がどう反応したかを一組で残してください。

たとえば「返品期限は到着後八日と案内」「購入日が異なるとして受け入れられず」のように書きます。回答文を全文で複製するより、参照したルールと相手が拒んだ理由を示す方が、次の確認へ進みやすくなります。AIが回答できずに転送した場合は、試した検索や聞き返しも短く残します。

Dialogflow CXの有人引き継ぎでは、引き継ぎ時に独自のメタデータを持たせられます。ただし、Dialogflow CXがデータ構造や転送後の処理を決めるわけではありません。自社側で項目と受け取り方を設計する必要があります。

AIの要約には誤りが混ざる場合があります。確定した事実とAIの推定を同じ文へ入れず、「本人が回答」「システムで照合」「AIが推定」のように出所を持たせます。オペレーターが、どこから再確認すべきか判断できます。

約束と未解決の質問を分けて渡す

会話の途中でAIが約束した内容は、用件の要約とは別に表示します。折り返し時刻や送付予定を伝えた場合、転送後の担当者もその約束を守る必要があるためです。確定していない候補を約束として表示しないようにします。

未解決の質問も独立させます。「希望日は確認済み、対象プランは未確認」のように、聞けたことと残っていることを分けてください。オペレーターは、引き継ぎの冒頭で同じ質問をせず、次に必要な一点から会話を続けられます。

画面に出す項目は、通話中に変更されることがあります。Amazon Connect Customerの問い合わせ属性は、転送や会議にまたがる問い合わせチェーンで値を伝播できます。最後に更新された希望や確認状態が転送先へ届くかを試してください。

古い値を上書きするだけでは、変更の経緯が分からない場合があります。約束の変更が業務上重要なら、現在値に加えて変更時刻と変更者を記録します。スクリーンポップは現在の状態を優先し、詳しい履歴は別画面から開けるようにします。

緊急度は根拠と一緒に表示する

「緊急」「怒っている」というラベルだけでは、担当者が優先順位を判断できません。緊急度を表示する場合は、その根拠となった発言や業務条件を一緒に出します。「本日中に停止しないと再請求されると申告」のように、時間制約と影響が分かる形にします。

感情分析のスコアだけで転送先や優先度を決めない方が良いです。声が落ち着いていても緊急性の高い用件はあります。反対に、強い口調でも即時の業務処理を必要としない場合があります。用件の期限と影響を優先し、感情は補助情報として扱います。

画面に渡す情報が増えるほど、個人情報の扱いも広がります。Genesys Cloudのスクリーンポップに関する公式説明では、スクリプト変数へ渡した値がやり取りの参加者データとして見えることを示しています。GDPR対応上の理由から、個人を識別できる情報を変数へ入れないことも推奨しています。製品ごとに保存先や削除範囲は異なるため、表示項目と保存項目を分けて確認してください。

六つの転送で画面を確かめる

設計した項目は、正常な一通話だけでは評価できません。候補製品のデモでは、同じ画面と転送先を使って次の六つを試します。

  1. 本人確認が完了し、確認済みの用件から会話を再開する
  2. 顧客候補は見つかるが本人確認は未完了で、非開示情報を表示しない
  3. AIの回答を相手が受け入れず、回答内容と拒んだ理由を確認する
  4. AIが折り返し時刻を約束し、担当者が期限と担当を引き継ぐ
  5. 緊急度が高い用件で、ラベルではなく根拠となる発言を確認する
  6. 転送直前に希望が変わり、画面へ最新の内容が反映される

各通話では、オペレーターが接続後に最初にした質問を記録します。AIがすでに確認した内容を聞き直したなら、項目が不足しているか、画面の優先順位が分かりにくい状態です。反対に、読む時間が長くなった場合は、全文や不要な候補情報を最初の画面から外します。

最初に、七つの表示項目を並べた一画面を作ります。先頭には転送理由と本人確認の状態を置き、その下で現在の希望とAIが試した回答を示します。最後に約束、未解決の質問、緊急度の根拠を続けます。実際の問い合わせを六つ通し、担当者が次の一言から応対を続けられるか確かめてください。