AI即架電の運用設計と問い合わせ後の会話例

AI即架電は、フォーム送信などのイベントをきっかけに短時間で電話を発信する仕組みです。資料請求、見積依頼、求人応募も起点になります。速さだけを目標にすると、夜間の発信や重複架電が起きます。同意の不足と担当者不在も先に防ぐ必要があります。

最初の電話では、フォームにない情報を一つ確かめ、担当者への接続か折り返しを決めるところから始めます。見積依頼なら不足条件、セミナーなら連絡が必要な参加者だけを対象にします。入力済みの情報をすべて聞き直す電話にはしません。

発信の起点と待機時間を定義する

最初に、どのイベントを発信対象にするかを明確にします。資料ダウンロードと相談予約では、利用者が電話を期待する度合いが違います。見積依頼と採用応募も、確認すべき内容を分けます。

発信条件にはフォーム種別と対象商品を含めます。地域や入力内容に加え、既存顧客かどうかも必要です。重複、停止希望、営業時間は発信可否の条件にします。APIやWebhookを受け取ってから電話番号を検証し、除外判定を行い、実際に発信するまでの時間を計測します。

「最短数秒」という表示だけでなく、通常時と混雑時を分けて確認します。夜間・休日と連携失敗時の処理も必要です。即時に発信しない時間帯は、翌営業日の予約へ切り替えます。SMS・メールまたは担当者通知を使う条件も決めます。

ここでいう受付済みは、送信ボタンが押されたことではありません。サーバーに保存され、有効な受付として扱える状態です。同じ受付IDの再通知で二度発信しないようにし、電話番号が同じでも別の商品への新しい依頼は分けます。IDを付けるだけでは重複を防げないため、発信済みの状態と照合する処理も必要です。

同意と発信時の案内を業務ごとに確認する

フォームには、入力情報の利用目的と電話連絡を行うことが分かる説明を用意します。発信時は会社名と用件を案内します。AIによる応対であることや録音の有無は、自社の運用と法令に応じて決めます。

個人情報保護委員会のフォーム取得に関するFAQでは、本人が入力画面へ記入する場合は原則として利用目的の明示が必要とされています。問い合わせへの回答と、別サービスの勧誘は分けてください。電話番号が入力されているだけで、あらゆる営業電話を希望しているとは扱いません。

個人情報保護委員会の通話内容録音に関するFAQは、特定の個人を識別できる通話内容が個人情報に該当し、取得した場合は利用目的の通知・公表が必要になることを示しています。フォームの表示と電話内の案内が矛盾しないようにします。

消費者への販売を目的とする電話勧誘には、消費者庁の電話勧誘販売に関する案内で示される氏名等の明示、再勧誘の禁止などの規制があります。すべてのBtoB連絡や問い合わせ対応へ同じ規定が適用されるとは限らないため、対象業務と相手を区分し、必要に応じて法務担当者や専門家へ確認します。

AIが聞く範囲と有人接続を決める

即架電の会話は、最初の電話で何を完了するかを絞ります。本人確認と問い合わせ内容を起点に、次の業務に必要な最小項目を選びます。希望条件、検討時期、面談候補を一度に聞くとは限りません。

価格交渉と契約判断は、AIが推測して答えず人へ渡します。苦情や詳細な専門相談も同じです。有人接続は通話中の転送か担当者通知を選びます。日程調整と折り返しタスクを使う条件も決めます。

担当者が応答できない場合は、相手を待たせ続けません。折り返し時間の案内、予約、別担当への送付から代替処理を選びます。転送率だけでなく、転送後に会話が成立したかまで確認します。

資料請求後の会話は不足する一問から始める

例えば、フォームで製品名と相談内容を受け取っている場合は、次のように話します。以下は架空の台本で、実サービスの録音や成果事例ではありません。

「〇〇社のAI受付です。先ほどの製品Aの資料請求についてお電話しました。担当者へのご相談を希望されていますが、今お話ししてもよろしいでしょうか」

「今は無理」と返ったら、予算や決裁者の質問へ進まず、連絡可能な時間を尋ねます。「製品Bの相談だった」と訂正されたら、フォーム値を消さず通話での変更として保存します。依頼に心当たりがない相手には入力住所や予算を読み上げず、公式窓口から確認できる方法を案内します。

「分からない」「答えたくない」「聞き取れない」を同じ空欄へまとめないことが重要です。聞き返しても解決しなければ、未確認のまま人へ渡すか別の連絡手段へ切り替えます。聞き取りの回数は自社の試験で決め、無限に質問を繰り返さないようにします。

見積依頼では価格を答えず算定条件をそろえる

見積フォームに商品と数量があり、希望時期だけが足りないなら、「お見積もりの確認です。ご希望の利用開始時期はお決まりでしょうか」と尋ねます。回答が「まだ未定」なら、そのまま担当者へ渡します。予算を答えないことだけで依頼を断る設計にはしません。

数値の訂正は原文と訂正後の値を組で残します。例えばフォームの20台に対して「まず10台、来月さらに10台」と返った場合、数量10台へ単純に上書きすると後半の依頼が落ちます。「初回10台・追加10台希望、納期は未確約」として担当者が確かめられる状態にしてください。

「合計はいくらですか」「来週必ず届きますか」には、確認済みの範囲を超えて回答しません。受付を完了したことと見積書を提示したことは別です。対象地域や最低数量に合わない可能性があっても、例外を判断する権限がなければ対象外候補として人へ渡します。

