AIコールセンターの有人転送と引き継ぎ設計

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

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

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

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

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

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

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

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

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

ただし、有人転送の完了は問い合わせの解決ではありません。担当者につながっても、返金の判断や契約変更が残っている場合があります。「転送開始」「担当者へ接続」「情報を受領」「用件を解決」を別々に記録すると、電話だけを渡して仕事が止まっている状態を見つけられます。

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

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

四つ目は転送を始める理由ではなく、実行できるかを判断する条件です。担当者に空きがあるだけで転送するのではありません。人へ切り替える必要があっても応答できる担当者がいなければ、通話転送より折り返し受付の方が顧客を待たせずに済む場合があります。

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

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

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

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

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

Amazon Connectのスクリーンポップでは、通話開始時の画面に問い合わせの情報を表示できます。画面を開けるだけでなく、実際に受ける担当者の権限で必要な内容を読めることが重要です。

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

引き継ぎメモは確認済みと未確認を分ける

AIの要約が読みやすくても、推測を事実として渡すと次の担当者が判断を誤ります。次の例では、架空の契約変更の問い合わせを使い、発言で確認した内容と担当者の判断が必要な内容を分けています。

「来月から変更できる」ではなく「来月から変更したいと発言」と残すのがポイントです。希望と確約を分け、聞けていない項目は空欄ではなく未確認とします。転送先が外部電話の場合も、このメモをどこで読むのかまで決めておきます。音声がつながることと、CRMの情報が見えることは別の要件です。

このメモを受けた担当者の最初の一言は、たとえば「来月からのプラン変更と費用のご相談ですね。契約内容をご案内する前に、本人確認をさせてください」です。「本日はどうされましたか」と用件を最初から聞く必要はありません。一方、本人確認は未実施なので省略できません。

電話番号の一致を本人確認済みにしない

顧客候補が一件見つかっても、話している人が契約者とは限りません。検索結果と本人確認の結果を別の欄にし、認証に使った秘密情報を短い要約へ複製しないようにします。

Amazon Connectの顧客プロファイルは電話番号などから候補を表示しますが、初期設定では本人確認後に担当者が問い合わせへ関連付けます。複数候補があれば選択が必要です。自動関連付けも設定できるため、製品名だけで安全性を判断せず、自社設定で「候補」と「確認済み」が混ざっていないか試します。

画面には現在の希望を優先し、直前の変更も分かるようにします。「来月から」を転送直前に「再来月から」へ訂正した場合、最新値と訂正時刻を残してください。Amazon Connectの属性には、通話の各区間へ共有される値と区間固有の値があります。共有値を更新するだけでは変更履歴の代わりにならないため、現在値と履歴を分けます。

表示用の変数へ全文を入れる方法にも注意が必要です。Genesys CloudのSet Screen Popでは、渡した値が参加者データとして表示・出力され、GDPR APIでは削除・更新されないため個人情報を入れないことが推奨されています。これは同機能の注意事項で、全製品に同じ制約があるという意味ではありません。画面表示だけでなく保存先と削除方法まで確認します。

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

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

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

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

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

接続できない理由ごとに終了状態を分ける

営業時間外と、呼び出した後の無応答は同じではありません。前者は転送を始める前に分岐でき、後者は接続を試した結果として記録します。以下は一般問い合わせを想定した編集部の設計例です。利用製品で実現できるかは個別に確認してください。

呼び出し上限は製品の初期値をそのまま採用せず、実際の待ち時間と担当体制で決めます。折り返し時刻も、担当者が守れる範囲だけを案内してください。通話終了後の発信は自動的に行うのではなく、顧客の希望と業務上の必要性に沿ったルールを用意します。

AIへ戻せない方式なら、同じ通話内で折り返し希望を聞き直せるとは限りません。転送前に代替案内を済ませるか、転送失敗時に案内できる仕組みを選ぶ必要があります。候補選定では、ここを「転送あり」の一語で済ませないことが重要です。

たとえば一般相談の呼び出し上限を試験用に30秒と決めた場合、無応答後にAIへ戻れる構成なら「担当者へ接続できませんでした。折り返しのご希望を承ってもよろしいですか」と案内します。了承後に連絡先と希望時間を確認し、担当キューへ一件の依頼を作ります。30秒は製品の標準値や推奨値ではなく、自社の待ち時間を評価するための仮設定です。

その依頼は「折り返し受付・担当未受領」として残し、通知の送信成功だけで閉じません。担当者が引き受けた時刻と対応期限を記録し、不在なら代替担当へ回します。通知を再送するときも元の受付IDを使い、同じ顧客へ二人から折り返さないようにしてください。

デモでは正常接続と四つの例外を試す

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

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

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

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

検証ではテスト用の電話番号を使い、提供会社と転送先担当者の間で実施時間を合わせます。顧客側の通話だけでなく、担当者の画面と処理履歴も確認してください。接続できても引き継ぎ情報が空だった場合は、今回の設計では完了としません。通話中の転送と、通知だけで後から人が対応する方式は分けて評価します。

画面と会話がつながる六つの試験

回線の試験が通ったら、受け手の画面を確認します。次の六つをテスト用データで流し、担当者が最初に何を尋ねたかまで記録してください。

仮に20件で転送を開始し、16件が担当者につながったとします。そのうち3件でメモが空なら、情報まで届いたのは13件です。回線接続率は16÷20＝80％、情報受領まで含めると13÷20＝65％になります。これは架空の例ですが、接続率だけでは画面連携の失敗を見落とすことが分かります。実運用では転送理由別に集計し、解決率はさらに別に確認します。

誤った顧客情報が表示されるなど重大な失敗があれば、平均値が良くてもその経路を本番へ出しません。運用責任者が該当する連携を止め、有人の通常受付へ切り替えます。修正後は同じ試験を再実行し、設定版と再開判断を残します。

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

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

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

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