電話が集中する時間帯になると、オペレーターは目の前の通話を終えるだけで精いっぱいになる。通話が終わっても、問い合わせ内容の入力や担当部署への連絡が残り、次の電話に出られない。コールセンターの自動化を考えるときは、こうした一連の業務のどこに負荷がかかっているかを分けて見ることから始めます。

営業時間を答える電話と、注文内容を確認して変更する電話、相手の事情を聞きながら解決策を探す電話では、必要な仕組みが異なります。「電話対応をAIに置き換える」と大きく捉えるより、案内、聞き取り、照会、手続き、記録、引き継ぎに分けると、自動化する範囲と人が担う範囲を具体的に決められます。

本記事では、コールセンターの責任者や電話業務の改善担当者に向けて、業務の選び方から試験運用、効果測定までを説明します。業種別の場面は導入設計を考えるための例であり、Bellの特定顧客の実績や成果を示すものではありません。

コールセンター自動化で変えられる業務

「受付」と「解決」を分けると、必要な仕組みが見える

自動化の最初の到達点は、必ずしも問い合わせの完全解決ではありません。たとえば、営業時間外に電話した顧客から氏名、連絡先、用件を聞き、翌営業日の担当者に渡すだけでも、留守番電話を聞き直して転記する作業を減らせます。一方、その電話を「解決済み」と扱うと、翌日の折り返しが抜け落ちます。受付完了と業務完了を別の状態として管理することが重要です。

配送状況の問い合わせを自動で解決したい場合は、さらに仕組みが必要になります。注文を特定し、本人確認を行い、配送システムの最新情報を取得したうえで、電話口で理解しやすい言葉にして伝えます。注文が見つからない場合や、表示された情報と顧客の認識が違う場合には、担当者が調査できるようにします。自然に会話できることだけでは、この業務は完結しません。

導入前には「AIが電話に出る」「必要事項を聞ける」「システムを更新できる」「顧客の用件が解決する」のうち、どこまでを目指すのかを書き分けてください。同じ予約受付という名前でも、希望日時を預かるのか、その場で予約を確定するのかによって、連携、テスト、責任範囲が変わります。

IVR、ボイスボット、有人対応を組み合わせる

番号選択式のIVRは、用件の分類や担当窓口への振り分けを、決められた分岐で行いたいときに候補になります。ボイスボットは、顧客が話した用件を受け取り、必要な項目を質問しながら受付や案内を進める仕組みです。生成AIを使う場合も、参照できる情報や実行できる操作の範囲は、業務に合わせて定める必要があります。

すでにIVRが機能している窓口なら、すべてを入れ替える必要はありません。入口の振り分けは既存のIVRで続け、特定の問い合わせだけをボイスボットへつなぎ、例外は有人窓口へ戻す構成も検討できます。比較すべきなのは名称の新しさではなく、顧客が迷わず用件を伝え、必要な処理へ進めるかどうかです。

会話方式の違いを詳しく整理したい場合は、IVRの仕組みと導入の考え方、製品を比較する段階ではボイスボットの選び方も参考になります。

自動化する業務の優先順位を決める

件数だけでなく、完了条件と失敗時の影響を見る

まず、通話記録や対応履歴から、問い合わせの内容、発生する時間帯、通話後に必要な作業を確認します。件数の多い用件を知るだけでなく、同じ分類の中にどれだけ例外があるかを調べます。「予約変更」が多くても、空き枠への単純な変更と、キャンセル料の説明や複数予約の調整が必要な変更を一つにまとめると、難易度を見誤ります。

最初の候補にしやすいのは、回答や処理の基準が明確で、結果を確認でき、失敗しても人へ戻せる業務です。営業時間の案内は回答を確認しやすく、折り返し受付は必要事項がそろったかを判定しやすい業務です。対して、返金の例外承認や契約条件の交渉は、関係者の判断が必要になるため、最初は一次受付や情報整理までに範囲を区切る方が設計しやすくなります。

この表は一般的な検討の出発点です。実際の範囲は、既存システムで取得できる情報と、現場の運用ルールで決まります。予約管理システムと接続できない段階なら、予約を確定するより、希望を受け付けて担当者が確認する方が適切な場合があります。

