コールセンターのチャットボット導入｜FAQ・時間外受付・有人引継ぎ

朝の受付開始と同時に、営業時間、申込方法、必要書類を尋ねる電話が続きます。その合間には、契約ごとの確認や強い不満を伴う相談も入ります。電話中心のコールセンターでチャットボット導入を検討する際、すべての問い合わせを一度にチャットへ移すと、誤案内や受付漏れが起きた箇所を切り分けにくくなります。

進めやすい順序は、根拠が明確なFAQの自動応答、営業時間外の仮受付、条件を決めた有人引継ぎです。回答、受付、引継ぎでは、利用者に約束する内容と社内の責任がそれぞれ異なります。前の段階が安定してから次へ進めれば、電話窓口を残したまま対象範囲を調整できます。

この記事では、電話の問い合わせ理由を棚卸しし、三段階それぞれの開始条件、公開後に確認する記録、次へ進む条件、問題が起きた場合の差戻し方法を整理します。電話件数の削減だけを目的にせず、利用者が必要な案内や担当者へ到達できたかを判断軸にします。

コールセンターへのチャットボット導入は3段階に分ける

三段階に分ける理由は、難しい機能を後回しにするためだけではありません。FAQ自動応答では「根拠どおりに答えたか」、時間外受付では「受け付けた案件を翌営業日以降も追跡できるか」、有人引継ぎでは「担当者へ必要な情報が渡り、対応を開始できたか」を確認します。各段階で成功基準が異なるため、公開範囲も分けて管理します。

1. 第1段階・FAQ自動応答：営業時間、窓口、公開済みの手続きなど、正しい回答を事前に確認できる質問へ案内する。
2. 第2段階・営業時間外受付：その場で回答できない相談を仮受付し、確認時期と次の連絡方法を伝える。
3. 第3段階・有人引継ぎ：個別判断、苦情、例外処理などを、決めた条件と情報で担当者へ渡す。

たとえば、住所変更の手続きページはFAQで案内できても、利用者ごとの変更処理まで完了したとは言えません。営業時間外なら、「依頼を受け付けた状態」と「変更が完了した状態」を明確に分けます。本人確認や契約情報の照会が必要な場面は、担当者へ引き継ぎます。この境界を曖昧にしたまま三段階を同時に公開すると、利用者にも担当者にも現在の処理状態が伝わりません。

最初から広い範囲を任せず、一つの窓口または一つの問い合わせ分類から始めます。各段階で、誤った案内の訂正、未処理案件の発見、担当者への連絡が実際に機能することを確かめます。そのうえで次へ進めば、運用上の問題を小さい範囲で修正できます。

導入前に電話のコールリーズンと回答根拠を棚卸しする

導入対象は、電話件数が多い順だけで決めません。まず電話記録、応対メモ、メール、フォームの内容を確認し、利用者が連絡した理由である「コールリーズン」を四つに分けます。

各項目には、件数だけでなく、回答の正本、更新頻度、誤案内した場合の影響、本人確認の要否、現在の担当部署を記録します。「以前からこの回答を使っている」という事実だけでは、根拠を確認したことになりません。公式ページ、規約、業務手順書など、参照する資料と適用条件を明記します。

頻度が高い質問なら自動化に向くとは限りません。問い合わせが多くても、契約内容によって結論が変わる質問や、情報の更新が頻繁なのに更新担当者が決まっていない質問は、初期対象から外します。反対に、件数が中程度でも、回答が簡潔で、根拠と更新者が明確な質問は試しやすい候補です。

棚卸し表には、「チャットが回答しない条件」も加えます。具体的には、本人確認が必要な場合、最新状況の照会が必要な場合、判断に必要な条件が不足している場合、公開情報に根拠がない場合です。対象外と判断した後の案内先も記録しておけば、回答を止めるだけでなく、電話、フォーム、有人窓口へつなげられます。FAQの準備方法を詳しく確認したい場合は、FAQチャットボットの導入手順も参照してください。

第1段階は根拠が明確なFAQの自動応答から始める

最初に公開するFAQは、営業時間、受付窓口、申込の流れ、公開済みの必要書類などから選びます。回答の正本があり、内容が変わったときに誰が修正するか決まっていることが開始条件です。文章を登録できた時点では公開しません。質問の言い換えや条件違いを試し、回答してよい範囲と回答しない範囲を確認できた状態を公開条件とします。

