あふれ呼とは？放棄呼との違い・原因別の対策とAI電話の導入チェック

あふれ呼とは、電話が集中して回線や受付体制の対応量を超え、応答しきれなくなる呼を指します。対策を選ぶときは、電話が入口でつながらないのか、担当者を待つ間に切れるのか、受け付けた後の対応が滞るのかを分けて確認します。

回線を増やしても応対する人が足りなければ、待ち時間が残ります。AI電話で用件を受け付ける場合も、人への引き継ぎや折り返しが必要な案件の処理体制を確保する必要があります。

この記事では、コールセンターや企業の電話窓口で使える、原因の調べ方と改善手順を整理します。電話業務全体の導入手順は、コールセンター自動化ガイドも参照してください。

あふれ呼・待ち呼・放棄呼を、ログの状態で分ける

「あふれ呼」が含む範囲は一律ではありません。例えばNTTドコモビジネスの解説では待ち呼を含む説明があります。電話を振り分けるACDなどの管理画面を比較するときも、名称が同じだからといって同じ指標とは限りません。

以下は、原因を特定するための整理です。利用中の回線・システムのログ項目を、実際に起きた状態に対応させてください。

未応答の通知を数えただけでは、取りこぼした顧客数は分かりません。同じ電話が複数の担当者へ順番に配られ、最後の担当者が応答する場合もあるためです。集計単位を「着信」「担当者の呼び出し」「問い合わせ案件」のどれにするかも明記します。

最初に調べるのは、ピーク時間と詰まっている場所

月間の着信数だけでは、短時間の集中を捉えられません。まず通常時と繁忙時を含む期間を選び、15分または30分単位で確認します。この区切りは調査の始め方の例であり、すべての窓口に共通する基準ではありません。

入口から対応完了まで、同じ時間帯を追う

• 回線の入口：着信試行、受付に到達した件数、容量超過やエラーで到達しなかった件数
• 待ち行列：待機に入った件数、発信者が切断した件数、担当者への接続までの時間
• 応対体制：実際に受電できた人数、通話・保留・後処理にかかった時間
• 受付後：有人転送の成否、折り返し待ち件数、最も古い未対応案件、対応完了までの時間

回線側で拒否された着信は、受付システムのログに残らないことがあります。取得できる範囲を回線事業者とシステム提供者に確認し、不明な件数をゼロとして扱わないでください。受付時間外、障害発生中、広告や告知の直後も分けて残します。

あふれ呼率・放棄呼率は分母をそろえる

待機中の切断を調べるなら、「待機中に発信者が切断した件数 ÷ 待ち行列に入った件数 × 100」が一つの計算方法です。Amazon Connectの公式指標定義でも、待機中の顧客切断と折り返し待ちを区別しています。自社で集計する際は、利用中の製品の仕様を優先してください。

例えば、ある30分間に着信試行が100件あり、10件は容量超過で受付に入れず、90件が待ち行列に入り、そのうち18件が発信者の切断で終了したとします。これは説明用の架空例です。

この場合、待ち行列に入った90件を分母にすれば放棄の割合は20％、全着信試行100件を分母にすれば18％です。どちらも計算できますが、測っている範囲が異なります。容量超過の10件も別に記録し、改善前後で定義を変えないことが重要です。

短時間の切断、折り返し受付、同じ人のかけ直しを含めるかも決めます。着信時刻で対象をそろえ、集計締め時点でまだ待機・対応中の電話は未確定として残すと、期間をまたぐ通話の扱いも確認できます。

原因別に選ぶ、あふれ呼を減らす対策

担当者の人数を見るときは、在籍人数ではなく、その時間に電話へ応対できる人数を使います。通話後の記録作業や休憩を含めずに見積もると、受けられる量を過大に考えがちです。

平均通話時間を短くするために、説明を途中で切り上げる運用は避けます。保留や重複確認を減らし、同じ用件でのかけ直しが増えていないかも確認してください。

折り返し受付は、IVRでも検討できます。NTTドコモビジネスのあふれ呼対応ダイヤルは、そのサービス例です。必要なのが短い連絡先受付なのか、会話で用件を整理することなのかを決めてから方式を選びます。

AI電話を使うときは、受付後までつながるフローにする

AI電話は、登録した情報の案内や用件の聞き取りなどを一次受付に組み込む選択肢です。AIが電話に出たこと、用件を記録したこと、人が対応を引き受けたこと、問題が解決したことを別の状態として管理します。