平均的な一日より、負荷が集中する時間を確認する

一日の合計着信数が同じでも、午前中の短い時間に集中する窓口と、終日分散している窓口では対策が変わります。前者では、待ち時間やつながらなかった電話への対策が重要です。後者では、通話後の入力や担当部署への照会が、実際の負荷になっているかもしれません。

電話に出られないことが主な課題なら、放棄呼、話中、営業時間外の着信を分けて調べます。呼量に対して回線や同時処理数が足りない場合と、人の応答待ちで切断される場合では、必要な変更が異なります。あふれ呼の原因と測定方法に沿って原因を整理すると、自動受付をどこに置くべきか判断しやすくなります。

業種別に考える、受付から引き継ぎまでの活用例

以下は、実際の業務の流れを検討するための想定例です。連携先のシステムが対応していることや、必要な運用条件を満たすことを前提としたもので、Bellによる標準対応や効果を保証するものではありません。

美容室・サロン：施術中の電話を受け、予約の取り違えを防ぐ

施術中にスタッフが電話へ出ると、接客が中断します。ここで自動受付を使う場合は、まず新規予約、予約変更、店舗への質問を分けます。予約なら希望店舗、メニュー、日時を順に確認し、予約台帳と連携できる場合は候補枠を提示します。

注意したいのは、施術時間がメニューや担当者によって変わることです。単にカレンダーの空き時間が見えるだけでは、予約可能とは限りません。必要な時間や設備の条件まで確認できない場合は、希望内容を預かってスタッフに渡し、「予約はまだ確定していない」と明確に伝えます。変更の場合も、既存予約を特定してから新しい内容を確認し、古い予約だけが消えるような中途半端な処理を防ぎます。

評価するのは、受けた電話の数に加えて、スタッフの中断時間、予約情報の訂正件数、折り返しが必要になった件数です。AIとの会話が終了していても、スタッフが毎回確認し直しているなら、聞き取り項目や連携の見直しが必要です。

医療機関・クリニック：一般案内と個別の相談を分ける

診療時間、所在地、予約窓口といった一般案内は、承認された内容に沿って回答する設計が考えられます。予約の問い合わせも、希望日時を受け付ける業務と、医療上の条件を踏まえて予約可否を判断する業務を分けます。

症状、検査結果、薬の使い方などの相談を、一般的なFAQと同じ経路で回答させないことが大切です。たとえば検査結果についての電話なら、結果を説明するのではなく、適切な窓口へつなぐための受付に範囲を限定します。緊急性が疑われる連絡については、医療機関が定めた案内基準と、有人窓口が不通だった場合の対応を、導入前に医療責任者と確認します。

この領域では、受付時間が短くなったかだけでなく、担当者へ渡すべき相談が確実に渡ったかを評価します。自動化率を上げるために、判断が必要な電話をAIにとどめる運用は避けます。

EC・小売：注文を特定してから、照会と手続きを分ける

「商品が届かない」という電話には、配送状況を知りたい場合と、配送先を変更したい場合、紛失の調査を求める場合があります。最初に注文を特定し、相手の希望を確認してから処理を分けます。配送システムで状態を取得できれば案内し、情報が更新されていない場合や顧客の申告と食い違う場合は、調査案件として担当者へ渡します。

返品・交換も同様です。返品希望を受け付けることと、返品条件を満たすと判断して返金を確定することは別の業務です。注文番号、商品、理由などを整理するところまでを自動化し、個別判断が必要な案件は人が確認する構成なら、境界を定めやすくなります。

また、システムへの登録が失敗しているのに、電話では「受け付けました」と案内しないようにします。受付情報が保存されたことを確認してから完了を伝え、失敗時は再確認や有人対応へ切り替えます。

不動産：最新情報の確認と内見希望の受付をつなぐ

物件の空室状況や内見日時は、時間の経過で変わります。AIが参照する情報を更新していても、実際の申込状況との間に差が生じる場合があります。どのシステムを正しい情報源とするか、いつの時点の情報を答えているかを決め、確認できない内容は担当者へ渡す設計にします。

