AI即架電の再試行ルールを決める方法

AI即架電の再試行は、一律に「出るまで三回」と決めない方が良いです。話中や未応答、留守番電話、無効な番号では次に行う処理が異なります。最初に通話結果を分けます。その結果ごとに再試行の可否と待機時間、上限、停止条件を決めます。

フォーム送信直後の一回目は早さに意味があります。しかし、その後も短い間隔で電話を重ねると、利用者には別の連絡ではなく重複発信に見えます。即時性を守る処理と、再試行を抑える処理は分けて設計します。

再試行の前に重複発信を止める

同じ電話番号へ二つの処理が同時に走っている状態は、再試行ではありません。フォームの二重送信やWebhookの再送、CRM更新を起点にした別フローが重なることがあります。その場合、最初の通話が終わる前に次の発信が始まりかねません。

発信イベントを受け取ったら、電話番号だけでなく目的と受付IDを使って重複を判定します。同じ相手でも、資料請求と既存予約の変更は別の用件だからです。

発信前には、対象を次のいずれかの状態へ置きます。

同じイベントを再受信しても状態を戻さない仕組みにします。連携元が再送してよい設計でも、架電側では一度だけ処理するためのキーが必要です。

通話結果ごとに次の処理を変える

再試行するかどうかは、相手と会話できたかだけで決められません。通話結果を、次の処理へ結び付く粒度で保存します。

Amazon Connectのアウトバウンドキャンペーン設定では、話中と無効な番号を別の結果として扱います。未応答や留守番電話も区別されます。再試行する結果と待機時間も設定できます。同じ考え方を使い、AI即架電でも結果別のルールを作ります。

留守番電話にメッセージを残した後で再び電話する場合は、同じ用件で何度連絡するかを合算します。AWSの同ページでも、留守番電話で終わった発信を受信者への一回の連絡として数えています。

回数より先に再試行の期限を決める

「最大三回」だけでは、いつまで発信が続くのか分かりません。問い合わせの鮮度が意味を持つ時間と、利用者が連絡を予期できる期間を先に決めます。

たとえば当日中の確認が必要な見積依頼と、翌営業日でもよい資料請求では期限が異なります。期限を過ぎた発信は、回数が残っていても自動で終了し、担当者への通知やメールへ切り替えます。

その上で、結果別に最大回数と最小間隔を置きます。話中と未応答に同じ間隔を使う必要はありません。初回発信と再試行、担当者からの手動連絡を合わせます。相手単位の総連絡数で確認してください。

Amazon Connectのアウトバウンド運用の推奨事項では、再試行より初回発信を優先して処理する考え方が示されています。また、受信者ごとに一定期間内の最大連絡数を設定でき、上限判定は稼働中の複数キャンペーンを横断して行われます。AI即架電でも、一つのフォームだけで上限を数えず、同じ相手へ動いている別施策を含めた方が良いです。

発信できる時間帯と例外日を一つにする

再試行の予定時刻が営業時間外になった場合は、その時刻に発信せず、次の有効時間へ送ります。元の問い合わせ時刻から一定時間を足すだけでは、夜間や休日に発信されるおそれがあります。

発信可能時間は、曜日と開始時刻、終了時刻を一つの設定として管理します。祝日や臨時休業は通常の曜日設定を上書きする例外日にします。相手の地域が分かれる場合は、どのタイムゾーンで判定するかも決めます。

Amazon Connectのアウトバウンドキャンペーンには、曜日別の有効時間と連絡しない例外日を設定する仕組みがあります。標準または受信者の現地タイムゾーンも選べます。現地時間を特定できない受信者を配信対象から外す仕様も示されています。

時間外へ送った再試行は、翌営業日の開始時に集中させない工夫も必要です。予定時刻を分散するか、担当者の対応可能数に合わせて順に処理します。

停止条件をすべての発信経路へ反映する

再試行を止める条件は、通話がつながったときだけではありません。予約の確定や有人担当への接続でも終了します。相手からの折り返し、停止希望、誤番号の判明も停止条件です。

停止情報は再試行キューだけでなく、発信対象を作る元データへ戻します。キューから一件を消しても、CRM更新やフォーム再送で同じ相手が再登録されれば停止になりません。

特に、停止希望と誤番号は相手単位で保持します。用件だけを完了にすると、別キャンペーンから再び電話する場合があるためです。保存期間と解除できる担当者も決めておきます。

七つの経路で本番前に試す

設定画面を確認しただけでは、複数の連携が重なったときの動きまでは分かりません。本番前にテスト用番号を使い、次の順で結果と状態の変化を確認します。

1. フォームを一回送信し、一回だけ即時発信される
2. 同じ内容を短時間に再送しても発信が重ならない
3. 未応答後は予定時刻まで再発信されない
4. 再試行予定が時間外なら次の有効時間へ送られる
5. 留守番電話後の連絡数が上限へ加算される
6. 会話完了や有人接続後は再試行が消える
7. 停止希望が別の発信フローにも反映される

各テストでは、通話履歴だけでなくCRMの状態と再試行キューを照合します。Amazon Connectのアウトバウンドデータ定義でも、恒久的な失敗と送信時刻を設定できない状態を分けています。リソース起因の再試行も別の状態です。

システムエラー時は、相手の端末が実際に鳴ったかも確認します。発信要求の失敗と、通話開始後の記録失敗を分けるためです。

まず、現在の即架電フローで保存している通話結果を書き出してください。それぞれに「再試行する」「別経路へ渡す」「停止する」のどれかを割り当てます。その上でAI即架電サービス比較表を開きます。結果別の再試行や時間帯、停止、重複防止を設定できる候補か確認すると進めやすくなります。