AI即架電の会話品質は、声の自然さや通話時間だけでは判断できません。相手が発信理由を理解し、用件を訂正でき、担当接続や日程調整などの次の行動へ進めたかを確認します。

短い通話ほど、質問を減らすだけでは不十分です。フォームの入力内容を長く読み上げたり、AIが誤解したまま転送したりすると、通話は短くても業務は進みません。受付IDと通話IDを結び、会話のどこで状態が変わったかを追ってください。

会話の成功を次の状態で定義する

最初に、一回の通話がどこまで進めば成功かを決めます。問い合わせ後の架電なら、相手が電話の理由を理解し、用件と優先度を確認できた状態が出発点です。その後は対象業務に合う終了状態を一つ選びます。担当接続や折り返し受付、日程確定が候補です。

完了だけでなく、途中の状態も残します。用件を正しく理解して続行した通話と、聞き直した後に理解できた通話は分けてください。停止希望と別チャネルへの変更も区別します。誤った理解のままの終了と早すぎる有人転送も別の状態です。

Amazon Connect CustomerのAIエージェント指標には、目標達成率と応答完了率があります。有人引き継ぎ率と会話ターン数も別の指標です。ただし、有人転送が多いことだけでは良否を判断できません。必要な転送と、理解できずに逃がした転送を分ける必要があります。

各通話には、受付IDと会話設定の版、終了状態を残します。集計値から録音や文字起こしへ戻れるようにすると、同じ「転送済み」でも正しく絞り込めた通話と誤転送を見分けられます。

冒頭で発信理由が伝わるか試す

AI即架電では、相手がフォームを送信した直後に電話がかかります。冒頭では会社名だけでなく、何の受付を受けて電話したのかを伝えます。相手が電話を予期できても、用件が分からなければ会話を続ける理由がありません。

フォームの内容をすべて読み上げる必要はありません。「先ほどの見積もり依頼について確認のためお電話しました」のように、発信のきっかけと目的を一文で示します。入力項目の復唱は、本人が確認に必要な範囲へ絞ってください。

試験では、入力した本人だけでなく、同じ番号を共有する担当者も想定します。送信から時間が空いた場合や、複数のフォームを続けて送った場合も必要です。相手が「どの問い合わせですか」と聞いたときに、AIが推測せず説明を補えるかを確認します。

冒頭の合格条件は、決めた文を最後まで読み上げることではありません。相手が発信理由を言い換えられ、そのまま確認へ進めることです。説明中の離脱が増えた場合は、音声の自然さより先に文の長さと情報の順番を見直します。

一つの確認で用件を絞れるか見る

冒頭の次は、フォーム情報を前提に一つだけ確認します。資料請求なら検討対象、応募なら希望職種、見積もりなら優先条件が候補です。すでに入力された氏名や電話番号を最初から聞き直さないでください。

重要なのは、想定どおりの回答だけではありません。「別の製品について聞きたい」「入力を間違えた」のような訂正を試します。AIが最初の分類へ戻そうとせず、訂正後の用件を記録できれば、柔軟な会話が業務結果へつながっています。

Dialogflow CXの状態ハンドラーは、意図に一致しない入力と音声が認識されない入力を、no-matchとno-inputとして分けています。自社の検証でも、答えが想定外だったのか、聞き取れなかったのかを同じ失敗にしないでください。

nocall.aiの公式案内では、生成AIによる自由対話と日程調整が紹介されています。転送や会話履歴、文字起こしも案内されています。機能の有無を確認した後は、自社の質問で訂正を受け付け、正しい終了状態へ進めるかを同じシナリオで試します。

離脱した箇所を通話イベントで分ける

相手が通話を終えた事実だけでは、会話品質の問題か分かりません。冒頭説明中と最初の質問後を分けます。聞き直し中と担当接続の待機中も別の区間です。通話開始からの経過秒数だけでなく、直前のAI発話と会話状態を残してください。

Amazon Connect Customerのコンタクトイベントには、接続とキュー投入の時刻があります。担当者接続と切断も時刻で確認できます。会話側には冒頭終了と用件確定の時刻を置きます。転送要求の時刻も残すと、離脱した区間を比較できます。

切断理由だけで原因を断定しないことも重要です。Twilio Voice Insightsの公式FAQは、利用者が感じる通話切断がシステム上は正常に見える場合があり、機械的な判定が難しいと説明しています。録音とイベント、相手の反応を合わせて確認してください。

冒頭で離脱が集中するなら、発信理由と話す長さを見直します。聞き直し後なら、認識できなかった言葉と再質問を確認します。転送待ちなら、会話AIではなく担当者の受け入れ体制が原因かもしれません。

担当接続と代替処理まで評価する

有人転送は、AIが転送を要求した時点では成功ではありません。正しい条件で切り替え、担当者が応答し、相手が同じ説明を繰り返さずに会話を続けられた状態を成功にします。

確認するのは転送率ではなく、転送の適否です。複雑な質問をAIが抱え込んだ通話と、簡単な訂正ですぐ転送した通話を分けます。担当者には発信理由と確認済みの用件を渡します。訂正内容と未解決の質問も同じ画面で確認できるようにしてください。

担当者が出られない場合も試します。長く待たせた後に切断するのではなく、折り返し受付や日程調整へ切り替えます。相手への案内、担当者への通知、CRMの終了状態が同じ結果を示すことまで確認します。

転送後に通話時間が延びても、それだけで失敗ではありません。担当者が必要な相談を受け、次の行動が決まったなら業務は進んでいます。短縮すべきなのは、同じ説明の繰り返しと接続後の探し直しです。

六つのシナリオで変更前後を比べる

本番前は、都合のよい一通話だけで判断しません。次の六つを同じ入力条件と会話設定の版で実行します。

  1. 用件が明確で、一つの確認から担当接続または日程確定へ進む
  2. 用件が曖昧で、追加の一問によって正しい目的へ絞り込む
  3. 相手がフォーム入力を訂正し、訂正後の内容を記録する
  4. 相手が停止または別チャネルを希望し、発信対象から外れる
  5. 担当者が応答できず、折り返し受付や日程調整へ切り替わる
  6. 騒音や不明瞭な発話があり、聞き直した後に続行または安全に終了する

Dialogflow CXのテストケースは、会話ターンごとに一致した意図を比較できます。現在のページと追跡対象のセッション値も確認対象です。AIの返答文が変わっても、意図と終了状態が同じかを見る考え方は、生成AIを使う電話にも応用できます。

変更前と変更後では、一度に一つの設定だけを変えます。冒頭文を短くした試験で意図判定の条件まで変えると、離脱が減った理由を特定できません。六つの結果と途中状態を版ごとに残し、改善しなかった場合は元へ戻せるようにします。

最初の作業は、直近の問い合わせから十件を選ぶことです。フォーム入力と録音、文字起こし、担当接続の結果を受付IDでつなぎます。どの区間で会話が止まったかを分類し、最も多い一箇所を六つのシナリオで試してください。候補製品はAI即架電サービス比較表で同じ条件にそろえて確認できます。