内見の問い合わせでは、対象物件、希望日時、連絡先を聞き、担当者が次の行動を取れる形で記録します。鍵の手配や管理会社への確認が必要な物件なら、希望日時の受付をもって内見確定としないようにします。家賃交渉や審査、融資に関する個別相談は、用件を整理して専門の担当者へ引き継ぎます。

導入効果は受付件数だけでなく、担当者が確認に要した時間、訂正が必要だった情報、内見日程が決まるまでの時間で確認します。自動受付の後に同じ質問を繰り返しているなら、引き継ぐ情報の粒度を見直す余地があります。

営業支援：接続後の会話と、担当者の追客を一つの流れにする

発信業務では、電話がつながった後の一次ヒアリング、担当者との日程調整、会話結果の記録が候補になります。相手が話せる状況かを確認し、関心の有無や次に希望する対応を聞き、担当者がフォローできるようにします。相手の断りや連絡停止の希望も、後続の架電対象へ反映できる必要があります。

アポイントを受け付けたら、担当者の予定に登録されたか、相手に伝えた日時と一致しているかまで確認します。会話が盛り上がったことや、前向きな返答があったことを、そのまま商談化と数えないようにします。

発信件数、接続件数、アポイント件数を分けて測ると、改善箇所が見えます。接続率の問題と、接続後の会話の問題では対策が異なるためです。受電窓口の待ち時間や完了率と、発信施策の成果を同じ指標で評価しないことも重要です。

導入は四つの段階で進める

1. 現状を測り、試す業務を一つ決める

試験運用の前に、同じ業務について比較できる記録を残します。通常日だけでなく、繁忙日や曜日による違いも含め、着信数、応答状況、対応時間、通話後の作業、再入電を確認します。記録の量が少ない場合は、効果を断定せず、まず業務の傾向と失敗の種類を把握する期間と位置付けます。

次に、「営業時間外の折り返し受付」「配送状況の照会」など、対象を具体的に区切ります。成功条件も、単なるAI応答件数ではなく、「必要項目が保存され、担当者が確認できる」「正しい情報を案内し、未解決なら引き継げる」といった業務の状態で定義します。誰が導入可否を判断し、誰が日々の記録を確認するかも、この段階で決めます。

2. 会話、連携、人への引き継ぎをまとめてテストする

テストには、想定どおりに答える通話だけでなく、言い直し、沈黙、雑音、途中の質問変更、情報不足を含めます。日付、氏名、住所、注文番号など、誤りが後続の業務へ影響する項目は、復唱や別の確認手段が機能するかを確認します。

予約変更なら「新しい日時を聞けた」だけでは合格にしません。正しい予約が更新され、同じ依頼を再処理しても重複せず、処理が失敗したときには未完了と案内できるかまで試します。読み取りだけの照会と、予約・注文情報を書き換える操作では、テストすべき影響が異なります。

有人引き継ぎも本番に近い形で確認します。転送先が話中のとき、営業時間外のとき、通話が切れたときに、誰が何を受け取るかを実際に試します。問題が出たときに既存の窓口へ戻す手順も用意しておくと、試験の範囲を安全に調整できます。

3. 対象時間や用件を限定して本番運用する

最初の本番運用では、対象の用件や時間帯を限定し、人が記録を確認できる体制を残します。たとえば通常の有人窓口を維持しながら、時間外の受付だけを試す方法があります。どの構成がよいかは、元の課題と、問題発生時に復旧できる体制で決めます。

この段階では、平均値だけでなく実際の失敗例を見ます。ある商品名だけ聞き取れない、特定の質問で同じ説明を繰り返す、折り返し案件が担当者に届いていない、といった具体的な問題を分類します。原因が会話の表現なのか、元の情報なのか、連携なのかを分けると、修正箇所を絞れます。

4. 基準を満たした業務から対象を広げる

対象を広げる条件は、開始前に定めておきます。たとえば、必要項目の欠落、誤った案内、引き継ぎ漏れを確認し、重大な問題が解消されていることを条件にします。数値の目標は一律に置かず、業務のリスクや現状の品質に合わせて決めます。

