AI電話受付で取次ぎに失敗したときの対応

AI電話受付の取次ぎは、転送を始めただけでは完了していません。担当者が応答し、受付内容を受け取って会話を続けられた時点を成功とします。応答がなければ、発信者を元の受付へ戻すか、折り返しへ切り替える処理が必要です。

ここが決まっていないと、保留のまま切断されたり、同じ担当者へ何度も転送したりします。取次ぎ先を増やす前に、失敗の種類とその後の約束を決めた方が良いです。

取次ぎ結果を四つに分ける

最初に、取次ぎ結果を「成功」と「失敗」だけで保存しないようにします。次の処理を決められる粒度が必要です。

Amazon Connectのキュー転送ブロックには、転送先の収容上限に達した場合と、それ以外のエラーを分ける経路があります。無効な転送先や停止中のキューもエラーになり得ます。製品ごとの画面名は異なりますが、混雑と設定不備を同じ処理にしない考え方は使えます。

取次ぎ先の呼出時間も決めます。短すぎれば担当者が応答できず、長すぎれば発信者を待たせます。一定時間で応答がなければ、同じ番号を呼び続けず次の案内へ移します。

接続できないことが分かっている相手へ転送すると、発信者の待ち時間だけが増えます。可能であれば、担当者やキューの状態を確認してから転送します。

Amazon Connectのキュー管理フローでは、転送前にスタッフの配置や担当者の応答可能性を確認できます。待ち人数などの指標を取得し、その値に応じて転送先を変える設計も示されています。

ただし、「オンライン」と表示されていても必ず応答できるとは限りません。通話中や離席、会議中をどこまで判定できるかは製品と連携先によって異なります。状態を確認できない場合は、短い呼出時間と折り返し受付を組み合わせた方が安全です。

転送音が止まった後に受付へ戻すだけでは、つながらなかったのか待てばよいのか判断できません。接続できなかったことと、次に何をするかを一つの案内にします。

たとえば「担当者が応答できないため、折り返しを承ります」のように伝えます。この時点で次の対応を選べるようにします。別の担当者へつなぐ方法と、折り返しまたは伝言を受け付ける方法があります。

緊急性の高い用件では、折り返しだけにしない方が良い場合があります。代替の当番者や有人窓口へ送る経路を用意し、その先も応答しなければ最終案内へ進めます。緊急の定義と当番表は、AIの会話ではなく社内の運用で管理してください。

折り返しを受け付けても、メールを一通送るだけでは対応漏れを見つけにくくなります。依頼を一件のタスクとして登録し、期限と状態を持たせます。

残す内容は、発信者の氏名と連絡先です。受付時刻と用件の要約、希望する担当先も必要です。加えて、折り返し期限と担当者、現在の状態を記録します。録音や文字起こしへのリンクを付ける場合は、閲覧権限も引き継ぎ先に合わせます。

折り返しが完了したら、元の受付履歴も完了にします。タスクだけを閉じると、同じ発信者から再入電があった際に経緯を確認できないためです。

通知を送れたことと、発信者へ折り返せたことは別の結果です。通知成功率だけを見ても、対応待ちの依頼が残っているかは分かりません。

Amazon Connectのコールバック失敗に関する説明では、担当者がコールバックを受け付けた後に問題が起き、担当者と顧客を接続できなかった場合を失敗として区別しています。担当者への割り当てと、発信者への接続を別段階で記録する必要があります。

日次確認では、取次ぎ成功率だけでなく未割当と期限超過を見ます。再入電が多い用件も確認してください。折り返し済みと記録されていても、必要な説明まで終わっていない可能性があるからです。

正常な転送だけのデモでは、導入後に困る経路が残ります。本番前にテスト用番号を使い、次の状態を一つずつ再現します。

各テストでは、発信者が聞いた案内と担当者側の記録を照合します。転送履歴と通知、折り返しタスクを同じIDでつなぎます。どこで止まったか追いやすくなるためです。

まず、現在の代表電話で取次ぎに失敗した直近十件を確認してください。不応答と混雑、設定エラーへ分けます。それぞれで発信者に何を約束したかを書き出します。その上でAI電話受付・電話代行比較表から、転送失敗後の案内と折り返し管理まで確認できる候補を絞ると進めやすくなります。