AI即架電の要件定義で決める業務条件

AI即架電の要件定義では、「フォーム送信後すぐに電話する」だけでは足りません。どの受付を発信対象とし、何をもって開始と数えるかを決めます。相手が応答しない場合と担当者が出られない場合も、一件の受付が終わるまでつなげてください。

比較の単位は発信機能ではなく、受付から結果返却までの業務です。受付IDを軸にします。発信前と通話中、通話後の終了状態を一枚にしてください。各社へ同じ一枚を渡せば、速さの表示だけに頼らず比較できます。

この記事では、個別機能の設定方法ではなく、候補を足切りできる受け入れ条件を作ります。同意文と再試行、連携の詳細は関連記事へ分けます。ここでは境界が切れない要件定義票を完成させます。

一つの受付イベントを対象にする

最初の対象は「すべての問い合わせ」ではなく、一つのフォームと一つの用件にします。資料請求と見積もり、応募では必要な入力項目が異なるためです。会話の終了状態も同じではありません。

受付時に残す項目を決めます。まず受付IDと受信時刻、電話番号が必要です。用件と連絡可否の判断に使う情報も残します。流入元と同意文の版も残せると、発信理由を後から確認できます。

同じ受付が再送される場合を想定します。TwilioのWebhook再試行に関する説明では、再試行を識別するための冪等性トークンが案内されています。これはTwilio固有の仕組みですが、同じイベントを二回受けても新しい発信依頼にしない考え方は共通します。

受付連携の作り方はフォーム送信からAI即架電を始める連携設計で詳しく扱います。要件定義票には、どの項目が欠けたら発信対象外になるかまで書いてください。

発信可否を開始速度より先に決める

フォームを受けたら、すべて即座に発信するわけではありません。電話連絡の案内と受付時間を確認します。電話番号の形式と重複、停止希望も発信前に判定してください。

状態を「対象」「保留」「対象外」に分けます。対象は自動発信へ進みます。保留は確認担当へ渡し、対象外は理由を記録して終えます。条件が不明なまま発信する設計にしないことが重要です。

Amazon Connect Customerのキャンペーン設定では、連絡可能な曜日と時間帯を設定できます。例外日と受信者のタイムゾーンも対象です。同じ相手への連絡上限もキャンペーン単位と全体で分けています。要件では製品の設定名を写さず、自社が発信してよい条件として書き直します。

案内と同意の整理にはAI即架電を始める前に整える案内と同意を使います。要件定義票では、判定に使った情報と判定結果を受付IDへ残せることを受け入れ条件にします。

開始までの時間を区間に分ける

「一秒で架電」のような表示だけでは、自社の開始時間を判断できません。受付時刻から着信音が鳴るまでには、まず受付処理と発信可否の判定があります。その後に発信キュー、電話基盤への要求、呼び出し開始が続きます。

まず、何を開始と呼ぶか決めます。電話基盤へ要求した時点と、相手の端末で呼び出しが始まった時点は同じではありません。要件定義票には次の時刻を分けて置きます。

通常時の目標だけでなく、混雑時の上限も必要です。夜間受付を翌営業日に送る場合は、即時性の対象外です。指定時刻までに開始できなかった受付を、遅れて発信するのか担当者へ渡すのかも決めます。

会話の完了と対象外回答を決める

電話がつながっただけでは業務完了になりません。本人または用件を確認し、必要な情報を聞き取り、次の行動が決まった状態を完了とします。

見積もり依頼なら、希望条件を聞いて担当者との接続または折り返し予定を確定するところまでが候補です。複雑な質問と対象外地域、本人確認の不一致は別の終了状態へ送ります。AIが推測して答えないようにしてください。

会話範囲は質問数ではなく、終了状態から逆算します。「必要事項を聞く」ではなく、必須項目がそろった場合と途中で拒否された場合を分けてください。留守番電話や別人応答も会話完了に含めません。

要件定義票には正常完了と有人接続、折り返し受付を置きます。対象外と未応答、停止希望も必要です。製品ごとの結果名が違っても、この終了状態へ対応付けられることを確認します。

有人接続を担当者不在まで定義する

有人接続は、転送ボタンがあるかだけで判断しません。AIが確認した内容を担当者へ渡し、相手を待たせたまま会話を続けられることが受け入れ条件です。

担当者が応答できる上限を先に置きます。即架電が集中すると、電話はつながっても転送先が埋まる場合があります。担当者が出られないときは、折り返し時刻を案内するのか、予約へ切り替えるのかを決めます。

Amazon Connect Customerのアウトバウンド運用ガイドでは、担当者の配置と接続遅延を分けて説明しています。応答後の無音時間を減らす設計も示されています。即架電でも、発信速度と担当者への接続速度は別の要件として測ります。

受け入れテストでは、担当者が応答できる場合だけでなく、不在と混雑を試します。相手への案内、担当者への通知、受付状態の更新が同じ結果にならないことを確認してください。

再試行と停止を受付単位でつなげる

未応答の後に再試行する場合は、最初の受付と同じ業務として追います。新しい発信依頼を作ると、上限と停止希望を正しく判定できません。

通話結果ごとに次の処理を決めます。話中と未応答は再試行候補です。無効番号、停止希望、正常完了は停止します。担当者が手動で連絡を始めた場合も、自動再試行を止める必要があります。

Amazon Connect Customerのキャンペーン設定では、番号ごとの再試行回数と相手ごとの連絡上限を別に扱います。AI即架電でも、一つのフォームだけで回数を数えません。同じ電話番号へ動いている別の施策を含めて上限を判定します。

結果別のルールはAI即架電の再試行ルールを決める方法で作れます。要件定義票には、再試行予定と停止理由を受付IDから確認できることを書きます。

結果返却と不明状態を設計する

通話後は、CRMへ結果を書き戻して終わりではありません。どの受付に対する結果かを照合し、後続担当が次の行動を判断できる状態にします。

返却する項目は終了状態と発信回数、最終時刻です。聞き取り結果と有人接続の成否も必要です。録音や文字起こしのURLだけでは、一覧から未処理を見つけられません。折り返し期限と担当も構造化して残します。

電話は終了したがCRM更新の結果が分からない場合があります。このとき通話を再実行すると、相手へ重複発信するおそれがあります。「通話済み・反映確認待ち」という不明状態を置き、再送する処理と再発信を分けてください。

発信要求にも同じ考え方が必要です。Amazon Connectの発信開始コマンドは、同じ要求を識別するクライアントトークンを受け取ります。要件では特定APIの採用を決めず、結果不明時に二重発信を防げることを求めます。

受け入れ条件を一枚にまとめる

最後に、受付から結果返却までを一枚へ並べます。各項目へ「必須」「選択」「将来」の優先度を付けます。必須条件を満たさない候補は、開始速度や会話機能の多さで救済しません。

最初の作業は、直近のフォーム受付を十件選ぶことです。受付IDから通話結果とCRM反映まで追い、途中で状態が分からなくなる箇所へ印を付けてください。その十件を正常と例外、失敗へ分けます。AI即架電サービス比較表の候補へ同じ受け入れ条件を渡してください。