チャットボットの有人対応とは、自動応答の途中から担当者による対応へ切り替えることです。引き継ぎは、接続する操作だけでなく、顧客が伝えた内容を次の担当者が理解する会話上の問題でもあります。研究では、引き継ぎ前後のやり取りと会話の進み方が検討されています。(引き継ぎに関する会話研究)
「担当者につながったのに、最初から説明し直した」という体験は、窓口を設けただけでは防げません。どの条件で切り替え、何を渡し、つながらないときにどう案内するかを決める必要があります。
本記事では、返金相談の架空例から切り替え条件と引き継ぎ票を提案します。営業時間外の経路と、解決・負担を評価する方法まで整理します。
自動応答と有人対応の役割
自動応答で案内する範囲と、人が判断する範囲を先に決めます。
営業時間や一般的な利用方法は、決まった情報を案内する対象として検討できます。一方、返金の承認、契約条件の個別判断、例外的な補償などは、担当者の権限と確認が必要な場合があります。AI(Artificial Intelligence:人工知能)が文章を作れることと、その判断を任せられることは別です。
役割を分ける際は、質問の難しさだけでなく、誤った回答の影響を見ます。回答が短い問題でも、金額や利用条件に関わるなら確認を厚くします。顧客自身が人との対応を希望した場合の経路も用意しましょう。
引き継ぎに関する会話研究は、自動応答が顧客の発言をどう受け取り、その後に担当者がどう応じるかを分析しています。これを踏まえ、切り替え前の履歴を保存するだけでなく、担当者が次の対応を判断できる要約を用意することを推奨します。
切り替えの条件を決める
人への経路を明示し、未解決を繰り返す前に切り替えます。
次の条件を出発点として検討します。回数や判断基準は、問い合わせ内容と対応体制に合わせて調整する設計案です。
| 条件 | 確認すること | 次の対応 |
|---|---|---|
| 顧客が人を希望します。 | 希望を伝えるボタンや言葉を認識できるか確認します。 | 接続または折り返しの経路を示します。 |
| 解決しない回答が続きます。 | 同じ案内の繰り返しや「解決していない」の回答を確認します。 | 履歴を添えて人へ引き継ぎます。 |
| 回答の根拠が不足します。 | 必要な規約や注文情報を確認できるか見ます。 | 確認できない範囲を伝え、担当者へ渡します。 |
| 判断権限が必要です。 | 返金承認などを自動応答で決めてよいか確認します。 | 権限のある担当者へ渡します。 |
顧客の不満を、感情を判定するAIだけで判断する方法は避けた方がよいでしょう。人を希望する操作や未解決の回答など、確認できる条件を先に使います。「強い言葉を使わないと人につながらない」という経路にしないことが重要です。
引き継ぐ情報をそろえる
履歴と要約を分け、確認済みの内容と未確認の内容を明示します。
担当者には、顧客の目的、対象の注文、すでに案内した内容、顧客が試した操作、未解決の点を渡します。AIが作った要約は、事実の確定ではありません。元の発言を確認できる履歴も残します。
注文番号などは、必要な範囲で安全な経路から取得します。会話欄でパスワードや決済情報を求める設計にしないでください。本人確認の状況を引き継ぐ際も、「確認済み」と「これから確認する」を分けます。
次の表は、架空の返金相談を想定した引き継ぎ票です。実際の個人情報を使わない説明用の例です。
| 項目 | 記入例 |
|---|---|
| 顧客の目的 | 二重に見える請求を確認し、必要なら返金を希望しています。 |
| 対象 | 注文番号は安全な確認画面で取得済みです。 |
| これまでの案内 | 一般的な請求の説明を案内しましたが、解決していません。 |
| 確認済みのこと | 顧客は利用明細に2件表示されていると伝えています。 |
| 未確認のこと | 二重決済か一時的な表示かは、決済記録で未確認です。 |
| 次に必要なこと | 担当者が決済記録を確認し、結果と手続きを説明します。 |
この票では「二重に見える」と「二重に決済された」を分けています。顧客の申告を確定した処理結果として要約すると、誤った承認や案内につながるおそれがあります。
返金相談の会話・分岐例
引き継ぎ後の最初の一言で、共有した情報が使われているかを確認できます。
次の架空の返金相談では、顧客は利用明細に同じ金額が2件表示されている理由を知りたいと考えています。一般的な案内では解決せず、人との対応を希望しています。
失敗する流れでは、ボットが「請求の説明はこちらです」と同じページを案内し続けます。接続後の担当者も「どのようなご相談ですか」と最初から聞き直します。顧客は、画面の内容と試したことを再び説明することになります。
改善案では、ボットが「利用明細に2件表示されている点を、担当者が確認します。これまでのやり取りを引き継ぎます」と伝えます。担当者は「2件表示されている点と、案内だけでは解決していない点を確認しました。決済記録を調べます」と対応を始めます。
この例の課題は、同じ説明の繰り返しと、確認前の断定です。担当者は共有情報を利用しながら、必要な本人確認や追加確認は省かないことが重要です。
営業時間外や接続失敗に対応する
その場でつながらない場合にも、顧客が次の対応を確認できる経路を用意します。
導入する製品では、営業時間の判定、問い合わせの受付、履歴の引き継ぎができるかを確認します。
時間外には、受付できたか、返答する時間の目安、連絡する経路を示します。翌営業日に対応する体制なら、その旨を案内します。守れない「すぐ対応します」という約束は置かないようにします。
接続に失敗した場合は、受付済みか不明なまま顧客を離脱させないことが重要です。受付番号を表示する、再送の要否を案内するなど、処理結果を確認できる方法を検討します。再接続した場合の重複受付も確認してください。
説明用の架空例として、平日9〜18時に担当者が対応する窓口を想定します。休日の扱いは別途案内し、次の分岐を試験します。製品の標準機能ではなく、設計例です。
| 状態 | 進める経路 | 顧客への案内例 |
|---|---|---|
| 営業中で接続できます。 | 履歴と引き継ぎ票を担当者へ渡します。 | 担当者に接続します。これまでの内容を共有します。 |
| 営業中ですが待機が必要です。 | 待つか、折り返しを依頼するかを選べるようにします。 | 現在お待ちいただいています。折り返し受付も選べます。 |
| 営業時間外です。 | 相談を受け付け、受付番号と次の営業開始時刻を表示します。 | 受付が完了しました。次の営業開始後に担当者が内容を確認します。 |
| 接続・受付の結果を確認できません。 | 完了したと断定せず、安全な問い合わせフォーム等の代替経路を示します。 | この画面では受付完了を確認できません。別の受付経路をご案内します。 |
接続失敗時には、処理記録を確認して重複受付を防ぐ仕組みも必要です。顧客への案内だけで、処理が確実に一度だけ行われるとは保証できません。
解決と対応負担を評価する
自動応答で終わった件数と、問題が解決した件数を分けて測ります。
ボットとの会話が終了しても、顧客が諦めただけの可能性があります。未解決・不明を解決に含めず、解決したかの回答や処理結果を確認します。複数回の会話が同じ相談に当たる場合は、案件をまとめる基準も決めます。
評価には、一定期間内の再問い合わせ、担当者につながるまでの待ち時間、説明の繰り返し、顧客の回答を使います。再問い合わせ率は、対象案件のうち同じ問題で再問い合わせがあった案件の割合と定義できます。観測期間と同じ問題の判定方法をそろえて比較します。
説明用の試算として、通販事業で月400件の引き継ぎを想定します。再説明の時間を1件3分短くできれば、月1,200分、20時間の対応余力が生まれます。時間単価を3,000円と置くと、6万円相当です。人員や支出を変えなければ、現金の費用が6万円減ることを意味しません。
空いた時間を、複雑な問い合わせや確認作業に使えるかまで検討します。有人対応への切り替え数を減らすこと自体を目標にすると、必要な顧客を人につなげない設計になりかねません。CES(Customer Effort Score:顧客努力指標)やVoC(Voice of Customer:顧客の声)も、負担の把握を補う方法です。
具体的な改善幅や費用への効果は、相談内容、担当者の体制、製品の機能によって変わります。架空の試算を導入効果の保証として扱わず、まず一つの問い合わせ種類で確認することを推奨します。
まとめ
チャットボットの有人対応は、切り替え条件・情報共有・接続できない場合の経路をまとめて設計します。
- ✓切り替え条件には、人の希望、未解決、根拠不足、判断権限を含めます。
- ✓引き継ぎ票では、顧客の申告と確認済みの結果を分けます。
- ✓時間外の経路には、受付結果と次の対応の目安を示します。
- ✓効果測定では、会話終了と問題解決、時間の余力と費用削減を区別します。
まず、よくある相談を一つ選び、自動応答から担当者の最初の一言までを確認してみてください。同じ説明を求める箇所と、確認前に断定している箇所を直すことから、引き継ぎの改善を始められます。


