チャットボットの利用が進んでいる中で、当社ではQA型チャットボットと、プロセス型チャットボットとの2つに大別して活動に取り組んでいます。QA型チャットボットは、お客様のシンプルな質問に対応し自己解決を促進しますが、解決率には限界があります。一方で、プロセス側チャットボットは、対話によりお客様の質問や意図を明確にし、必要な処理までも自動で実施することができます。ここでは、メーカー向けに、プロセス型チャットボットとQA型チャットボットを組み合わせた、ハイブリッドチャットボットの導入事例を紹介します。
プロセス型チャットボットとは
一般的に、問い合わせへの対応は大きく2つに分類できます。一つは「問い合わせに対応する回答を案内すること」、もう一つは「後続のデータ更新や事務手続きなどに対応すること」です。QA型チャットボットとは、前者のようなお客様からの問い合わせに対し、自然言語処理によりQAを検索して回答する仕組みです。いわゆるFAQをチャットボット基盤に載せて回答を得やすくしたものです。
一方、プロセス型チャットボットとは、後者のような、商品の交換、お申込み、変更手続きといった、事務処理などを自動化するための仕組みです。大きなメリットは、お客様をお待たせせずに手続きすることで、処理漏れや、処理ミスなどがなくなり、自己解決を促進しながら顧客満足度を引き上げられることです。
関連動画のご紹介
プロジェクトの背景
あるメーカーでは、製品の普及が一気に広がり、数多くの問い合わせがコンタクトセンターに入っていました。市場で画期的な製品だったため、問い合わせの種類も多種多様で、応答率低迷と応対品質悪化によるクレームも増えていました。しかし、マーケティング施策は強化され、新製品が矢継ぎ早に市場に投入されることになりました。このまま人海戦術で対応すると、オペレータの規模を膨大に増やす必要があり、コスト増はもちろん、さらなる混乱が予想されました。
お客様から、
- 何か良い施策はないか？
- コスト下げながら、お客様満足度を上げる応対方法は？
- 自動化による呼減の具体的な方法を知りたい
と相談を受け、検討の結果、プロセス型チャットボットがソリューションの候補となりました。
導入に向けての取り組み
問い合わせ内容の可視化
導入に先立ち、まずはお客様の問い合わせを徹底して可視化しました。お客様は話題を選ばず、あらゆることをごちゃまぜにして問い合わせをしてきます。そのため、仮説でFAQを作ったり、チャットボットシナリオを作ったりしても、自己解決にはなかなか結びつきません。そこで、当社の方法論にもとづき、コール（チャット）リーズン分析を実施し、問い合わせ内容を可視化し分析することで、問い合わせの種類に応じた、最適な自己解決にの仕組みを整理しました。
具体的には、
- 過去の問い合わせをテキスト化
- クラスタリング技術を使って話題分類
- 方法論による人のチェックやノウハウの組み合わせ
- 問い合わせ単位ではなく、問い合わせの中に混在する話題をすべて抽出
などを実施しました。１つの問い合わせには、平均すると２～３の話題が含まれていますから、それを可視化することで、お客様が本当に何をしたいのか？何を問い合わせているのか？が明らかになります。
その話題ごとに、
- 自動化が可能か？
- QA型ボットで答えが出せるか？
- プロセス型ボットが有効か？
- 人の対応が必要か？
- むしろ人が対応すべきではないのか？
などにあてはめていくアプローチです。
その結果、問い合わせのかなりの割合が自動化しうる内容であり、主に２つのパターンがあることがわかりました。
- 製品の故障に関する問い合わせ（製品の不具合や、交換手続きなど）
- 自動化対象の7割を占める。
- プロセス型ボットによる自動交換で対応可能。
- 製品に関する問い合わせ（製品の入手方法や使用方法など）
- 自動化対象の３割を占める。
- 詳細な話題分類にもとづくQAの誘導で、正しい回答を提示可能。
この２つに対して、自動応答の呼減効果などを算定し、プロセス型チャットボットとQA型チャットボットを組み合わせた、ハイブリッドチャットボットの導入が決まりました。
シナリオ作成
まず重要なのは、製品の故障に関する問い合わせに対応する、プロセス型チャットボットのシナリオ設計です。コールリーズン分析から得られた分類された話題をもとにその内容を深堀し、
- 対象の問い合わせがどういう流れで進むのか？
- お客様の言い回しは、具体的にどうなのか？
- 事象を切り分けるための、最適な分岐は？
- トークを一方的にコントロールして会話が成り立つか？
などを判断し最適なシナリオを作成しました。その際、既存運用で利用しているオペレーターのトークスクリプト、業務フロー、後処理の流れなどを含めて、運用プロセスをすべて可視化し、それらを参考にしながらシナリオに取り入れます。並行して、チャットボットと他システムとの連携などのシステム開発要件を明らかにします。
その際、オペレータの利用ツールを調べ、その仕様を把握し、システム操作を含めた現状の全プロセス、参照情報、更新情報などが、プロセス型チャットボットによって完全に自動化できるようにします。他システムがAPI連携に非対応の場合、同様の情報のやり取りのために、他システム側にも追加開発が必要になります。
結果として、対象の問い合わせに関して最適なシナリオが完成し、処理に伴う応対ログや顧客情報を、APIを通じてCRMやその他システムに連携し、人海戦術＋システム入力で行っているプロセスのすべてを、プロセス型チャットボットに置き換えることができました。
QAコンテンツや学習データを整備
一方で、製品に関する問い合わせは多種多様です。こちらは、QA型チャットボットで対応しました。ここでも、コールリーズン分析結果を再利用して深掘りし、お客様が話題に応じて使う一般的用語を洗い出して検索性を高めます。お客様が、製品名やサービス名を正しく理解されているケースはまれなため、その揺らぎに対応した最適な代表質問を想定します。シナリオの中で、自然とブランドを印象づけるような工夫をしたり、内容によっては、文字だけの表現でなく、画像や動画などを組み入れた分かりやすい回答を準備します。
QAコンテンツがそろったら、コールリーズン分析の結果と問い合わせの発生頻度を考慮し、整理統合した代表質問に対して正しい回答をひもづけて、QA型チャットボットで検索可能にします。あらかじめ十分に学習させることで、実際のお客様の問い合わせ状況に応じて、自然な回答文が表示されるようになります。
視認性を追求したデザイン
骨格が出来たらデザインの検討に入ります。お客様が一目で見て該当する選択肢を選んだり、テキスト内容を把握するには、シナリオやQAコンテンツと同じくらいデザインが重要になります。スレッド内の文字数の制限、ボタン配置、カルーセルの動きなど お客様の様々な利用シーンを想定し、使いやすさを追求します。また、商品のイメージやサービスモデルを具現化し、カラーやアイコン表示などに反映します。これらのデザインを追求することで、お客様を飽きさせず、シナリオの途中離脱を防止し、想定した自己解決を促進することができます。
徹底したユーザテスト
構築が完了するとテストを実施します。設計上のシナリオが動作するかのユニットテスト・システムテストによるバグ出しは重要ですが、それ以上に大切なのは、利用するユーザに近い状況で、チャットボットが適切に自動応答できるかをテストすることです。
開発に関わっていない、コンタクトセンターのオペレーターなどを巻き込み、試行回数を確保し、純粋にユーザ視点に立ってテストを繰り返しました。製品による視認性の違い、想定外のパターンで実行されるシナリオ、論理的には合っていてもわかりにくい回答、シナリオにつまった場合の出直しのガイド方法など、膨大な時間をかけて発生した意見や課題を収集し、ユーザ視点に立ち戻り、シナリオ改善やQAコンテンツ改善などを通じて問題を解決しました。
プロジェクトに参画した全員が、このテストを通じて、どんな些細な事象も見逃さず、お客様への不信感や不満を完全になくすことができるように努力しました。技術者がシステムを導入しているのではなく、人が対応していたプロセスに可能な限り近い自動化プロセスを、業務・システムの両方の視点で実現することの重要性をあらためて認識しました。
運用プロセスの設計
最後は運用プロセスです。人による応対をもとにシナリオを作成しましたが、そのシナリオで対応しきれなかった場合、友人チャットにスイッチします。自動応答を離脱したとき、シームレスに有人チャットに連携する運用プロセスを整備することは、さまざまなメリットがあります。
- ゼロから状況を聞き出さずに、お客様が何をしたいかがわかるので、効率的な応対ができる。
- チャットボットのシナリオの不具合を補うことができる。
- 離脱理由とその後対応を分析し、離脱しないシナリオやコンテンツ改善ができる。
- 自動化の範囲をさらに拡充することも可能。
などです。そのため、テストの中では、あえていろいろなパターンで離脱した場合を想定して、その後の人による応対がスムースに行われるかの検証も重ねました。
シナリオやQAコンテンツのチューニング
こうして完成したプロセス型・QA型ハイブリッドチャットボットを、稼働後は継続的にチューニングします。
理由は、
- 実際にユーザが利用することで、テストで気が付かなかった不具合や気づきが発生する。
- 新しい商品やサービスが投入され、当初導入のビジネス要件やシステム要件が変わる。
- ユーザが利用しているうちにリテラシーが向上し、重要ポイントが変わってくる。
- 状況に応じて、重要なQAの順番は変化する。
- プロセスが最適化されると、さらなる効率化を目指して、別の要件が出てくる。
など、さまざまに変化する外部環境や内部環境に対応するためです。
そのために本プロジェクトでは、カスタマーサクセスチーム（Advanced CRMチーム）を立上げチューニングを、専任体制で継続的改善をサービスとして提供しました。
取り決めたKPIをもとに、
- シナリオが正常に動いているか？
- QAのカバー率や正答率は満足いくものか？
- 特別に離脱している不具合箇所はないか？
などを適時トレースし、課題を特定します。また、ユーザのコメント、オペレータの有人スイッチ後の意見への対応、蓄積されたデータを分析した改善のための仮説と検証の繰り返しから、シナリオやQAコンテンツのチューニングを通じて課題に一つ一つ対応しました。
導入による効果
プロセス型・QA型ハイブリッドチャットボットを導入し、一定期間チューニングした結果、以下のような効果が得られました。
まず、当初の目的である呼減は、導入直後で総コンタクト数の１割、チューニング後には３割超となり、人海戦術での対応に比べ、大幅にコストを削減し、顧客満足度を維持されています。これまではお客様から製品名や製品コードなどを聴取しなければならなかったものが、プロセス型チャットボットを導入し、基幹連携により登録製品の情報やお客様に紐づく情報を自動反映することで、お客様の煩わしさをなくしています。開発コストをわずか１年で回収し、お客様対応に欠かせないチャネルとして位置付けられるようになっています。
その後も新製品が投入され、定番のチャネルとして成長を続けながら、シナリオやQAコンテンツの品質も高まり、ユーザが自動応答に慣れてきたこともあって、自動応答のコンタクトボリュームは増大し、導入前と比較して約3倍になっています。チャットボット導入は、想定を超えるコンタクトボリューム増に対する呼減効果はもちろん、これまでリーチできなかった潜在顧客からの問い合わせを可視化し、適切な対応をすることで定性的であるものの製品やサービスの販売促進に貢献しています。
今後は、一層の自動化を推進、顧客満足度を向上しながらコストを下げる施策を継続、マーケティング視点での分析を強化、コンタクトセンターに集まった声をビジネスに効果的に利用します。
成功のポイント
今回の事例における、プロジェクト成功のポイントは、以下のとおりです。
- 問い合わせの可視化
- 仮説だけでチャットボットを導入しない。
- コールリーズン分析が重要。クラスタリング技術と方法論で問い合わせを可視化。
- 問い合わせ内容に応じたたチャットボットの選択
- プロセス型チャットボットとQA型チャットボットを組み合わせて最適なソリューションを選択。
- コールリーズン分析結果を深堀し、シナリオやQAコンテンツの最適化。
- 有人スイッチとのシームレスな連携
- 自動応答から離脱したユーザをシームレスな連携で対応。
- 離脱原因を分析し、シナリオやQAコンテンツの改善に利用。
- 導入とチューニングの最適な分担
- 導入をシンプルに、設計に凝り過ぎずにまず稼働させる。
- チューニングを通じて課題や不具合を察知し、継続的に改善する。
- 当初目標の達成と将来への貢献
- コンタクトボリューム増に対して、呼減を実現し開発費を早期に回収する。
- マーケティングに貢献するチャネルとして、成長させていく。
プロセスの自動化が必要なコンタクトセンターへのチャットボット導入には、大いに参考になる事例です。
まとめ
プロセス型チャットボットを中心に、QA型チャットボットを組み合わせた、ハイブリッドチャットボットの導入事例を紹介しました。
まとめは以下のとおりです。
- 呼量の大幅増に、コスト削減と顧客満足度の維持の両面に対応するため、プロセス型・QA型を組み合わせたチャットボットを導入。
- コールリーズン分析で、問い合わせの可視化を行い、シナリオ構築、QAコンテンツ最適化、視認性の追及、徹底したテスト、運用プロセスの最適化を実施。
- 早期に稼働させ、専門チームによる継続的改善により、シナリオやQAコンテンツをチューニング、当初の目標を早期に達成し開発費も早期に回収。
- チャットボットは成長を続け、潜在顧客へのリーチや問い合わせの可視化を通じて、マーケティングへの貢献を高めながら成長している。
執筆者紹介
