AI電話受付サービスの商談では、きれいに話した一件だけを試しても導入後の動きは判断できません。会社名を言い直す電話や用件が曖昧な電話、担当者が出られない電話まで同じデモで確認してください。

三つのテスト通話を候補各社へ渡します。正常に受付できる通話と、聞き取りにくい通話、取次ぎ先が応答できない通話です。AIの会話だけでなく、受付結果を担当者が確認して次の行動へ移れるところまで見ます。

この記事では、機能の有無を尋ねる質問を、受付業務を判断できる実演へ変えます。商談前に決める受付範囲はAI電話受付の要件定義で決める受付範囲で整理してください。

三つのテスト通話と完了条件を渡す

最初に対象用件を一つ選びます。代表電話の一次受付なら、誰から何の用件で電話があり、担当者が次に何をすれば受付完了かを決めてください。

正常な通話では会社名と氏名、用件を伝えます。二本目は会社名を言い直し、用件を途中で変更します。三本目は無言の時間を置いた後、対象外の質問をしてください。

各通話には終了状態を置きます。受付完了と有人取次ぎ、折り返し受付を分けます。聞き取り不能と対象外も必要です。通話が切れただけの一件を受付完了へ含めません。

質問は「自然に会話できますか」ではなく、「三本の通話を終了状態と受付記録へどう残しますか」とします。各社が同じ通話を処理すれば、音声の印象だけでなく業務結果を比較できます。

聞き取りと訂正を受付記録で確認する

聞き取り精度は、正しく認識した割合だけでは判断できません。会社名と人名、電話番号を一度ずつ言い直します。AIが確認のために読み上げ、相手が訂正した後の値を見てください。

デモでは音声認識の途中表示ではなく、最終的な受付記録を確認します。訂正前の値が残るのか、担当者に渡る値はどちらかを質問してください。数字は桁を変えて再確認します。

用件を「営業の件」から「契約内容の確認」へ言い直す通話も試します。最初の分類を維持するのか、最新の発言で更新するのかを見ます。担当部署の候補が変わった場合は、どの条件で取次ぎ先を決めるか聞いてください。

受付後に人が修正できる範囲も確認します。修正者と時刻、元の値が残るかを見てください。修正した結果が通知やCRMへ反映されるかも実演対象です。

無言と対象外用件の終わり方を見る

相手が話さない場合と、AIが用件を理解できない場合を分けます。聞き直しの回数と待ち時間を確認し、それでも判断できないときの案内を見せてもらってください。

Dialogflow CXの状態ハンドラー資料は、入力がない状態と意図が一致しない状態を別のイベントとして扱います。段階ごとのハンドラーも設定できます。実装は製品ごとに異なりますが、無言と理解不能を同じ失敗へまとめない質問の参考になります。

商談では無言を二回続ける通話と、対象外の質問を繰り返す通話を試します。有人受付へ渡すのか、折り返しとして記録するのかを確認してください。営業時間外なら別の終わり方になるかも見ます。

終了後は、失敗理由を一覧から抽出できるか質問します。聞き取り不能が受付完了へ混ざると、担当者へ届かなかった電話を数えられません。再入電があった場合に前回の失敗と関連付けられるかも確認してください。

取次ぎは時間外と担当者不在で試す

有人取次ぎは、電話番号へ転送できることだけでは不十分です。営業時間内で担当者が応答できる場合と、時間外、担当者不在の三条件を試します。

Amazon Connect Customerの標準キュー転送フローは、営業時間を確認した後に担当者が利用可能かを判定します。担当者がいない場合は、案内して通話を終了する分岐があります。候補製品にも、時間外と不在を分けて質問してください。

転送中は、相手へ流れる案内と待ち時間を確認します。担当者へは発信者情報と用件、聞き取り結果が渡るかを見ます。担当者が応答した時点で、同じ質問を最初から聞き直さなくてよい状態が必要です。

不在時は折り返しへ切り替えます。担当と期限を受付記録へ残せるか確認してください。相手への案内と担当者への通知が両方完了して、初めて折り返し受付として数えます。

混雑とキュー満員後の処理を聞く

通常時に取次ぎできても、着信が重なると転送先が埋まります。通常時と昼休み前後、キャンペーン実施日の三条件を渡してください。入電件数と平均通話時間、取次ぎ率を各条件へ置きます。

Amazon Connect Customerのキュー管理資料は、担当者の配置状況とキュー容量を確認してから転送する方法を示しています。キューが満員の場合は成功と同じ経路へ進みません。商談でも混雑と満員を別に扱います。

質問するのは最大同時通話数だけではありません。AI受付の上限と電話回線、取次ぎ先の上限を分けます。上限を超えた電話が話中になるのか、AI受付後に折り返しへ変わるのかを確認してください。

同時着信をデモで再現できない場合は、負荷試験の資料を依頼します。試験時の件数と通話時間、取次ぎ率が自社条件と違う場合は、その差を見積もりの前提へ残してください。

通知は届かなかった場合まで追う

メールやチャットへ通知できるという説明だけでは、受付完了を判断できません。通知に含まれる受付IDと用件、発信者情報を確認します。担当者が次に行うことと期限も必要です。

商談では通知先を一時的に無効にします。送信失敗をどの画面で見つけ、誰へ代替通知するかを実演してもらってください。自動再送の回数と間隔、手動再送も確認します。

Amazon SNSのデッドレターキュー資料は、クライアント側またはサーバー側のエラーで配信できないメッセージを保存し、分析や再処理に使う方法を示しています。これは特定の通知基盤の仕様ですが、通知失敗を消さずに復旧できるかを聞く根拠になります。

通知済みと受領済みは分けてください。担当者が通知を開いたか、折り返しを完了したかをどこまで追えるか質問します。未確認のまま期限を過ぎた受付を、別の担当へ回せるかも比較項目です。

録音と受付結果の生成状態を分ける

録音が有効でも、通話終了と同時に利用できるとは限りません。商談では通話終了後に、録音と文字起こし、要約が使えるまでの時間を確認してください。

TwilioのVoice Webhooks資料は、通話状態と録音状態を別のコールバックで通知します。録音には処理中と完了、欠損、失敗の状態があります。候補製品でも、録音がない受付を空欄ではなく生成失敗として抽出できるか質問します。

実演には短い通話と長い通話を使います。録音はあるが文字起こしがない場合と、要約だけ生成されない場合の表示を確認してください。再処理の可否と担当者への通知も必要です。

閲覧権限は管理者と一般担当者で比較します。録音の再生とダウンロード、削除を誰が行えるかを見ます。保存期間と契約終了時の出力、削除完了の確認方法は正式資料へ残してください。

実演結果を受付台帳と見積もりへ残す

商談後は、一通話ごとに終了状態と受付記録を残します。口頭回答と実演結果、参照した仕様書を分けてください。条件付きの回答には、営業時間と件数、対象用件を書きます。

費用は通常時と混雑時、営業時間外を含む三条件で見積もります。電話番号と受電、AI応対、有人取次ぎを分けてください。通知と録音・文字起こし、有人電話代行、運用支援も同じ条件へ入れます。

候補を絞る基準は、会話の自然さだけではありません。聞き取り不能を検知し、担当者不在時に折り返しへ切り替え、通知失敗を復旧できることを先に確認します。その上で、通常時と混雑時の費用を比較してください。

AI電話受付の比較表へ三通話の結果を転記すると、候補を同じ終了状態で比べられます。受付範囲や取次ぎ先が定まらない場合は、相談窓口で確認項目を整理できます。