AIコールセンターの有人転送を失敗させない設計

AIコールセンターの有人転送で最初に決めるのは、転送ボタンの有無ではありません。「いつ人へ切り替えるか」「人へ何を渡すか」「誰も応答できないときにどう終えるか」の三つです。この三つがつながって初めて、AIで解決できない問い合わせを人が引き継げます。

転送先へ発信できても、担当者が応答しなければ顧客の用件は解決していません。会話履歴が渡らなければ、顧客は同じ説明を繰り返します。人へ切り替える条件が広すぎれば、AIを導入してもキューの混雑は変わりません。

この記事では、AIコールセンターの候補を比較する前に、有人転送を一つの業務として設計します。製品ごとの設定手順ではなく、自社の要件と共通デモへ使える判断基準を作ります。

有人転送の完了条件を先に決める

有人転送の完了は、AIが転送処理を始めた時点ではありません。顧客の用件と、それまでに確認した内容を担当者が受け取り、対応を続けられる状態になった時点です。

Amazon Connectの公式ドキュメントでは、転送先として特定の担当者・キュー・外部電話番号が示されています。また、転送元の画面に接続済みと表示されても、転送先の担当者が通話を受け入れるまでは実際に接続されていない段階があると説明されています。

この違いを踏まえ、要件には「担当者へ転送できる」ではなく、次のように終了状態を書きます。

営業相談と判定したら営業キューへ転送し、担当者が通話を受け入れたことを確認してAIの対応を終了する。一定時間で応答がなければ折り返し希望を確認し、担当キューにタスクを残す。

この一文で、転送条件から接続確認と失敗時処理までがつながります。比較する製品が変わっても、同じ終了状態を実現できるか確認できます。

人へ切り替える条件を四つに分ける

転送条件は「AIが分からないとき」だけでは足りません。顧客の希望・業務上の判断・会話の状態・運用上の制約に分けると、設定とテストへ落とし込みやすくなります。

四つ目の条件は見落とされがちです。人へ切り替えるべき会話でも、応答できる担当者がいなければ、通話転送より折り返し受付の方が顧客を待たせません。

Amazon Connectのキューメトリクスを使ったルーティング例では、キュー内の問い合わせ数などに応じて転送先を分け、混雑時にはコールバックキューへ回す構成が案内されています。特定製品に限らず、比較時には「転送するか」だけでなく「いま転送してよいか」を判定できるか確認してください。

担当者へ渡す情報を最小単位で決める

顧客に同じ説明をさせないためには、通話そのものだけでなく、AIが確認した情報を担当者へ渡す必要があります。ただし、聞ける情報をすべて引き継ぐのではなく、次の応対に必要な範囲へ絞ります。

最低限そろえたいのは、用件と転送理由です。AIが確認した項目と未確認の項目、次に取るべき行動も渡します。本人確認を行う業務なら、確認済みか未完了かも明示します。録音や全文の文字起こしを担当者が開ける場合でも、通話開始時に読む短い要約は別に用意した方が実務で使えます。

たとえば、AIが「契約内容を変更したい」という用件を受けた場合、担当者へ渡すのは契約変更という分類だけではありません。「本人確認は未実施」「希望する変更日は確認済み」「例外条件の判断が必要」という状態まで渡します。担当者は、どこから会話を再開するか判断できます。

Amazon Connectの問い合わせ属性に関する公式説明では、顧客名などの情報を問い合わせごとの属性として保持し、フロー内で使えることが示されています。製品を比較するときは、会話要約の有無だけでなく、必要な項目を構造化して転送先の画面やCRMへ渡せるかを確認します。

個人情報を扱う場合は、引き継ぐ項目を業務上必要な範囲へ限定します。録音・文字起こし・要約の閲覧者と保存期間も、有人転送の設計と一緒に決めてください。

担当者が応答できない場合を先に作る

有人転送で障害になりやすいのは、正常に接続できた通話ではなく、担当者が応答しない場面です。呼び出し時間を延ばすだけでは、顧客の待ち時間が増えます。

転送先が応答しない場合は、通話をAIへ戻す方法があります。別のキューや留守番電話へつなぐか、折り返しを受け付ける方法もあります。どれを使うかは、用件の緊急度と担当体制で決めます。

一般的な問い合わせなら、一定時間で転送を止め、希望する連絡方法と時間帯を確認してタスクを作る方が扱いやすいでしょう。緊急性がある用件は、通常キューと同じ折り返し処理に入れず、当番先や専用窓口など別の経路が必要です。緊急対応をAIだけで判定してよいかも、自社の業務責任者と確認します。

折り返しへ切り替えた後は、担当者と対応期限を決めます。通知先とCRM上の状態も同じルールに含めます。顧客がもう一度電話した場合や、複数の担当者が同じタスクを受け取った場合の重複対応も防ぎます。

デモでは五つの失敗場面まで試す

製品デモでは、AIから人へ問題なく接続できる一件だけを見ないようにします。同じ条件を各社へ渡し、接続前後の状態まで確認します。

1. 顧客が明示的に人との会話を希望する
2. AIが意図を特定できず、聞き返し回数の上限に達する
3. 転送先の担当者が通話を受け入れる
4. 担当者が応答せず、折り返し受付へ切り替わる
5. 転送処理中に顧客が通話を終了する

それぞれについて、顧客への案内と担当者へ届く情報を見ます。CRMにどの状態が残るかも確認します。担当者が応答した場合は、AIが通話から抜ける前に顧客と担当者を同時につなげる方式か、すぐに引き渡す方式かも確認します。

Amazon Connectの転送操作に関する公式説明では、転送先へ接続した後に三者通話へ入り、転送元が退出する流れが案内されています。これは一つの実装例です。候補製品では、顧客の保留時間や転送先への事前説明を見ます。接続失敗時の復帰方法も同じシナリオで比べてください。

一枚の転送設計書にして比較表へ進む

有人転送は、会話の途中だけを切り取ると要件が抜けます。比較前に「転送条件」「転送先」「引き継ぐ情報」「接続確認」「不在時の処理」「記録と対応期限」を一枚へまとめます。

その設計書を使い、AIコールセンターの比較表で対応範囲と有人連携を確認してください。公開情報だけで判断できない項目は、同じ五つのデモシナリオを候補へ依頼します。

次の行動は、実際の問い合わせを一つ選び、正常に接続する場合と担当者が応答しない場合の二つの終了状態を書くことです。この二つが決まれば、転送機能の説明ではなく、自社の対応を最後まで完了できる製品かを比較できます。