なぜ「どこで人に渡すか」で迷うのか
電話営業でAIを使い始めると、多くの会社が最初につまずくのが「どこまでAIに任せて、どこから人に渡すか」という線引きです。この線引きが曖昧だと、AIが本来つなぐべき相手を逃したり、逆に人が対応しなくていい電話まで抱え込んだりします。
ある人材派遣会社の検討では、早朝の出発確認や欠勤連絡といった一次対応をAIに任せ、複雑な交渉や判断が必要な場面だけ人にエスカレーションする設計が話し合われていました。ここで問題になったのが「AIがどう判断したら人に回すか」という基準です。
別の営業の現場では、架電した相手を反応の強さでランク分けし、関心が高い相手だけをその場で担当者に転送する運用が検討されていました。逆に反応が弱い相手は、後で改めて架電するリストに回すという考え方です。
つまり「どこで人に渡すか」は、会話の内容そのものより、事前に決めた判断基準で決まります。基準がないままAIを動かすと、担当者が対応すべきでない電話まで転送されたり、逆に重要な電話が記録だけで終わったりします。
よくある失敗は、「とりあえず全部転送」か「とりあえず全部記録だけ」で始めてしまうことです。前者は担当者の手が塞がり、後者はせっかくの見込み客を取りこぼします。まずは自社にとっての転送すべき相手を言葉にすることが出発点です。
転送の判断基準をどう作るか
判断基準を作るときにまず整理したいのが、「何を測って」「どう転送するか」の2つです。多くの現場では、通話が成立したかどうかと、相手の反応の強さを組み合わせて判断しています。
たとえば、ある企業の活用例では、通話がすぐに切れた相手と、1分以上会話が続いた相手を分けて考えていました。会話が続いた相手はニーズがある可能性が高いと見なし、そのまま担当者へ転送する運用です。
逆に、会話は続いたものの温度感が低いと判断された相手は、その場で転送せず、後日改めて架電する対象としてリストに戻していました。これは「転送する・しない」の二択ではなく、段階を分けて扱うという考え方です。
判断基準を作るときに見落としやすいのが、「担当者が受けられる件数」です。基準を緩くしすぎると、対応できる数を超えて転送が発生し、かえって取りこぼしが増えます。
基準は最初から完璧である必要はありません。まずはシンプルな2〜3段階の基準から始め、実際の会話ログを見ながら調整していく方が現実的です。
転送ルールの3つのパターンを比較する
転送のルールは大きく3つのパターンに分けられます。全件転送、条件付き転送、そして転送をせず記録だけを残すパターンです。どれが正解ということではなく、業務内容によって向き不向きがあります。
| 観点 | 全件転送 | 条件付き転送 | 転送なし(記録のみ) |
|---|---|---|---|
| 向いている場面 | 架電数が少ない | 反応にばらつきがある | 一次確認が中心 |
| 担当者の負担 | 大きい | 中くらい | ほぼ無い |
| 取りこぼしのリスク | 低い | 基準次第 | 高い |
| 向かない場面 | 架電数が多い | 基準が曖昧 | 商談化が目的 |
全件転送は、架電数が少なく取りこぼしを避けたい場面に向いています。ただし架電数が増えると、担当者の電話が鳴りっぱなしになり、本来の商談対応に支障が出ます。
条件付き転送は、反応の強さで振り分けたい場面に向いています。ただし基準が曖昧だと、担当者から「これは転送しなくてよかったのでは」という不満が出やすくなります。
記録のみのパターンは、出発確認や欠勤連絡のような一次対応が中心の業務に向いています。複雑な判断だけを人に回す設計と相性がよい形です。
よくある失敗は、業務の性質を確認せずに「とりあえず条件付き転送」を選んでしまうことです。架電の目的が商談化なのか、一次確認なのかで、選ぶべきパターンは変わります。
転送までの手順を設計する
転送ルールを決めたら、次は実際の通話の流れの中でどこに転送の判断を入れるかを設計します。ここが曖昧だと、AIが判断に迷ったまま通話を続けてしまいます。
- 1応答AIが名乗り、用件を伝える
- 2ヒアリング相手の反応と状況を聞き取る
- 3判定事前に決めた基準で振り分ける
- 4転送 or 記録担当者に回すか、リストに戻す
この4段階のうち、現場でつまずきやすいのは「判定」の部分です。判定基準が数値化されていないと、AIも人も何を根拠に転送したのか説明できなくなります。
たとえば人材派遣会社の検討では、複雑な交渉が必要な場面をAIが一次受けし、対応内容を記録した上で人にエスカレーションする設計が話し合われていました。記録が残ることで、引き継いだ人が経緯をすぐ確認できます。
逆によくある失敗は、転送はするものの、何を話したかの記録が引き継がれないケースです。担当者が「何の電話か分からないまま出る」状態になり、相手にも不信感を与えます。
手順を設計するときは、転送する直前にAIが何を伝えるかも決めておくべきです。「担当の者におつなぎします」の一言があるかないかで、相手の受け止め方は変わります。
導入前によくある失敗と避け方
転送の設計でつまずく会社には、いくつか共通したパターンがあります。ひとつは、転送先の担当者が受けられる体制を確認しないまま設計を進めることです。
ある企業の検討では、導入効果を測るために「人員を減らせるか」「転送数が想定を超えないか」といった具体的な基準を先に決めてから試験運用に入っていました。基準がないまま始めると、効果があったのか判断できません。
もうひとつよくある失敗は、既存のシステムとの連携や、担当者ごとの出勤時間といった前提情報の整備を後回しにすることです。前提のデータが整っていないと、AIは誰にいつ電話をかけるべきか判断できません。
また、担当者への引き継ぎ期間を設けずに一気に切り替えるケースも失敗につながりやすいです。並走期間を設けて、AIと人が並行して対応する期間を数か月確保すると、現場の混乱を避けられます。
社内で決めておくべきことは、転送を受ける担当者の受け入れ時間帯、転送されなかった相手の扱い、そしてエスカレーションが発生したときの連絡手段の3つです。これらを事前に決めておくと、運用開始後の混乱がぐっと減ります。
判断に迷う場面での考え方
転送の設計を進めていくと、「この場面は人が出るべきか、AIのままでいいか」判断に迷う場面が必ず出てきます。そういうときは、自社の運用が今どの段階にあるかを意識すると整理しやすくなります。
多くの会社は最初、段階1の「全部人が対応」から始まり、架電量が増えるにつれて段階2の「AIが一次対応」に移っていきます。ここでの迷いどころは、どこまでAIに任せて、どこから人に戻すかという線引きです。
迷ったときの考え方はシンプルで、判断に交渉や感情への配慮が必要な場面は人に回し、定型的な確認や振り分けはAIに任せるという分け方です。謝罪や条件交渉のような場面は、人の声のほうが相手の納得を得やすい傾向があります。
逆に、出発確認や在庫確認のような定型のやり取りは、AIが一次対応しても違和感は出にくいものです。判断に迷ったら「この電話は交渉が発生するか」を自問してみてください。
段階3の「AIが振り分けまで完結」まで進めるのは、基準が十分に固まってからで構いません。焦って段階を飛ばすと、かえって取りこぼしや誤転送が増えます。
社内で決めておくこと
AIから人への転送を運用に乗せる前に、社内で言葉をそろえておきたい項目があります。ここが曖昧なままだと、現場ごとに解釈が変わり、転送の質にばらつきが出ます。
- 転送先:誰が、どの時間帯に受けるか
- 転送基準:何をもって「関心が高い」とするか
- 記録の残し方:会話内容をどこにどう残すか
- エスカレーション:判断に迷ったときの連絡手段
- 振り返りの頻度:基準をいつ見直すか
たとえば、ある人材派遣の検討では、転送先の担当者が出勤する時間より前にAIが一次対応し、複雑な案件だけを引き継ぐ設計にしていました。受け入れ時間帯を先に決めていたからこそ、AIの稼働時間も決めやすくなっていました。
記録の残し方も重要です。会話のログが自動で残らないと、引き継いだ担当者は「なぜ転送されたのか」を毎回聞き直すことになり、AIを使う意味が薄れます。記録と転送はセットで設計するべきです。
振り返りの頻度も決めておくと安心です。最初に決めた基準が、実際の会話データを見ると合っていないことはよくあります。月に1回程度、基準を見直す時間を作ることをおすすめします。
これらを決めずに走り出すと、現場から「聞いていない電話が来た」「なぜこの電話は転送されなかったのか」といった声が出やすくなります。事前の言葉合わせが、後のトラブルを減らします。
まとめ
明日やることとしては、まず自社の架電のうち「明らかに転送すべき相手」と「明らかに転送しなくていい相手」を1つずつ言葉にしてみることです。この2つの言葉があるだけで、判断基準づくりの土台ができます。
ただし、この基準を人の電話だけで回そうとすると、必ずどこかで詰まります。担当者が兼務で手が空かず、反応の強い相手を後回しにしてしまったり、断られた相手への再架電が積み残されたまま忘れられたりする場面です。
この壁を、AI音声エージェントでの一次架電に任せると、状況は変わります。時間帯を選ばずに架電でき、会話の記録が自動で残るため、担当者は転送された相手だけに集中できます。断られた相手も記録に残るので、再架電の積み残しが減ります。
ただし、向き不向きは会社の架電数や商談の性質によって変わります。まずは自社の架電件数と、今つまずいている条件を整理したうえで、無料相談で自社に合うかどうかを確かめてみてください。




