AI即架電サービスの商談では、「何秒で電話できますか」と聞くだけでは比較できません。受付から呼び出し開始までのどこを測った数字か、混雑時や連携失敗時も同じかが分からないためです。

一つのフォーム受付を候補各社へ渡し、結果返却までを実演してもらいます。受付後の発信判定と呼び出し、会話も確認の対象です。正常に進む一件だけでなく、二重送信と担当者不在、停止希望も同じデモへ含めてください。

この記事では、公開情報を聞き直すのではなく、導入後の動きを判断できる質問に変えます。商談前の条件はAI即架電の要件定義で決める業務条件で一枚にまとめておくと比較しやすくなります。

一つの受付と五つの時刻を渡す

最初に、実際に使うフォームを一つ選びます。資料請求と求人応募を同時に扱わず、必要項目と会話の終わり方が一つに定まる用件にしてください。

サンプルには受付IDと受信時刻、電話番号を含めます。発信可否の判定に使う項目と、担当者へ渡したい情報も必要です。実在する顧客情報ではなく、テスト用の値を使います。

測る時刻は五つです。受付と判定完了、発信要求を分けます。その後の呼び出し開始と結果確定も記録してください。

「即時」の基準は、フォームを送った時刻から相手の端末で呼び出しが始まるまでと定義します。各社が別の時点を開始としている場合は、五つの時刻へ対応付けてもらってください。

質問は「最短何秒ですか」ではなく、「この受付で五つの時刻をログから示せますか」とします。表示値と実演結果を分けて記録すれば、開始速度の前提をそろえられます。

通常時と混雑時で開始速度を測る

一回だけの実演では、通常時の最短値しか分かりません。少量の通常時と、受付が重なる混雑時、営業時間外の三条件を用意します。各条件で呼び出し開始までの時間と、開始できなかった件数を確認してください。

Amazon Connect Customerのイベント起点キャンペーンは、外部イベントの条件から発信を始める仕組みを示しています。イベントには有効期限があり、キャンペーンで使う場合の上限も記載されています。製品ごとの実装は異なりますが、古くなった受付を無条件に発信しない考え方の参考になります。

商談では「開始期限を過ぎた受付はどうなりますか」と聞きます。遅れて自動発信するのか、保留して担当者へ通知するのかを実演してもらいます。夜間受付を翌朝へ送る場合は、即時架電の実績へ含めない集計が必要です。

混雑時の上限も確認します。契約上の受付数と同時発信数を分け、上限到達時の待機と破棄を見ます。増枠に必要な時間と費用は、口頭ではなく見積書へ反映してもらってください。

二重送信と受付欠損を再現する

フォームは、利用者の再送信や連携側の再試行によって同じ内容が二回来る場合があります。同じ受付IDを二回送信し、発信が一回だけ作られるか試してください。受付IDが異なり、電話番号と送信時刻が近い場合の重複判定も別に確認します。

StripeのWebhook公式資料は、イベントが再送されることと、配信順が保証されないことを説明しています。同じイベントを複数回受け取る場合に備え、処理済みIDを記録する方法も示しています。決済用の仕様を電話へ流用するのではなく、Webhookを使う連携では重複と順序を確認すべき根拠として使います。

次に、受付側では送信済みなのに即架電側へ届かない状態を試します。失敗した受付をどの画面で見つけ、誰へ通知するかを質問してください。自動再送と手動再送の条件も必要です。

再送後は、発信済みの一件まで再度電話しないことを確認します。「未受信」「受信済み・未発信」「発信済み・結果返却待ち」を分けて表示できれば、欠損の復旧と二重発信の防止を両立できます。

連携失敗後の分岐を実演する

即架電はフォームだけで完結しません。顧客情報を取得し、通話後にCRMへ結果を返すことがあります。商談では連携先を停止し、タイムアウトと認証エラーを再現してもらってください。

Dialogflow CXのWebhook資料は、名前解決と認証の失敗を分けて記録します。未到達とタイムアウトも別のエラーです。セッションIDや応答IDで関連ログを追う方法も示しています。候補製品には、同じ粒度で失敗理由と追跡IDを出せるか質問します。

