AI電話サービスのデモは、各社の得意な会話を見せてもらうだけでは比較できません。自社の一業務を選び、正常な通話と判断に迷う通話、例外が起きる通話を同じ順番で実演してもらってください。

見る範囲はAIの受け答えだけではありません。通話の終了状態と担当者への引き継ぎ、CRMや受付記録まで確認します。候補ごとに同じ入力と期待結果を渡せば、音声の印象を業務としての合否へ変えられます。

この記事では、四つのAI電話領域に共通して使えるデモシナリオの作り方を説明します。対象はAIテレアポとAI即架電、AIコールセンター、AI電話受付です。方式の違う製品を無理に同じ採点へ入れず、同じ業務を担う候補同士で使ってください。

デモする一業務と完了条件を先に決める

最初に「誰からの、どの電話を、どこまで終えたいか」を一文にします。資料請求者の希望条件を聞いて商談日を確定する、代表電話で用件を聞いて担当部署へつなぐ、といった形です。

一つのデモに複数の目的を入れません。商品説明と本人確認を一緒にすると、候補ごとに自動化する範囲が変わります。予約変更と苦情対応も別の業務です。比較したい業務を一つに絞ってください。

完了条件は通話終了ではなく、次の行動が決まった状態です。日程がカレンダーへ登録された、担当者へ用件が届いた、折り返し担当と期限が記録された状態を完了とします。

対象外の状態も決めます。本人確認ができない場合や専門判断が必要な場合、停止希望があった場合です。AIが無理に完了へ進めず、適切に会話を終えられることを確認します。

三つの通話台本に期待結果を付ける

一つ目は正常な通話です。必要な情報を順番に伝え、予定どおり完了するかを見ます。氏名や会社名、希望条件など、担当者が次に必要とする項目を台本へ入れてください。

二つ目は判断に迷う通話です。会社名を言い直し、質問の途中で話題を変えます。数秒間の無言と、想定していない質問も加えてください。訂正後の値が最終記録へ残るかを確認します。

三つ目は例外が起きる通話です。取次ぎ先を不在にするか、カレンダーの候補日時を直前に埋めます。CRMや通知先を一時的に使えない状態にしても構いません。成功経路へ戻さず、折り返しや再処理へ移れるかを見ます。

台本には期待する終了状態を一つずつ付けます。正常は完了、判断に迷う通話は確認済みまたは有人確認、例外は折り返しや連携再処理です。期待と実際が違った場合に、理由を説明できる状態へします。

入力と前提を候補各社でそろえる

受電デモでは、同じ電話番号から同じ時間帯に電話します。発信デモでは、同じ項目を持つテスト受付または架電リストを使ってください。実在する顧客情報は使わず、試験専用の氏名と電話番号を用意します。

会話の設定には名乗りと目的を渡します。取得する項目と終了条件も必要です。候補各社が独自に台本を作ると、製品ではなく設定担当者の提案内容を比べることになります。最初の比較では共通条件を優先してください。

有人対応の前提もそろえます。転送先の人数と応答できる時間、担当者不在時の扱いを同じにします。通知先とCRM項目、録音の有無も固定してください。

設定に必要な工数は別に記録します。デモの会話が良くても、対象用件を追加するたびに大きな開発が必要なら運用負荷が変わります。候補各社が行った設定と、自社で変更できる範囲を残してください。

会話と業務結果を別々に観察する

会話では、聞き取りと応答の間、言い直しへの対応を見ます。同じ質問を繰り返していないか、相手が話している途中で割り込まないかも確認してください。

Dialogflow CXの状態ハンドラー資料は、入力がない状態と意図が一致しない状態を別のイベントとして扱います。実装は製品ごとに異なりますが、無言と理解できない回答を同じ失敗へまとめない観察方法の参考になります。

業務結果では、取得した項目と終了状態を確認します。会話が自然でも、会社名の訂正前の値がCRMへ残れば業務は完了していません。担当者へ渡る記録を基準にします。

録音と文字起こし、要約は生成状態を分けてください。通話終了時点では処理中の場合があります。利用できるまでの時間と、生成に失敗した場合の表示や再処理を確認します。