配送に関する窓口なら、「配送状況はどこで確認できますか」には公開された確認方法を案内できます。一方、「私の注文は今日届きますか」には、注文情報や配送状況の個別照会が必要です。同じ「配送」という分類でも、一般案内と個別回答を分けます。個別照会が必要な質問は、所定の確認ページまたは有人窓口へつなぎます。

公開前は、次の質問を一組として試します。

• FAQに記載した標準的な質問
• 利用者が使いそうな言い換えや略称
• 対象者、曜日、契約などの条件を加えた質問
• 意味が複数に取れる短い質問
• 登録情報に答えがない質問
• すでに終了した制度や古い条件を尋ねる質問

期待する回答、実際の回答、参照根拠、合否、修正担当者を記録します。この記録があれば、正本や回答を更新した後に同じ組み合わせで再試験できます。正しい質問だけを入力して動作を見るのではなく、答えてはいけない質問では回答を止め、適切な窓口を案内できるかも確かめます。

公開後は、無回答、同じ質問の繰り返し、回答直後に電話窓口を選んだ会話、訂正が必要な回答を確認します。チャットと電話の利用者を個人単位で結び付けられるとは限りません。そのため電話側でも、「チャットを見たが解決しなかった」「チャットの案内と電話回答が違った」といった連絡理由を記録し、再入電の兆候を確認します。

重大な誤案内が見つかった場合や、正本が更新されたのに反映担当者が対応できない場合、対象外の質問へ回答を続ける場合は、FAQを追加して様子を見るだけでは不十分です。該当範囲を停止するか有人案内へ戻し、正本と類似回答への影響を確認します。その後、関連する質問も含めて再試験します。訂正から再公開までの流れが実際に機能することが、第2段階へ進む条件です。

第2段階は営業時間外の「回答」と「受付」を分ける

FAQが安定したら、営業時間外の相談を受け付ける範囲を検討します。ただし、画面が24時間開いていることと、個別相談への回答が24時間いつでも完了することは同じではありません。定型FAQはその場で案内し、担当者の確認が必要な相談は「仮受付」として扱います。

仮受付では、受付が完了したこと、担当者が内容を確認する時期、今後の連絡方法、緊急時の別窓口を表示します。「翌営業日に回答します」と一律に約束できない体制なら、「翌営業日以降に内容を確認します」など、実際に運用できる案内にします。受付番号や確認手段を設ける場合も、利用する製品と社内運用の双方で実現できるかを事前に確認します。

たとえば、営業時間外に住所変更の依頼が届いても、「変更しました」とは回答しません。変更手続きの一般的な方法はFAQで案内できますが、個別処理が必要なら、現在は受付段階であること、確認予定、必要な手続き先を示します。チャット上で氏名、住所、契約番号などを受け取る前に、受付に必要な情報か、保存や閲覧のルールが整っているかを確認してください。

社内では、翌営業日に最初に確認する担当者、受付一覧を見る場所、未処理を発見する方法、担当部署への渡し方、完了を記録する欄を決めます。通知だけに頼ると、通知先の設定ミスや担当者不在によって受付が残るおそれがあります。通知の有無とは別に、受付一覧と未処理状態を確認できるかを、対象製品の最新仕様も含めて確かめます。

次の段階へ進めるのは、受付から担当者の確認までを追跡でき、利用者に回答完了と誤認させず、緊急連絡を通常受付から切り分けられたときです。受付漏れ、通知失敗、未処理の長期化が見つかった場合は、受付対象を縮小します。必要に応じて、フォームや電話など検証済みの代替導線へ戻します。利用者向けの案内文や翌営業日の確認フローを詳しく設計する場合は、営業時間外の問い合わせ対応を確認してください。

第3段階は有人引継ぎの条件と渡す情報を決める

有人引継ぎは、チャットが答えられないたびに無条件で人へ転送する運用ではありません。何をきっかけに、どの担当部署へ、どの受付時間内で渡すのかを決めます。個別契約の判断、返金や例外処理、強い不満を伴う相談、回答根拠がない質問、同じやり取りが繰り返されている場合などが切替候補です。

利用者には、切り替える理由と次に起きることを伝えます。「担当者による確認が必要です」「現在は受付時間外のため、内容を受け付けます」「お急ぎの場合はこの窓口をご確認ください」のように、現在の状態が分かる案内にします。実際には待機担当者がいないのに、すぐ有人チャットが始まるように見せてはいけません。

