コールセンターにAIを導入するときは、「何を答えさせるか」と「どの条件で人へ戻すか」を一緒に決めることをおすすめします。まず、応対後の記録作成、担当者への回答支援、顧客への自動応答に分け、顧客に届く前に誰が確認するのかを整理しましょう。
この記事では、公式資料で確認できる機能例を示したうえで、業務を任せる範囲と有人対応へ切り替える条件を提案します。判断表や試行手順は、各社が自社の運用を決めるための案です。
AIの役割を記録・担当者支援・自動応答に分ける
導入を検討する際は、次の三つに分けると確認責任を決めやすくなります。
- 記録の支援：応対後に会話の要点を整理し、担当者が確認して記録する。
- 担当者の支援：社内手順から回答候補を用意し、担当者が採用するか決める。
- 顧客への自動応答：対象を絞った問い合わせに、AIが直接案内する。
製品機能の例として、Amazon Connectの公式資料には、顧客との会話を生成AIで要約し、応対後作業に利用する機能が記載されています。ただし、すべての応対で必ず要約が生成されるわけではありません。AWS公式資料：応対後の要約
導入初期の案としては、担当者が原文と照合できる記録支援から試し、次に回答候補の提示、自動応答へと対象を広げます。要約が出ない場合の手入力経路も残します。自動応答から始める場合も、有人対応の受け皿まで試行範囲に含めましょう。
業務別に決めるAIの支援範囲
次の表は製品の対応機能一覧ではなく、業務設計のたたき台です。候補製品で実現できるかは、デモや試行で個別に確かめてください。
| 対象業務 | AIに任せる範囲の案 | 人が確認・判断する点 | 人へ戻す条件の案 |
|---|---|---|---|
| 営業時間・利用手順の案内 | 承認済みの情報に沿った案内 | 情報の更新日、対象商品や窓口 | 参照情報がない、資料間で内容が異なる |
| 問い合わせの振り分け | 用件の聞き取りと転送先候補の選択 | 複数の用件、担当不明の相談 | 用件を特定できない、有人希望がある |
| オペレーターへの回答支援 | 根拠資料と回答候補の提示 | 顧客の状況への適用、実際に伝える表現 | 根拠を確認できない、例外対応が必要 |
| 応対記録の作成 | 要点・依頼事項の下書き | 金額、期日、約束、未解決事項 | 原文との食い違い、要約の未生成 |
| 契約変更・返金などの受付 | 必要事項の整理と手続き案内 | 本人確認、実行権限、承認 | 確認が終わらない、承認範囲を超える |
特に手続きの案内と、契約・金額などの変更実行は別の許可として扱う設計を提案します。「返金の流れを説明できる」ことを、そのまま「返金を確定してよい」という権限に結び付けないようにします。
人へ引き継ぐ条件を会話開始前に決める
有人対応への引き継ぎは、実際に製品で用意されている仕組みの一つです。Google CloudのDialogflow CXの資料では、仮想エージェントから人へ会話を引き継ぐ処理が説明され、電話での利用には電話連携の設定が必要とされています。Google Cloud公式資料：Dialogflow CX handoff
導入時は、この仕組みの有無に加えて「何を検知したら切り替えるか」を運用責任者が決めます。以下を条件の候補にしてください。
顧客が有人対応を希望したとき
「担当者と話したい」という希望が出たら、有人窓口への切り替えを案内する運用にします。理由を何度も尋ねて自動応答を続ける設計は避けましょう。
担当者不在時の扱いも必要です。折り返し受付や営業時間の案内など、実際に提供できる経路を決め、対応できない時間の即時接続を約束しないようにします。
用件が分からない・入力を受け取れないとき
Dialogflow CXには、入力が意図に合わない場合と、入力が届かない場合などを扱う別々のイベントがあります。Google Cloud公式資料：State handlers
運用でも、この二つを分けることを提案します。用件が不明なら選択肢を示し、音声を受け取れないなら入力方法を案内します。再質問の上限を事前に設定し、改善しなければ人へ戻します。上限回数は一律に決めず、自社の試行で顧客の負担と用件の把握状況を確認してください。
根拠・権限・処理結果を確認できないとき
回答に使える資料が見つからない、資料の記述が矛盾する、担当者の承認が必要といった場合を、停止条件にします。顧客の発言から都合のよい条件を推測して手続きを進めない運用です。
また、連携先の応答が途絶えた場合は、処理済みかどうかを確認する担当者へ回します。たとえば変更依頼の途中でエラーになったときは、完了の案内や同じ処理の再実行をする前に、受付状態を照合する手順を用意します。
引き継ぎでは「要約」と「未確認」を分けて渡す
人へつなぐ際には、次の項目を引き継ぎ票に持たせる案が考えられます。
- 顧客が求めていることと、現在の未解決事項
- AIがすでに案内した内容と参照資料
- 本人確認の実施状態と、確認済みの範囲
- 実行した処理、処理結果、結果が不明な操作
- 人へ切り替えた理由と、元の会話を確認する参照先
「顧客が返金を希望」と「返金が承認済み」は別の状態です。要約には希望・確認済みの事実・未確認事項を分けて表示し、人が元の記録に戻れるようにしましょう。
入力する顧客情報の範囲、記録を閲覧できる担当者、保存期間、外部サービスでのデータの扱いも試行前の確認項目に含めます。社内で用途・入力・確認責任を整理する際は、生成AIの社内利用ルールの作り方も参考にしてください。
小さく試して、引き継ぎ後まで評価する
最初の試行では、対象の問い合わせと承認済み資料を限定します。通常の案内だけでなく、有人希望、用件不明、担当者不在、資料不足、処理結果不明のケースを含む確認用シナリオを作りましょう。
評価項目としては、次のように定義して記録することを提案します。
| 評価項目 | 確認する内容 |
|---|---|
| 回答の根拠 | 承認済み資料と一致し、対象条件も合っているか |
| 引き継ぎの成功 | 条件に該当した会話が、決めた窓口や受付経路へ届いたか |
| 記録の品質 | 金額・期日・約束・未解決事項に修正が必要だったか |
| 対応完了の確認 | 終了した会話のうち、解決を確認できたものはどれか |
| 再問い合わせ | 決めた期間内に、同じ用件で再び問い合わせがあったか |
| 全体の作業時間 | 応対、記録確認、引き継ぎ後の再確認にどれだけかかったか |
切断や離脱を解決と数えないように、完了の判定方法もそろえます。効果を比べる場合は、対象業務・集計期間・件数を添え、単にAIが応答した件数だけで評価を終えないようにしましょう。
導入範囲を広げる判断には、責任者が定めた合格条件を使います。権限のない処理や誤った完了案内が見つかった場合は、その業務の自動応答・実行を止め、条件を修正して再確認する運用を提案します。
コールセンターのAI活用は、支援する業務、確認する人、切り替える条件、引き継ぐ情報を一組で設計しましょう。自社の問い合わせを判断表に当てはめれば、試行する対象と、先に整えるべき有人対応の経路を具体化できます。