用件と時間帯を同時に大きく広げると、問題の原因を追いにくくなります。まず同じ用件で対象時間を広げ、その後に次の用件を追加するなど、一度に変える条件を絞ると比較しやすくなります。運用が安定しても、料金、営業時間、キャンセル条件などが変わるたびに、回答内容と会話の分岐を確認する担当者は必要です。

失敗時に困らせない設計が、運用の品質を決める

聞き取れないときは、同じ質問を繰り返し続けない

聞き取りに失敗したとき、まったく同じ質問を何度も繰り返すと、顧客はどのように答えればよいか分かりません。質問を短くする、必要な項目を一つずつ聞く、選択肢を提示するなど、確認方法を変えます。そのうえで解決しなければ、あらかじめ定めた回数や条件で人へつなぐか、折り返し受付へ切り替えます。

相手が担当者との会話を希望した場合も、長い自動会話を続ける必要はありません。用件の複雑さだけでなく、顧客の希望を切り替え条件に含めます。感情の推定だけに頼らず、明示的な申し出、確認不能、対象外の相談といった、確認できる条件を中心に設計します。

引き継ぎは、転送先につながるまで設計する

転送機能があっても、担当者が出なければ引き継ぎは完了しません。転送待ちの上限、不通時の折り返し受付、営業時間外の案内を決め、受付した依頼を担当者が確認するまで管理します。折り返し時刻を約束するなら、実際に対応できる体制と一致している必要があります。

引き継ぐ情報には、用件、確認できた項目、まだ確認できていない項目、処理済みの操作、未解決の点を含めます。要約だけで意味が変わる恐れがある場合に備え、権限のある担当者が元の記録を確認できるようにします。「注文のキャンセルを希望している」のか、「キャンセル処理が完了した」のかを区別するだけでも、二重処理や案内の食い違いを防ぐ設計につながります。

古い情報、連携障害、誤った登録への備えを持つ

回答に使う情報には管理責任者を置き、変更日と内容を追えるようにします。誤った案内が見つかった場合に、その回答だけを止めたり、該当用件を有人対応へ戻したりできる運用を用意します。システム障害時には、確認できていない内容を推測して答えず、受付可能な範囲と次の連絡方法を伝えます。

連携では、情報を読み取る権限と、更新する権限を分けて検討します。予約や注文の更新に必要な権限だけを与え、操作結果を記録し、失敗した処理を確認できるようにします。電話が途中で切れた場合や再入電した場合に、同じ手続きが二重に実行されないかも確認事項です。

KPIは、応答・解決・引き継ぎを分けて測る

自動応答率だけでは成果を判断できない

AIが電話に出た割合が高くても、その後に用件を解決できず、顧客がかけ直しているなら負荷は残ります。反対に、適切に人へ引き継いだ電話は、自動完結率には貢献しなくても、顧客対応として必要な処理です。指標を一つにまとめず、入口、用件の完了、人への引き継ぎを分けて確認します。

上の表は社内で定義をそろえるための例です。製品の管理画面にある指標名と、同じ計算方法とは限りません。たとえばAmazon Connectの公式ドキュメントでは、放棄呼率はキューへ入ったコンタクトを分母に計算し、コールバック待ちのコンタクトは放棄として数えないと説明されています。自社で見たい「電話がつながらなかった割合」と一致するか、集計条件を確認してください。（参考：Amazon Connect公式ドキュメント「Metric definitions」、2026年10月7日確認）

導入前後は、対象業務と集計条件をそろえる

比較期間の長さだけをそろえても、繁忙期と閑散期、キャンペーンの有無、問い合わせの種類が違えば、結果の解釈は変わります。用件、曜日、時間帯などで分けて見ると、自動化が寄与した可能性と、外部条件の変化を切り分けやすくなります。対象件数も併記し、少ない通話から得た割合を全体の成果として扱わないようにします。