時刻と状態を一件の記録に残す

受電では着信とAI応答、有人接続、通話終了の時刻を残します。発信では受付と架電要求を分けます。呼び出し開始と相手の応答、通話終了も別の時刻です。

TwilioのVoice Webhooks資料は、発信開始と呼び出し中を別の通話状態として扱います。応答と完了も分かれています。特定製品の共通仕様ではありませんが、「電話した」という一状態へまとめずに見る根拠になります。

業務状態には完了と有人対応を使います。再連絡と対象外、失敗も分けてください。必要に応じて日程確定や折り返し受付を追加します。状態名は候補間で同じ意味にしてください。

一件の試験IDへ時刻と状態をまとめます。録音や文字起こし、通知、CRMレコードも同じIDからたどれるようにします。画面をまたいでも一件の現在地が分かることが重要です。

例外は復旧した後まで実演する

連携失敗を見せてもらうだけでは足りません。CRMへの結果返却が失敗した後、データがどこに残るかを確認します。誰が気づき、どの操作で再送するかも見てください。

通知先が受け取れない場合は、再送と代替通知を試します。担当者不在なら折り返しへ切り替え、担当と期限を記録します。カレンダー登録が競合した場合は、別の候補日時へ戻れるかを見ます。

Amazon Connect Customerのテスト実行資料は、期待するイベントを観察できなければテストを失敗として扱います。テストが本番キューへ到達しないよう、専用キューへ置き換える考え方も示しています。

本番の担当者や顧客へ試験通話を流さないようにしてください。テスト用番号と通知先、カレンダー、CRMレコードを用意します。試験データを削除する担当と期限も決めます。

合否は期待値との一致で決める

評価表には、期待した結果と実際の結果、根拠を残します。「会話が自然だった」のような感想だけでは足りません。「訂正後の会社名が記録された」「担当者不在で折り返しへ移った」と書いてください。

Amazon Connect CustomerのCheck block資料は、実際の値を期待値と比較し、一致しなければ失敗として扱う方法を示しています。候補比較でも、期待値を先に書いてから実演結果を入れます。

足切り条件は点数より先に置きます。停止希望後も発信する、対象外の質問に断定して答える、連携失敗を検知できない場合などです。重大な条件を平均点で埋め合わせないようにします。

条件付きで合格した項目には前提を書きます。営業時間内だけ取次ぎ可能、特定プランならWebhookを使える、といった条件です。口頭回答は正式資料やデモの記録と分けてください。

設定変更後も同じシナリオを繰り返す

デモで一度通った会話が、設定変更後も同じ結果になるとは限りません。プロンプトやシナリオ、連携項目を変えた後に、三つの通話をもう一度実行してください。

Dialogflow CXのテストケース資料は、会話を期待値付きのテストケースとして保存し、更新後に再実行する方法を示しています。会話ごとの応答や遷移を以前の結果と比較できます。

自社の試験台帳にも、設定の版と実行日、実行者を残します。新しい用件を追加した場合は、その用件だけでなく既存の三通話も確認してください。以前の正常な経路が壊れていないことを見ます。

本番開始後は、苦情や誤分類、連携失敗から新しいテストケースを追加します。実際に起きた問題を匿名化し、再発しないことを設定変更前後で確認してください。

共通デモの結果を比較表へ移す

候補各社のデモが終わったら、三つの通話について終了状態と記録、例外からの復旧を並べます。音声の好みや管理画面の使いやすさは、その後に比較してください。

共通デモは製品の優劣を一つの点数で決めるものではありません。自社が任せたい一業務を、期待した状態で終えられる候補を絞るために使います。対象業務が違えば、別のシナリオを作ります。

受発信の方向や有人対応の範囲が異なる候補は、同じ表へ無理に入れません。まずAI電話サービス検索で同じ業務を担う候補に分け、その中で共通デモを実施してください。

デモの前提を作り切れない場合は、AI電話サービスの相談窓口で対象業務と完了条件を整理できます。候補へ連絡する前に、三つの台本と期待結果を一枚にまとめるところから始めてください。