混雑時にどこからAIへ回すか

対象は「担当者が応答できない場合」「決めた待ち時間を超えた場合」「特定の用件」「受付時間外」などから選びます。以下は運用の設計例で、Bellの標準設定や導入実績を示すものではありません。

1. 回線・受付システムで混雑を検知し、設定した条件でAI受付へつなぐ。
2. AI受付であることを案内し、用件を短く聞く。
3. 確認済みの定型案内は回答し、判断が必要な用件や人を希望する電話は担当者へ回す。
4. 転送先が応答しない場合は、予備連絡先や折り返し受付など、決めた経路へ進む。
5. 折り返しを希望する場合は、必要な連絡先と連絡可能な時間を確認し、担当者・対応期限を記録する。
6. 担当者が内容を確認したか、期限までに対応したかを点検する。

回線の入口が埋まった時点でAIへの転送も始められない構成では、AI側の受付能力だけを増やしても届きません。着信、転送、AI受付、有人転送の各段階で、同時利用の条件と上限時の動作を確かめます。クラウドサービスであっても無制限とは限りません。

人につながらないときの案内を決める

転送先が話し中、不在、留守番電話になった場合の動作を分けてテストします。通話の接続を試みただけで「担当者へ引き継ぎ済み」にせず、担当者の応答や受領を確認できる状態を設けます。

折り返しを受け付ける場合は、実際に連絡できる担当者と時間を確保してください。確認できない折り返し時刻や手配の完了をAIに約束させないようにします。人を希望する電話、聞き返しが続く電話、定めた緊急条件に該当する電話の切り替え先も事前に決めます。

Bellでは、条件に応じて担当者へ接続する転送・CTI機能を紹介しています。既存の回線で使える転送方式、予備連絡先への切り替え、接続失敗時の処理は、自社の希望する動作を示して確認してください。

聞き取る情報と共有先を絞る

一次受付では、用件の分類と引き継ぎに必要な項目を先に決めます。折り返しに不要な住所や詳細な個人事情まで、一律に聞き出す設計は避けてください。連絡先は復唱などで確認し、誤記による再連絡の失敗を点検します。

録音・文字起こしを行う場合の案内、保存目的・期間、閲覧できる担当者、削除方法、AI学習への利用条件も確認します。通知は必要な担当者へ届く範囲に絞り、要約の送信だけで対応完了にしない運用にします。

試験導入で確認すること

まずは一つの窓口・用件・時間帯に範囲を限定し、比較する条件と停止基準を決めます。導入前後で曜日、受付時間、着信数、用件、配置人数が違えば、その差も評価に残してください。

切り替える前のチェックリスト

• ピーク時の同時着信と、回線・AI・転送先の上限を確認したか
• 対象外の質問に推測で答えず、人への確認に切り替えられるか
• 人を希望する電話、聞き取りが難しい電話を引き継げるか
• 転送先不在、通知遅延、連携エラーでも未対応案件を追跡できるか
• 折り返し担当者、期限、期限超過を確認する責任者が決まっているか
• 障害時に既存の受付へ戻す手順と、切り替えを判断する人が決まっているか

応答率と一緒に見る指標

率だけでなく件数と対象期間も残します。応答率が上がっても、未対応案件や誤案内が増えていれば運用を修正する必要があります。重要な引き継ぎ漏れ、権限のない約束、復旧経路の不具合が見つかった場合は、対象の自動受付を止めて既存受付に戻し、修正後に再テストします。

Bellであふれ呼対策を検討するには

Bellの機能一覧では、シナリオ設計、用件の聞き取り、転送、通話記録などを確認できます。通話履歴・AI要約は、受け付けた内容や要対応事項を担当者が確認する際の機能です。AIの要約は必要に応じて通話記録と照合し、人が対応を引き受けたかを別に管理します。

検討時には、通常時とピーク時の着信状況、現在の回線・転送構成、任せたい用件、人へつなぐ条件、折り返し体制をまとめておくと確認が進めやすくなります。同時受付数、利用料金、転送失敗時の動作、記録・通知の条件は個別に確認してください。

あふれ呼対策は、入口の接続、受付の正確さ、その後の対応完了までを一緒に評価することが大切です。まずはログから詰まっている場所を見つけ、範囲を絞った試験で改善を確かめましょう。