AIコールセンターのエスカレーション品質を測る

AIコールセンターのエスカレーション品質は、AIから人へ切り替えた割合だけでは測れません。人が必要な通話を見逃さず、不要な通話はAIで完了できたかを先に見ます。切り替えた後は、正しい担当者へつながり、会話を続けるための情報が渡ったかまで確認してください。

この記事では、人または追加支援へ切り替えることをエスカレーションと呼びます。転送の開始から担当者接続までを一つの結果にせず、途中状態へ分けます。担当者が応答できない場合の折り返しや受付完了も含めると、利用者が途中で取り残されていないか判断できます。

正解となる切り替えを人が付ける

最初に、実際の通話へ「人へ切り替えるべきだったか」を人が付けます。AIが転送した通話だけを確認すると、転送すべきだったのにAIが回答を続けた見逃しを測れません。AIで完了した通話も同じ評価対象にしてください。

正解は、問い合わせの結果から後付けしません。本人確認ができない場合や、契約変更に承認が必要な場合など、自社で決めた切り替え条件を使います。利用者が明示的に人との会話を希望した場合も対象です。誤案内の影響が大きい用件は、曖昧なまま回答を続けずに人へ渡す条件を決めます。

Amazon Connect CustomerのAIエージェント指標では、AIが対応した問い合わせのうち、人または追加支援へ切り替わった割合をAI Handoff Rateとして定義しています。この数字から件数の変化は分かりますが、切り替えが必要だったかは別に評価する必要があります。

Amazon Connect Customerの自動応対評価は、AIが利用者を理解できずに聞き返したことや、人へエスカレーションしたことを評価条件にできます。自社では録音と業務ルールを使い、AIの判定とは独立した正解を残してください。

転送開始と担当者接続を分ける

AIが人への切り替えを決めても、担当者が会話を始めるまでは完了していません。転送信号、キューへの登録、担当者接続を別の時刻で記録します。外部番号へ転送する構成でも、呼び出し開始を接続成功にしないでください。

Dialogflow CXのLive agent handoffは、会話を人へ渡すべきことを連携先へ知らせる信号です。Dialogflow CX自体は、その後のセッション状態や転送処理を変更しません。信号が出たことと、実際に人へつながったことは別の事実です。

Amazon Connect Customerの問い合わせイベントには、キューへ入った時刻と担当者へ接続した時刻があります。転送元の通話が終了した時刻も記録されます。この時系列を使えば、AIが切り替えを決めた後に、どこで止まったかを確認できます。

品質確認では、切り替え理由と転送先を最初に照合します。次に、キューへ入ったかを見ます。担当者接続と利用者の切断も確認してください。接続までの待ち時間は、同じ用件と時間帯で比べると改善の有無を判断しやすくなります。

見逃しと過剰転送を別に測る

エスカレーションの失敗には二つあります。人が必要な通話をAIが処理し続ける見逃しと、AIで完了できる通話を人へ送る過剰転送です。二つを合計すると、どちらの条件を直すべきか分からなくなります。

判断は次の四つに分けます。

見逃し率は、人が必要だった通話のうち見逃した件数で見ます。過剰転送率は、実際に転送した通話のうち不要だった件数です。分母が違うため、一つの正答率へまとめない方が良いです。

見逃しが多い場合は、利用者の発言と切り替え条件を確認します。過剰転送が多い場合は、AIが処理できる用件の境界や聞き返し回数を見直します。転送率を下げること自体を目標にすると、見逃しを増やすおそれがあります。

引き継ぎ後の最初の応答を確認する

担当者へ接続できても、利用者が用件を最初から説明し直すなら引き継ぎは不十分です。接続後の最初の応答を聞き、担当者が転送理由と確認済みの内容を使えたかを評価します。

表示する情報の多さではなく、次の一言を選べたかを見ます。たとえば、本人確認が未完了なら、その状態を理解した上で確認を続けられることが合格です。AIが試した回答と利用者の反応も分かれば、同じ案内の繰り返しを避けられます。

引き継ぎの記録には、転送理由と確認済みの事実を分けて残します。未確認の内容や未解決の質問も必要です。全文の文字起こしは根拠として開けるようにし、接続直後の画面へそのまま並べない方が扱いやすくなります。

評価時は、担当者が最初に何を尋ねたかを録音で確認します。同じ質問を繰り返した場合は、情報が生成されなかったのか、画面へ表示されなかったのかを分けます。表示されていたのに使われなかった場合は、転送機能ではなく画面配置や研修を見直してください。

担当者不在時の代替処理を評価する

エスカレーションが必要でも、担当者が常に応答できるとは限りません。キューが満員のときや営業時間外には、折り返し受付や別の窓口へ切り替える必要があります。待たせ続けて利用者が切断した通話を、転送済みとして完了にしてはいけません。

Amazon Connect Customerのキュー管理は、担当者の在席状況やキューの件数を使って転送先を変えられると案内しています。キューが満員の場合も分岐できます。問い合わせ放棄の指標は、担当者へ接続する前に利用者がキューから切断した件数を別に扱います。

自社の評価では、代替処理の受付が完了したかを見ます。折り返しなら、連絡先と用件が保存され、担当者と期限が設定された状態が合格です。別の窓口へ転送する場合は、その窓口で同じ情報を受け取れることを確認します。

利用者には、担当者へすぐにつながらないことを先に案内します。待ち続けるか折り返しを選ぶかも示してください。代替処理へ進んだ件数と、その後に対応を完了した件数を分けて追うと、受付だけが増えていないか分かります。

六つの通話で変更前後を比べる

切り替え条件や転送先を変えた後は、転送率だけを比べません。同じ六つの通話を使います。見逃しと過剰転送を分け、接続から情報引き継ぎと代替処理まで順に確認します。

1. 利用者が明確に担当者との会話を希望する
2. AIの対応範囲外で、人の承認が必要な用件を話す
3. 聞き返しても用件を特定できない
4. AIだけで完了できる定型的な用件を話す
5. 人への切り替えが必要だが、転送先が満員になっている
6. キューで待っている途中に利用者が通話を終了する

各通話には、人へ切り替える正解と転送先を先に付けます。期待する引き継ぎ情報と、担当者不在時の終了状態も決めてください。試験後は、切り替え判定だけでなく担当者接続または代替処理まで同じ受付IDで追います。

設定変更後の実通話も確認します。試験で使った言い方だけに合う条件になっていないかを見るためです。用件と時間帯、転送先の体制が近い通話を選び、変更前と同じ四分類で比較します。

最初の作業は、直近の通話から「人へ切り替えた十件」と「AIで終了した十件」を選ぶことです。各通話へ人による正解を付け、見逃しと過剰転送を分けます。切り替えた通話は担当者接続から代替処理まで追います。最初の応答も聞き、止まった一工程だけを改善してください。