担当者へ渡す情報は、量ではなく、判断に必要かどうかを基準に選びます。

• 利用者の質問要旨と希望する対応
• 確認済みの対象、日付、契約区分などの条件
• チャットが案内した内容と参照先
• 解決していない点と引継ぎ理由
• 受付日時、受付チャネル、担当部署
• 業務上必要な場合に限った連絡方法

一方、自由記述欄に機微な情報を書かせたり、「念のため」という理由で個人情報を広く集めたりしないようにします。本人確認が必要な手続きでは、チャット内ですべてを完結させず、定めた本人確認の経路へ案内する方法もあります。収集目的、閲覧者、保存範囲を社内ルールと対象製品の条件に照らして確認します。

引継ぎ後は、担当者が情報を受け取っただけで完了にしません。担当違い、同じ内容の再聞き取り、利用者への連絡漏れ、対応期限を過ぎた未完了を記録します。担当者が会話を確認できるか、どの項目を渡せるか、自動割当てや通知が可能かは製品によって異なります。未確認の機能を前提に運用を組まず、必要な操作を利用予定の環境で確認します。

切替条件と引継ぎ項目をさらに具体化する場合は、AIから有人対応へ引き継ぐ方法を参照してください。人へ渡せない時間帯の表示と代替窓口も、同じルールに含めます。

3段階の開始・移行・差戻し条件を運用表にする

段階導入では、担当者の感覚だけで次へ進めると、公開範囲が急に広がります。対象、開始条件、確認者、公開後に見る記録、移行条件、差戻し条件を一枚の運用表にまとめます。外部の固定的な削減率や正答率をそのまま採用せず、現在取得できる記録と、自社で許容できない事象を基準にしてください。

確認期間を一律の日数で決める必要はありません。問い合わせ数が少ない窓口では、短期間の確認だけでは例外的な質問が現れないことがあります。予定日が来ただけで次へ進まず、標準、条件付き、対象外、時間外など、想定した種類の記録を確認できたかで判断します。

チャットの利用後に電話した人を、個人単位で追跡できない場合もあります。そのときは、電話受付で自己申告された利用経路、チャネル別の問い合わせ分類、同じ質問の増減、チャット内で電話案内が選ばれた記録など、取得できる情報を組み合わせます。追跡できない数値を推測し、削減効果として扱わないようにします。

週次の確認欄には、発生日、事象、影響したFAQや受付、一次対応、原因候補、修正担当、再確認日、再公開の判定を残します。問題の有無だけでなく、見つかった問題を誰が直し、利用者への案内をどのように回復したかまで記録します。この形式なら、担当者が交代しても判断経緯を引き継げます。

電話・チャット・フォームの役割と更新責任をそろえる

チャットボットを追加しても、電話やフォームが不要になるとは限りません。定型的な情報探索はチャット、書類添付や詳細入力はフォーム、緊急性がある相談や会話による確認が必要な相談は電話というように、問い合わせ種別ごとの第一導線と代替導線を決めます。

役割表には、チャネル名だけでなく、回答元、更新者、承認者、受付時間、障害時の戻し先を記載します。営業時間が変わったとき、Webページだけを直してチャットの回答が古いままでは、利用者はどちらを信じればよいか判断できません。情報の正本を一つに定め、変更時にどの順序で各チャネルへ反映し、誰が最終確認するかを決めます。

たとえば、解約条件の一般的な説明は公開規約を根拠にチャットで案内し、契約ごとの適用判断や例外交渉は有人窓口へ渡します。電話担当者も同じ規約と最新の業務手順を参照します。チャット専用の回答文を用意する場合も、適用条件が正本と食い違っていないかを更新時に照合します。

チャットで解決できない相談を、会話内に留め続ける必要はありません。確認済みの電話番号やフォームへ案内し、その文面が利用者の画面で理解できるかまで試します。回答範囲、更新責任、停止時の代替導線を社内文書へ落とし込む際は、チャットボットの運用ルールも役立ちます。

公開前テストと公開後レビューで対象を広げる

公開前テストでは、回答文が自然かを見るだけでは不十分です。正しい質問、言い換え、曖昧な質問、対象外、受付時間外、入力中断、古い条件を一組として確認します。時間外受付では担当者が不在の場合や通知を見落とした場合、有人引継ぎでは担当部署を誤った場合も想定します。

