インバウンド営業の問い合わせ対応に、AIボイスエージェント（音声で自動対話する仕組み）を導入する企業が増えています。しかし営業担当者から「結局使えない」と言われるケースは少なくありません。CRM（顧客管理システム）連携を含む問い合わせ対応フローを設計・運用する立場の方に向けて、何が原因で、どこを見直せば実務に耐える仕組みになるのか整理します。
Ant Engage社がFonix.AIの実践ガイドとして公開した内容は、B2Bの製品・サービス問い合わせ（デモ依頼など）向けの音声リード選定（lead qualification、問い合わせの内容を確認し営業対応の優先度や担当を決める作業）を対象にしています。不動産の内見予約や学校の入学相談など、別の業務要件を持つシナリオは対象外とされている点も押さえておく必要があります。自社のユースケースがB2B問い合わせ対応に当てはまるかどうか、最初に確認しておくとよいでしょう。
「つながった」「ホット判定」では不十分な理由
AIボイスエージェントの成果を测る指標として、通話が成立したかどうか、自動で「ホット（確度が高い）」ラベルが付いたかどうかを見てしまいがちです。しかしこれらは、営業がそのリードに対応すべきかどうかを判断する材料にはなりません。
本当に必要なのは、買い手が述べた具体的なニーズ、未解決の質問、適切な営業担当者、そして合意された次のアクションの4点です。この4点が揃って初めて、営業担当者は会話の続きを引き継げます。逆に言えば、通話ログやスコアだけを渡されても、担当者はゼロから状況を聞き直すことになり、結局「使えないツール」という評価につながります。
既存の問い合わせ管理システムやCRMを運用しているチームであれば、この4点のうち自社のシステムで記録・参照できる項目がどれかを棚卸しすることが、最初の具体的な一歩になります。
問い合わせを「イベント」として正しく扱う設計
フォーム送信は完結した顧客情報ではなく、1件のイベントとして扱う必要があります。送信元、タイムスタンプ、問い合わせ参照ID、製品関心、連絡希望方法を保持したまま、CRM上の既存レコードと突き合わせる処理が欠かせません。
同じ電話番号が複数の問い合わせに紐づくことや、1社から複数人が同じ製品を検討しているケースは珍しくありません。CRMに既にアカウントマネージャーが割り当てられている場合、AIエージェントが独立して架電し、既存の営業活動と競合してしまう事態は避ける必要があります。
この設計上の論点は、重複イベントの扱い、後日の折り返し希望者の扱い、連絡不要になったレコードの扱いという3つの運用ルールに集約されます。既存の問い合わせ管理フローに、これら3ルールが明文化されているかどうか、まず確認してみてください。耐久性のある問い合わせ参照IDと、1件につき1つのアクティブなタスクという原則があれば、複数のエージェントが同じ相手に同時に電話をかけてしまう事故を防ぎやすくなります。
通話の冒頭でも、架電元の会社名を名乗り、自動応答であることを明示し、実際の問い合わせ内容を参照したうえで、通話可能なタイミングかを確認する流れが推奨されています。相手が問い合わせの記憶がないと答えた場合は、無理に質問スクリプトを続けず、その反応自体を記録する設計が求められます。
要件は聞くが、確信はでっち上げない
次に重要なのが、ヒアリング項目の設計です。質問は「次のアクションを変える答えが返ってくるか」を基準に選ぶ必要があります。
| 質問 | 有用な回答 | 混同してはいけないもの |
|---|---|---|
| 解決したい課題は何か | 買い手自身の言葉による課題と現状のプロセス | 担当者側の緊急度の解釈 |
| どのチームが使うか | 利用部門と概算の利用規模 | 全社展開という推測 |
| 何と連携する必要があるか | 具体的なシステム名と必要な処理 | 連携可能という約束 |
| 評価したい時期はいつか | 明言された日付、または未定という回答 | 推測による導入期限 |
ここで強調されているのは、「20人ではじめて将来200人になるかもしれない」という発言を、現在の200席の要件に変換してはいけないという点です。予算についても、未回答であれば未回答のまま記録するべきで、「まず仕組みを理解したい」という回答を低品質な見込み客の証拠として扱うべきではありません。
スコアリング（定性的な回答を点数化する仕組み）を導入する場合は、採点基準を文書化し、スコアの根拠となった回答を参照できる状態にしておく必要があります。トランスクリプト（通話の書き起こし）、構造化された回答項目、算出されたスコア、人間が下した判断は、それぞれ別レコードとして保持し、営業担当者がスコアの根拠を会話全体を聞き直さずに検証できるようにする設計が推奨されています。
ルーティングと引き継ぎの検証
要件が整理できたら、テリトリー・製品・アカウントに関する既存の営業ルールと照らし合わせ、次の宛先を決めます。結果はデモ予約、技術担当との商談、後日の折り返し、あるいは初期質問への回答のいずれかになります。
デモを予約する場合は、空き状況を確認し、具体的な日時で合意し、カレンダーへの書き込みが実際に成功したかを検証する必要があります。折り返しを割り当てる場合は、受け手の担当者と希望時間を記録し、担当者が引き受けたことが確認できるまでは「折り返し希望があった」というステータスのまま扱う設計が示されています。
日本の現場で確認しておきたいこと
国内でも、SFA（営業支援システム）やCRMと連携したIVR（自動音声応答）、チャットボット経由のリード一次対応は広く使われています。ただし今回扱った設計思想は、単なる自動応答の導入ではなく、既存のCRMレコードとの突合、担当者の引き継ぎ検証、スコアの追跡可能性という、既存システムとの統合設計に重点があります。
既にCRMやSFAを運用している組織であれば、新しい音声AIツールを選ぶ際に次の点を確認すると判断がしやすくなります。
- 問い合わせイベントと既存アカウントの突合処理が設定できるか
- 既存の担当者がアサイン済みの場合に自動架電を抑止できるか
- トランスクリプト・回答項目・スコア・人間の判断を別レコードとして保持できるか
- カレンダー書き込みや折り返し割り当ての成否を後から検証できるか
これらはベンダーのデモ画面だけでは分かりにくい部分なので、PoC（概念実証）の段階で実データに近いシナリオでテストしておくと、本番導入後のトラブルを減らせます。
まとめ
AI音声リード選定の価値は、通話の成立数やホット判定の自動付与では測れません。買い手の発言・未解決の論点・担当者・次アクションという4点が、既存のCRMやSFAと矛盾なく連携されているかを確認する必要があります。
導入を検討しているなら、まず自社の問い合わせ管理フローにおける重複処理ルール・担当者引き継ぎルール・スコアの根拠追跡の有無を棚卸しし、ベンダー選定時のチェックリストとして使ってみてください。