発信前に必要な情報を取得できない場合は、推測で会話を始めないことを確認します。受付を保留し、担当者へ通知する分岐が必要です。通話中に連携が切れた場合は、相手へ何を案内してどの終了状態を残すかを見ます。

復旧後は同じ結果を再送します。CRMへ二重登録されないか、古い値を上書きしないかを確認してください。再送成功後に保留件数が減ることまで実演対象です。

会話完了と有人接続を分けて聞く

電話がつながった状態と、業務が完了した状態を分けます。資料請求なら本人確認と希望条件の取得後に、資料案内または担当者との接続が決まった状態を完了とします。

正常な回答に加え、曖昧な回答と対象外の質問を試してください。聞き直しの回数と、人へ渡す条件を確認します。AIが回答できないときに、もっともらしい案内で完了扱いにしないことが重要です。

有人接続では、担当者が応答できる場合と不在の場合を分けます。転送開始までの時間と、担当者へ渡る情報を見せてもらいます。不在時は相手へ折り返し予定を案内し、担当と期限が記録されるか確認してください。

「有人転送に対応していますか」ではなく、「担当者が出ない状態で受付はどの結果になりますか」と聞きます。通話終了後の通知だけを有人接続へ含めないよう、結果の定義も議事録へ残してください。

再試行と停止希望を同じ相手で試す

再試行は、未応答なら何回でも行う機能ではありません。話中と未応答、留守番電話、無効番号を別の結果として扱います。待ち時間と回数、発信可能な時間帯を回答してもらってください。

Amazon Connect Customerのアウトバウンドキャンペーン設定は、結果コードごとの再試行と、相手ごとの連絡上限を別に設定します。留守番電話への接続も一回の連絡として数える考え方が示されています。候補製品でも、再試行回数と相手単位の総連絡数を分けて確認します。

デモでは、一回目の通話中に停止希望を伝えます。通話結果に停止理由が残り、予約済みの再試行が取り消されるかを見てください。別キャンペーンや手動発信にも反映する範囲を質問します。

個人情報保護委員会のガイドライン通則編には、電話勧誘の停止意思が示された後も電話をかける事例が不適正利用の判断例として記載されています。個別の法的判断は自社で行う必要がありますが、停止希望を通話結果だけに残さず次回発信の判定へ反映する設計が必要です。

結果返却は不明状態まで確認する

通話後に返すのは録音URLだけではありません。受付IDと終了状態、発信回数、最終時刻を構造化して受け取ります。聞き取り結果と有人接続の成否、次の担当と期限も必要です。

商談では、通話は終わったもののCRM更新の結果が分からない状態を作ります。ここで通話を再実行せず、結果だけを再送できるか確認してください。「完了」と「失敗」の間に「反映確認待ち」を置けることが判断基準です。

担当者の画面では、未反映件数を一覧にします。エラー理由と最終試行時刻、次の処理が見えるかを確認してください。CSVで出力できても、復旧後の状態更新が手作業だけなら運用工数へ含めます。

結果を訂正した場合の履歴も見ます。元の値と修正者、修正時刻を確認できるか質問してください。AIの聞き取り結果を担当者が直した後、後続システムへどちらの値が送られるかも実演してもらいます。

回答を実演結果と見積もりへ残す

商談後は、質問ごとに口頭回答と実演結果を分けます。仕様書の参照箇所とログ、未確認事項も同じ行へ残してください。回答が条件付きなら、成立する件数と時間帯を記録します。

費用は通常時と混雑時、翌営業日処理を含む三条件で見積もります。受付連携と発信、AI応対、有人転送を分けてください。再試行と結果返却、監視、運用支援も同じ業務量で見積書へ入れます。

候補を絞る基準は、最短秒数ではありません。二重発信を防ぎ、開始できない受付を見つけ、停止希望を次回判定へ反映できることを先に確認します。その上で、自社の通常時と混雑時に開始期限を満たす候補を費用比較へ進めてください。

AI即架電サービス比較表へ実演結果を転記すると、候補間の差を同じ条件で確認できます。未確定の業務条件が残る場合は、相談窓口で質問票を整理できます。