1. 期待する案内と根拠を先に書く。
2. 実際の回答、受付状態、引継ぎ先を記録する。
3. 利用者に表示される文面と、担当者側の記録を両方確認する。
4. 不合格なら、FAQ、案内文、対象範囲、引継ぎ条件のどこを直すか決める。
5. 修正した質問だけでなく、関連する質問群を再試験する。

公開後のレビューでは、無回答を見つけるたびにFAQを増やすとは限りません。質問の意味が曖昧なら、聞き返し方や選択肢を見直します。個別判断が必要なら有人対応へ渡し、そもそも担当外なら正しい窓口を示します。誤案内は、資料不足、古い情報、条件の混在、対象外への回答などに分けると、修正箇所を判断しやすくなります。

電話側では、チャット利用後の再入電、回答の食い違い、利用者が受付済みだと認識していた相談を確認します。受付側では、未処理、連絡不能、担当違い、対応完了の未記録を確認してください。引継ぎ後に同じ質問を最初から聞き直している場合は、渡す項目が不足しているか、担当者が記録を確認できていない可能性があります。

公開範囲を広げる判断は、「しばらく問題が報告されなかった」という理由だけでは行いません。必要な記録を担当者が確認でき、問題発生時に対象を縮小または停止できる状態かで判断します。会話記録の分類方法を詳しく確認する場合は、チャットボットの会話ログ分析も参照してください。

製品選定では段階導入を運用できるか確認する

製品を検討するときは、機能名の多さより、自社で作成した三段階の運用表を実行できるかを確認します。FAQについては、回答元と更新方法、回答しない条件、公開範囲の変更方法、履歴で確認できる項目を具体的に質問します。

時間外受付では、利用者への受付表示、担当者が受付を見る場所、通知の有無、未処理の確認方法を分けて確認します。有人引継ぎでは、切替条件、受付時間外の表示、担当者へ渡せる項目、会話履歴の見え方、障害時の停止方法と代替導線を確認してください。対応チャネル、外部連携、自動割当てなどは製品ごとに異なります。機能名だけで対応可能と判断せず、利用予定の環境と運用表を示して最新仕様を確かめます。

Socratesで実現できる範囲を検討する場合も、最初に現在のコールリーズン、第一段階で扱うFAQ、時間外受付の確認担当者、有人へ渡す条件を整理してください。その内容をもとに、利用したい環境での対応範囲、必要な設定、運用方法を個別に確認すれば、未確認の機能を前提にせず導入計画を組み立てられます。

コールセンターのチャットボット導入でよくある質問

FAQ自動応答・時間外受付・有人引継ぎは同時に始めてもよいですか？

原則として段階を分けます。三つの段階では、回答の正しさ、受付案件の追跡、担当者の対応開始という異なる確認が必要です。前段階の訂正や差戻しが機能することを確かめてから次へ進むと、問題の原因と影響範囲を切り分けやすくなります。

最初のFAQは何件用意すればよいですか？

固定の件数では決めません。回答根拠、適用条件、更新担当者が明確で、標準質問、言い換え、条件付き、対象外のテストを完了できる範囲から始めます。問い合わせ頻度が高くても、個別判断や頻繁な更新が必要な質問は初期対象から外します。

営業時間外に個別相談へ回答してもよいですか？

公開情報だけで結論を確定できない相談は、回答完了と見せず、仮受付または有人窓口へ回します。利用者には、受付状態、確認時期、連絡方法、緊急時の別窓口を示します。個人情報を受け取る場合は、収集目的と取扱いを確認し、受付に必要な範囲へ絞ります。

有人引継ぎでは、どの情報を渡しますか？

質問要旨、確認済みの条件、案内済みの内容、未解決点、受付日時、引継ぎ理由を基本にします。担当者の判断に必要な最小限へ絞り、利用目的が決まっていない個人情報や自由記述を広く集めないようにします。

チャットボット導入の効果は何で確認しますか？

電話件数だけでなく、無回答、誤案内候補、チャット利用後の再入電の兆候、受付漏れ、未処理、担当違い、引継ぎ後の未完了を確認します。導入前に取得できる現状値を把握し、追跡できない数値を推測して効果として扱わないようにしてください。

Socratesなら有人引継ぎまで自動化できますか？

必要なチャネル、切替方法、通知、担当者への情報の渡し方、外部連携によって実現条件は変わります。Socratesの対応範囲と最新仕様を個別に確認し、未確認の機能を前提にしないでください。先にFAQ候補と有人対応へ渡す条件を整理すると、必要な構成を具体的に相談できます。