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

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

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

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

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

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

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

同じ受付が再送される場合を想定します。TwilioのWebhook再試行に関する説明では、再試行を識別するヘッダーが案内されています。ただし、再試行の識別と業務上の重複発信防止は別です。受付IDと処理の種類を記録し、同じ受付を再送しても発信を増やさない仕組みを確認します。

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

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

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

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

Amazon Connect Customerのキャンペーン設定では、曜日・時間帯と例外日、受信者のタイムゾーンを設定できます。連絡上限も施策単位と全体で分けています。ただし全体の件数反映は即時とは限らないため、設定があるだけで同時発信を完全に防げるとは判断しません。

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

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

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

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

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

受付から呼び出しまでの記入例

架空の受付R-301で、受付が10時00分00秒、判定完了が02秒、発信要求が04秒、基盤が返した呼び出し開始が07秒だったとします。この場合、受付から基盤の呼び出し開始までは7秒、判定後の待ちは2秒です。4秒を「受付から着信まで」と表示すれば測定区間が違います。

基盤のイベント時刻だけでは、実端末で着信音が鳴った瞬間まで保証できません。デモでは試験端末の着信も照合し、取得できない時刻は測定不可と記載します。時計とタイムゾーンをそろえ、候補各社が同じ起点・終点で回答しているか確かめてください。

開始期限を仮に60秒とするなら、通常時だけでなく集中受付でも判定します。これは検討用の値で推奨値ではありません。30受付中24件が期限内、4件が遅延、2件が未開始なら期限内率は24÷30=80%です。未開始を除いた24÷28で報告しないよう、分母も指定します。

Amazon Connectのイベント起点キャンペーンにはイベントの有効期限があります。自社では期限切れを破棄、保留、人への引き継ぎのどれにするかを決めます。翌朝の受付処理を、その日の即時架電の成功へ混ぜないようにします。

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

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

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

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

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

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

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

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

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

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

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

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

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

Amazon Connect Customerの再試行設定では、番号ごとの再試行と相手ごとの連絡上限を別に扱います。自社の要件でも一つのフォームだけで回数を数えず、同じ相手への別施策を含めて確認します。システム外の手動発信まで自動集計されるとは限らないため、反映範囲を質問してください。

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

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

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

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

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

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

商談では、発信前の認証エラーと発信要求後の応答待ち時間切れを別に再現します。前者は設定を直してから発信可否を判定し直します。後者は電話がすでに開始している可能性があるため、先に要求IDから結果を照会します。何でも再実行する復旧手順は避けてください。

通話後のCRM障害では、R-301の通話結果を保存し、反映だけを再実行します。担当者が結果を訂正した後に古いAI要約が届く試験も加えます。受付IDだけでなく結果の版や確定者を使い、古い内容で上書きしない条件を決めます。

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

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

提供会社へ依頼する六つの実演

次は同じ試験受付を使い、機能説明を結果の証拠へ変えます。実際の顧客情報や電話番号は使わず、許可された試験先だけへ発信してください。

停止希望が記録されたのに再発信する場合は、開始速度の点数で補いません。該当する発信経路を止め、修正後に同じ試験を行います。記録と停止処理の設計はAIテレアポの停止リスト管理へまとめています。

見積もりにも通常時・集中受付時・翌営業日処理の同じ件数を使います。連携、発信、再試行、AI応対、転送の各費用を確認します。監視と障害復旧の担当、一次回答の目標、増枠に必要な日数を別欄へ記載してもらってください。対応可能という口頭回答だけの項目は未確認として残します。

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