自動化によって簡単な問い合わせが減ると、有人窓口には複雑な相談が多く残る場合があります。このとき有人通話の平均時間が長くなっても、それだけでは悪化と判断できません。対象業務全体で使った有人時間、解決状況、再入電、顧客からの指摘を併せて確認します。

費用対効果は、残る有人業務も含めて計算する

利用料以外の費用と、削減できる作業をそろえる

比較には、初期設定、会話設計、システム連携、試験運用の費用に加え、月額料金、従量料金、通話・転送料金、保守改善にかかる費用を含めます。さらに、導入後も残る有人対応、受付内容の確認、誤りの修正にかかる費用を加えます。24時間受付を行う場合も、料金体系や利用量によって費用は変わるため、追加コストがないとは限りません。

比較期間はそろえます。年間で評価するなら、導入前の対象業務の年間費用と、導入後の年間運用費用を比較し、その差額から初期費用を引きます。売上への効果を加える場合は、売上高をそのまま足すのではなく、追加で得られた粗利益を、費用削減とは分けて示します。

仮の数字で見る、回収期間の考え方

以下は計算方法を説明するための仮定であり、Bellの料金や導入実績ではありません。対象業務の導入前費用が月100万円、導入後に残る有人対応が月50万円、システム・通話・保守などが月20万円、初期費用が120万円だったとします。

この場合、導入後の月次費用は70万円で、月の差額は30万円です。この差額が継続すると仮定すれば、初期費用の単純回収期間は120万円 ÷ 30万円で4か月になります。初年度の差引効果は30万円 × 12か月 − 120万円で240万円です。ここでは立ち上がり期間の差や資金の時間価値を考慮していないため、実際の予算では移行中の二重運用や利用量の変動も反映します。

ROIを使う場合は、何を投資額に含めるかを明記します。たとえば「対象期間に得られた効果から自動化の総投資額を引き、その総投資額で割る」と定義するなら、初期費用と継続費用をどちらにも重複計上しないようにします。まずは導入前後の費用表と回収期間を示し、そのうえで社内の投資評価の定義に合わせると、比較がぶれにくくなります。

なお、作業時間が減っても、支払う人件費がすぐに下がるとは限りません。余裕ができた時間を既存顧客へのフォローや難しい相談に振り向ける場合は、支出削減と、対応余力の創出を分けて報告します。金額に換算した作業時間を、そのまま現金の削減額として計上しないことが重要です。

個人情報と運用体制を、選定時に確認する

通話録音、文字起こし、要約、顧客情報がどこに保存され、誰が閲覧でき、いつ削除されるかを確認します。電話サービスと連携先のCRMで保存期間が違う場合や、録音を削除しても要約が残る場合もあるため、データの種類ごとに扱いを整理します。AIの学習等への利用条件や、委託先・再委託先の範囲も、契約と実際の設定で確認する項目です。

個人情報保護委員会の通則編では、個人データの取扱いを委託する場合に、委託先への必要かつ適切な監督が必要とされています。サービス提供者に任せれば自社の確認が不要になるわけではありません。取り扱う情報に応じて、契約、アクセス権限、保存・削除、事故時の連絡手順を担当部署と確認してください。出典：個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」

現場の運用では、会話内容の責任者、システム連携の責任者、未対応案件を確認する担当者を明確にします。窓口のルールが変わったときに誰が修正し、どのテストを通して公開するかまで決めておくと、導入後の品質を維持しやすくなります。

まとめ：一つの用件を、受付から完了まで設計する

コールセンターの自動化では、対象業務を小さく区切り、完了条件と人へ戻す条件を具体化することが出発点です。会話の自然さに加えて、正しい情報を参照できるか、処理結果を確認できるか、引き継ぎが実際に届くかを検証します。

最初の一歩として、負荷の大きい用件を一つ選び、直近の対応記録から、必要な質問、参照する情報、例外、通話後の作業を書き出してみてください。その内容を基に試験の範囲とKPIを決めれば、製品の比較や見積もりも具体的になります。

Bellへの相談では、対象の用件、月間の通話量、混み合う時間帯、現在の電話・顧客管理システムが分かると、受付範囲や連携条件を整理しやすくなります。電話業務の自動化について相談する