【コールセンターDX失敗】誰にも使われないチャットボットを作ってしまう危険性
こんにちは、Enlyt (エンライト) 代表の大野です。
DXという言葉が出来る17年ほど前から携帯電話内線システムによる、通信キャリアを問わない内線化や外出先から03発着信が出来るサービスを考案し、ビジネスシーンに変革をもたらしてきました。
時代の変化と共に、FAQチャットボット、RPA 、SaaS、PaaS、Twitterで サーバー監視と復旧、AI自動音声アウトバウンドテレマ(重要事項説明)やサイバー攻撃に対応すべく多要素認証を用いたコミニケーション連携など100以上のDXプロジェクトに参画し、ビジネスの変革に従事してきました。
そんな私の今回のブログでは、DXコンサルティングについて少しお話ししてみたいと思います。
目次
そもそもDXとは?
まず、WEBで「DX」「DXとは」「DXって何」と検索すると以下のような解説があります。
大手の開発会社モンスター・ラボ によると
「DX(デジタルトランスフォーメーション)」は、2004年にスウェーデンのウメオ大学のエリック・ストルターマン教授によって提唱された概念で、「進化し続けるテクノロジーが人々の生活を豊かにしていく」というものです。
つまり、“進化したデジタル技術を浸透させることで人々の生活をより良いものへと変革すること”。「Digital Transformation」を直訳すると「デジタル変換」という言葉になりますが、“変換”というよりも“変革”という言葉が鍵になります。
DX(デジタルトランスフォーメーション)とは? 意味・定義をわかりやすく解説
この説明を拝読した人の多くは「恐らく、DX化すると今よりも生活(仕事の業務効率等)が良くなるだろう」と思われるのではないでしょうか?
実は、DX化をしても想定していた効果が得られない(失敗する)ケースが多いんです。
勿論、正しいアセスメントアプローチをすれば、想定していた効果に近い効果は得られます。
DX化は本来、ITの導入といった手段をもとに、何らかの目的を達成して業務を変革することができますので、今より業務の可視化や自動化のポイントが見つかりコスト削減や、業務効率化、生産性向上といったメリットが享受されます。
しかしながら、正しくないアセスメントアプローチをすると失敗するケースが多いんです。
実際に経験したDXの具体例
実話を元にした依頼内容
DX化したい企業の管理者(Aさん)が外部のDXコンサルタント(Cさん)に
「弊社の社内ヘルプデスクの問い合わせで、[よくある問い合わせ] について、FAQを整理してチャットボット化して、社員の自己解決率を高めたい」と依頼した場合。
登場人物を整理しますと・・・・
①依頼主)情報システム部の管理者(以下Aさん)
②依頼主)情報システム部の社内ヘルプデスク担当者(以下Bさん)
③外部のDXコンサルタント(以下Cさん)
まず、Cさんが着手することは、何からだと思いますか?
多くの方は、「まずは現状把握と理解をすること」と答えるのではないでしょうか?現状把握と理解は確かに重要ですが、現状把握や理解をする為のアプローチ方法がさらに重要になります。
CさんがAさんに
「現状についてお聞かせ頂きたいので、担当者様と面談日程の調整を頂けないでしょうか?」
あるいは
「担当者様にヒアリングシートの記入をお願いできないでしょうか?」
と依頼したとします。
Aさんは、DXコンサルがどういうものかよくわからないので、
それが正しいことと信じ、そのままCさんにDX化推進を依頼したとします。
この結果はどうなると想像しますか?
答えは、DX化が失敗に終わります。
何故失敗するのか?
結論からいうと、失敗の原因はこの例の場合、Bさんのスキル(理解力、分析力)や思い込みで、誤った説明をAさんにしているケースが多いためです。
AさんがBさんに今日のタスク報告と感想を求めたとします。
Bさんは、
「本日は営業部からのMicrosoft365関連の問い合わせが多く、忙しかったです」
とAさんに報告。
ここでAさんは、何の疑いも持たず、Microsoft365関連の問い合わせが多いと信じ、それをAさんがCさんに説明しました。
CさんもAさんの話を鵜呑みにして、Microsoft365関連のデータをベースにFAQ収集、整理、分析、カテゴリー分けをしてチャットボット化を完成させたらどうなるでしょうか?
結果は、誰にも使われないチャットボットが誕生します。つまりDX化の失敗です。
理由は、DXで改善するべき点について不明確なことが多すぎたからです。
そもそも、本当にMicrosoft365関連の問い合わせが多かったのでしょうか?
このBさんの音声データを解析したところ、その日の対応件数は12件でした。
内訳を見ると、
- 2件:Microsoft365関連
- 6件:社内システムのパスワード忘れ
- 3件:人事関連システムの閲覧権限付与
- 1件:勤怠管理システムの打刻修正
では、2件しかなかったMicrosoft365関連の問い合わせを、なぜ多かったと報告したのでしょうか?
それは、Bさんが一番印象に残った問い合わせが、Microsoft365関連であったためです。つまり思い込みが招いた結果、誤った報告をしたことになります。
なぜ印象に残ったのかというと、Microsoft365関連の問い合わせは非定型の質問であった為、上司へのエスカレーションを行い、回答までに通常より多くの時間を要したからです。通常AHT※1 10分に対し、倍の20分以上の時間を費やしました。
※1 AHTとは、Average Handing Timeの略であり、コールセンター・コンタクトセンターの1応対にかかる平均処理時間のことを指します。
DXの失敗を防ぐ正しいアセスメントの方法
FAQチャットボット設計時で、ヒアリングを主体としたアセスメントによるDX化は失敗しやすいのはおわかり頂けたのではないでしょうか?
失敗原因は、複数あると思いますが、その一つとして、先述したようにクライアント担当者や分析担当者の勝手な思い込みや勘違いによるものです。
FAQチャットボット構築における失敗とは、分析があまいまま、チャットボットを構築した場合、ユーザーが自己解決できず、最終的に「オペレータに繋ぐ」を選択してしまうことです。
そして、Bさんが費やした時間だけ見ると忙しいとはいえないことがわかります。
(精神的な疲れで忙しいと感じたかもしれませんが・・)
ETVXフレームワークとVOCを重視
正しいアセスメント方法として一つがETVXフレームワークと、VOCを重視するアセスメントです。
ETVXとは?
サブプロセスレベルでの活動の重要なフェーズを4つに分けます。
- E→Entry criteria(開始基準)
- T→ Task(活動)
- V→ Validation(妥当性確認・検証)
- E→ Exit criteria(終了基準)
この4つのオブジェクトをつなぎ合わせることで、プロジェクト目標にあった一連のプロセスとして仕上げることができます。
また、オブジェクト単位に実績を計測することで、活動状況を評価、分析することが可能となり、定量的な実績値を元にしたプロセス改善にもつなげることができます。
ETVXフレームワークで見える3つの範囲
FTVXフレームワークを使用することで、下記の3種類に分けることが可能になります。
そうすることでシステム化できる範囲を定めることができます。
- 完全にドキュメント化できるもの
- 人の判断が入るもの
- 全くドキュメント化できないもの
全くドキュメント化できなければBP改善を諦めることになります。
ETVXフレームワークは、上位レベルまたは組織レベルのプロセスを表す方法ではありません。
VOCとは?
VOCとは「Voice of customer」の略称で、「顧客(お客様)の声」や「顧客の見方」を指します。
コンタクトセンターに集まる商品やサービスについての意見はVOCの一例です。
顧客の生の声を収集し、蓄積されたデータを分析します。その分析結果をもとに戦略を立て、具体的な施策を実行することで顧客体験を高めることにつなげていきます。
ただし、ETVXフレームワークと、VOC分析は奥が深く落とし穴もあります・・
・・・この続きは、続編のブログでご紹介いたします!
Enlytについて
株式会社Enlytはベトナムに開発拠点SupremeTechを持ち、これまで50以上の開発プロジェクトを行ってきました。ベトナムと日本のグローバルなチームで、数多くのプロジェクトを成功に導いてきました。
お客様の納得のいくまで、共に開発させていただき、アイデアを最高のかたちにサービス化いたします。
オフショア開発についてのお悩みやご相談がございましたら、下記ボタンより気軽にお問合せください!