コールセンター向け顧客対応チャットボット導入検討時のポイント

Bot（ボット）という言葉をご存知でしょうか。ウィキペディアによれば、Botとは「robot（ロボット）の短縮形・略称で、転じてコンピュータやインターネット関連の自動化プログラムの一種のこと」とあります。

このBotをチャットツールやSNSのメッセージツールに利用したものがチャットボットと呼ばれるもので、SFに出てくるロボットのように、自動的に人間との会話を行うことが出来ます。

最近FacebookやLINEなどの大手SNSがボット向けのAPIを公開開始したことで注目を集めており、またマイクロソフトの人工知能ボット「りんな」や「Tay」なども話題になっています。その性質上、コールセンターにおける顧客対応業務への適用が期待されており、実際に導入した事例も増えつつあります。

今回はこのチャットボットの導入にあたって検討するべきポイントについて、弊社メンバーからの寄稿記事を公開します。

こんにちは、弊社ハイテク雑用担当のM.K＠神谷町です。

「そろそろうちも世間で流行りのチャットボット的なものを導入してみては」というようなことを上司から言われ、現場で頭を抱えている顧客サポートやコールセンタの運営担当の方も多いかと思います。我々もそういったご相談をいただく機会が多くなってきましたので、チャットボットの導入をどのような観点で検討すれば良いのか、少し考えてみた内容を本記事にまとめます。

1. 目的と数値目標

なぜチャットボットを導入するのか、その具体的な数値目標はどう定義するか、という点について考えます。

基本的には、人間にしか出来ないことを人間が行い、機械の方が得意なことは機械にやってもらう、という考え方になります。機械が得意なことは何かというと、①大量に、②長時間、③高精度で続けるような処理で、かつ④定型的な処理内容に限られます。

チャットボットに当てはめて考えると、

①大量に・・・サーバの処理能力の許す限り、大量ユーザに同時対応可能
②長時間・・・サーバ上のソフトウエアにより無人対応、24時間・365日休まず稼働可能
③高精度・・・人間と違い疲れることが無いので、常に同じ品質で対応可能

となります。

ただし、その対応内容は ④定型的な処理・・・ソフトウエアで実現可能なものに限られます。このため、チャットボットでの対応を行う業務は、ある程度定型的な、プログラミングで表現可能なものに限定されます。

１）目的について

現在人力で対応している業務のうち、チャットボットで対応可能なものを切り出します。例としては、単純なキーワード検索的お問い合わせ（FAQの全文検索や、用途を絞った単純な問い合わせ）や、定型化された手続き（項目数の少ない申込み処理、毎回ほぼ同じ内容の定型的やりとり）などが挙げられます。これらを顧客サービスのレベルを維持しつつチャットボットにより自動化し、メリットを享受することが目的となります。

なお、これまで人力であった処理がシステム化されることでデータとしての蓄積にも繋がるため、データの活用などの新たな付加価値を生むケースも有り得ますが、それについて深く検討するのは次のフェーズ以降で充分かもしれません。

２）数値目標について

コールセンターのPBX／IVRや、WEBサイトの運営において、普段使用しているKPIと同様の考え方で定義可能です。採用するチャットボットシステムにおいて、どういうデータが取得可能なのかは採用したシステムにも依存しますが、本来必要な指標とその算出ロジックを定めてみてください。

・受注系のコールセンターの場合

チャットボット上で完結した受注数が明確に把握出来るため、その件数をベースに目標値を定めれば良いと考えます。また、チャットボットの導入により悪化している指標が無いか、ウオッチすることも重要です。操作性の悪さや案内不足により、ユーザに離脱を強いている場合も有り得ます。併せて、チャットボットからオペレーターへ接続し受注処理を行うような導線についても、計測範囲をどこからどこまでとするか、チャットボットの回答と受注レコードを紐付けた測定が仕組み上可能なのか、などという点も加味する必要があると思われます。

そもそも、チャットという手段の性質として、非同期にコミュニケーションが進むことを許容するため、例えば、朝の通勤電車の中でチャットを開始し、その日の夜の帰宅後にチャットの続きを行う、というようなケースも有り得ます。これらをどのように取り扱うのかという点も検討が必要と思われます。