セミナーでは申込者と参加者を分ける

一人が二人分を申し込んでも、申込者の電話番号を二人分の発信先へコピーしません。セミナーID・申込ID・参加者IDを分け、電話が必要な参加者の連絡先を確かめます。承認待ちの人へ参加確定と案内しないようにします。

発話は「〇〇社のAI受付です。お申し込みの△△セミナーについて、参加方法のご案内で確認が必要な点はありますか」のように目的を限定します。メールで案内が完了している人へ、電話すること自体を目的に連絡しません。参加が未定という回答は欠席へ変えず、担当者への質問と参加状態も別に残します。

日程が変わった場合は、発信時点の正式な開催情報を参照します。参加URLや入場コードを長く読み上げず、確認済みの案内先へ送って送信結果を残します。案内を送れたことと、相手のカレンダーへ登録されたことを混同しないようにします。

再試行と停止条件を先に設定する

不在時の再試行は、回数を増やせばよいわけではありません。回数と間隔を決めます。時間帯に加え、留守番電話と別番号の扱いも必要です。応答後の再発信は不在時と分けます。

• 不在・話中は、許容する回数と間隔で再試行する
• 明確な拒否や停止希望は、その場で対象から除外する
• 番号違い、対象外、既存対応中は再発信しない
• 担当者接続後や予約完了後は、重複発信を止める
• システム障害時は自動再送の上限と確認担当を決める

停止希望は会話ログに残すだけでなく、次回の発信対象から確実に除外できる経路が必要です。複数システムや複数サービスを使う場合は、停止情報の正本と反映時間を決めます。

再発信の可否は、予約を作った時点と実際に発信する直前の二度確認します。その間に営業担当が手動で電話したり、相手が停止を希望したりするためです。手動連絡と留守番電話への伝言も接触履歴へ含め、AIの回数だけを上限管理しません。

見積回答の期限が近いからといって、許可時間外へ発信しないでください。期限までに連絡できなければ、担当者確認や案内済みの別チャネルへ切り替えます。架電要求がタイムアウトして成否不明の場合も、結果照会か人の確認を先に行い、別IDで新しい電話を追加しません。

CRMへ戻す結果と失敗時の処理を決める

通話後は、発信日時と応答結果をCRMへ返します。回答内容、担当接続、予約も記録します。停止希望と次の担当者に加え、対応期限も業務システムへ渡します。録音や全文文字起こしをすべて連携するのではなく、次の担当者が必要とする情報を選びます。

API・Webhookでは認証と再送を確認します。重複登録と項目欠落に加え、連携先停止時の保留も試します。画面上では成功に見えてもCRMへ結果が届かない場合があるため、通話IDなどで照合できるようにします。

例えば受付Q-104の通話で「製品AではなくB、今は話せない、翌営業日の午後を希望」と訂正されたとします。フォームの製品Aは出所付きで保持し、最新の相談はB、終了状態は折り返し待ちとします。担当者と対応期限が決まって初めて、引き継ぎタスクを作れます。実在顧客ではなく記録の例です。

通知送信に失敗したときは、そのタスクと通知だけを復旧します。CRMの再送を新たな発信イベントとして処理しないでください。不要な全文や個人情報まで共有せず、担当者に必要な訂正内容と未確認事項へ絞ります。

会話品質は離脱した場所と完了点で見る

電話が短かったことだけでは、よい会話とは判断できません。冒頭説明中の離脱、質問への回答、聞き返し、転送待ちを分け、どこで次の行動へ進めなかったかを調べます。録音を確認できる権限と保存期間も先に決めておきます。

Amazon Connectのコンタクトイベントでは、キューへの投入と担当者への接続を別のイベントで扱います。自社のシステムでも、転送要求と接続完了を同じ成功件数にしないようにします。必要な有人転送は失敗ではなく、正しい窓口へつながったかが判断点です。

例えば20件の架空の試験で、担当接続10件、正しく折り返し受付4件、停止希望3件、冒頭離脱2件、誤分類1件だったとします。業務上の次の行動へ進んだのは14件で、停止を守った3件も安全上は正しい処理です。17件すべてを商談化と数えたり、離脱の2件を音声品質だけの問題と決めたりしません。

冒頭離脱が多ければ、発信理由と文章の長さから見直します。転送待ちの離脱なら担当者の受け入れ体制が候補です。最初は一つの設定だけを変え、同じ試験入力で訂正後の値と終了状態を比べます。声が自然になっても誤分類が残るなら改善完了ではありません。

本番前に一連の流れを検証する

本番前は、フォーム入力から発信までを通しで試します。会話から担当接続へ進み、CRM記録と停止反映まで確認します。

正常な問い合わせに加え、夜間と重複を試します。番号誤りと担当者不在も対象です。停止希望と連携失敗まで確認してください。

試験には管理下の電話と架空の情報を使います。質問を減らすなら、その情報がなくても同じ担当者と終了状態を選べるか確認してください。最初に一つのフォームを選び、受付から引き継ぎまでの記録がつながる状態を作るのが出発点です。

候補の機能はAI即架電サービス比較表で横並びにできます。比較時は開始速度だけでなく、発信可否の判定と再試行を見ます。有人接続、記録、停止処理を継続運用できるかも確認してください。