・お問い合わせ／顧客サポート系のコールセンターの場合

チャットボットでの回答完結率という形でデータが取れれば良いのですが、実際には困難です。お客様が離脱した際、課題が解決したかどうかが不明であること、またよくある「この回答で満足していただけましたか？Y／N」などという測定のための仕組みを導入したとしても、実際にはこれをクリックしていただけないことが多いためです。

このため、導入前と比べてコールセンター側での対応が何％減ったか、つまり有人対応からチャットボットに何％程度を肩代わりさせることが出来たか、というあたりを目標にせざるを得ないと考えます。

また、少々気が早いかもしれませんが、チャットボットの有効性が実証された場合には、既存のチャネルからチャットボットへとユーザを誘導するための施策の実行と、その成果の計測も求められるようになります。このため、チャットボットへの誘導施策のKPIと、その測定手段も必要となります。

２. 初期導入時の作業内容について

チャットボットの導入直後は、システム的な調整作業を継続的に行う必要が有ります。なお、本作業は顧客対応品質に直接影響する部分でもあるため、出来る限り社内メンバーで運営していくことをおすすめします。

・お問い合わせ／顧客サポート系のコールセンタの場合

運用開始後、チャットボットの自動回答のベースとなるFAQデータの精度を高めるため、これを継続的にメンテナンスしていくことなります。これは作業イメージ的にはWEBサイト上でFAQコンテンツを公開する際の運営業務と基本的に同一です。具体的には、検索回数上位のキーワードやセンテンスに対して、実際に表示されたFAQの妥当性の確認を行います。

併せて、ヒットしなかったキーワードについて、ユーザー定義辞書的なものや、FAQ自体を充実する、というフィードバックのプロセスを回します。

もし、FAQについてのリコメンドの仕組みが既にあれば、それを流用することで、このFAQデータの精緻化工数を削減できる可能性があります。リコメンドの仕様についての妥当性は充分確認済みのはずであるため、チャットボットの応答生成に活用できれば、少ない工数で精度の高い応答が可能になると思われます。

・受注系のコールセンタの場合

一方、受注業務（ECサイトや、受注センタ）をチャットボット対応した場合も、基本的な考え方はお問い合わせ業務と同様です。

定常的な運営業務として、商品の検索機能、リコメンド機能などについての妥当性確認作業が発生します。もちろん発注処理部分の妥当性は非常に重要であり、その確認も充分に必要ですが、この部分は初期導入直後に一通り品質の確認が出来れば、その後はそれほど手を加えることは無いケースが多いと考えます。

３. 構築ツールや手法の選定

チャットボットの構築には既存のシステムや業務の理解が要求され、またユーザーインターフェース的な知見もある程度要求されるため、その構築の難度は比較的高いと考えます。

その一方で、インターネット上にはチャットボットを構築するための技術情報やサンプルコードなども大量に存在するため、とりあえず単純な機能のチャットボットであれば、その作成に関するハードルは極めて低い状況であるという一面もあります。

個人的なお勧めは、まずは小さく始めて、チャットボットとはどういうものか腹落ちしたら、次のステップに進むかどうかを判断する、というようなやり方です。

構築作業は、出来れば内製か、あるいは親しい開発業者の方に軽く相談してみるというのが良いのではないかと考えます。

事業の内容や既存システムの構成などをある程度理解している方の方が、どういった部分にチャットボットの適用余地が有るか考えやすいと思います。

かつ、新しい技術に関心が有り、個人的にチャットボットを作って動かしてみているような技術者の方であれば、比較的容易にプロトタイピングが可能と思います。

そういう方が周囲に居ないか、探してみることをおすすめします。

まとめ

チャットボットの導入において、どういう点に気をつけたら良いのかを考えてみました。弊社もまだまだ手探り状態の部分も多いのですが、参考になれば幸いです。顧客対応業務におけるチャットボット活用は今後ますます広がっていくと思われます。弊社でも継続的に調査を行い、興味深い事例などが有ればこの場で公開する予定です。

ご興味あればどうぞお気軽にお問合せ下さい。