【イベント参加レポート】ヘルプセンターを支える技術 ── 生成AI時代の自己解決エンジニアリング
イベント概要
参加した目的
他社のサポートではどのような工夫をしているのかを知りたい
生成AIを使った自己解決の事例を知りたい
他社のエンジニアの方と交流することで価値観をアップデートしたい
なにか良い知見があれば自社にも展開して「自己解決」について議論して改善したい
今回のスピーカーは3社。ざっくりメモは以下。
【一人目】ヘルプセンターを支える技術 生成AI時代の自己解決エンジニアリング
※メルカリのCSは、プロダクトの性質上、「カスタマーサクセス」ではなく、カスタマーサポートとのこと。逆にカスタマーサクセスはいないらしい。
メルカリのヘルプセンターの内製化
メルカリではzendesk等の外部ソリューションは使わずに内製化しているんだとか。恐らくユーザー数が多すぎて、より効率的に問い合わせをさばくために、内製化したツールを使い柔軟性のある対応が求められるんだと思います。メルカリ本体のデータ連携も内製化によって実現でき、個人最適化やデータ分析ができたり、社内標準のABテストエコシステムを活用できるので利点が多いとおっしゃっていました。
メルカリのCSディビジョンが目指すこと
Mission EffortlessCustomer Experienceをエンジニアリングの力で実現する
メルカリを利用するお客様が求めていることは、トラブル無くメルカリを利用すること。
問い合わせすること自体がお客様に手間を掛けることであり、問い合わせを発生させる根本原因を解決することを目指す。
→CREでもこれは重要課題だな…
お客様が問い合わせに至った場合でも、短時間、かつ少ない回数の問い合わせで解決する
ガイドを読んでも解決しない場合、問い合わせフォームに遷移し、24時間体制のカスタマーサポート(CS)にContactToolで問い合わせが飛ぶ。お問い合わせ項目はすべてCMSで動的に管理され、お困りごとに応じてフォームの項目が自動的に切り替わる仕組み。
標準化されたA/Bテストプラットフォームを用いて、HelpCenterの最適化をデータドリブンに遂行。例えば、ElasticSearchのチューニングを行い、検索指標の改善を達成。
メルカリのCSディビジョンのミッションは、エフォートレスな顧客体験を提供すること。お客様がトラブルなくメルカリを利用できるようにし、問い合わせを発生させる根本原因を解決することを目指している。短時間かつ少ない回数の問い合わせで解決することを重視している。
※エフォートレスとはユーザーがサービスを使う上で努力を要さないこと。ストレスを感じないこと。
追い求める指標:
自己解決率
CPT (Contact Per Transaction)
検索指標: 0-hit rate, CTR (Click Through Rate), 役に立った率, GVIR (Guide View Inquiry Rate), AHT (Average Handling Time)
想定ガイド閲覧率, フォーム入力率
CSAT (顧客満足度), DSAT (不満足度)
課題
メルカリグループが新規ビジネスを立ち上げるたびに毎回ヘルプセンターを作成する必要があり、それぞれに異なるプラットフォームを利用している。例えば、メルカリとメルペイは内製のヘルプセンターを使用しているが、Mercari ShopsはZendesk、Mercari HalloはHelpfeelを使用している。
感想
メルカリのアクティブユーザー数は月に2200万人という記事がありました。これだけのユーザーが居る以上、問い合わせ数は通常のサービスとは桁違いの量が来ることと思います。そのためにはいかに自己解決してもらえるか、そもそも問い合わせに発展させないようにどうすればいいか=エフォートレスを追求していく必要があり、そのためにヘルプセンターを内製化したり、サポートメンバーの得意領域に対して問い合わせの内容から自動で問い合わせを振り分けたり、問い合わせフォームを動的に管理し、問合せ担当者の自動の負荷分散の仕組みをつくったり、とにかく効率的にさばくためにどうすればいいかと言ったノウハウが多く語られていました。
内製で他社のSaaSのようなツールつくっているようでそれもすごい…
【二人目】自己解決を支える検索技術と改善サイクル
Helpfeelは、正直知らなかったのですがGyaza(スクショのサービス)を提供している会社のプロダクトのようでそれでピンときました!AIを活用したFAQシステムおよびナレッジベースサービスで、ユーザーにストレスなく必要な情報にたどり着くために、これまでにないFAQの体験を提供するサービスとのこと。
導入事例として紹介されていたのが伊予銀行のよくある質問ページの検索フォーム。ここに曖昧な言葉を入れても、正確に必要な情報に素早く到達できるデモがされていました。↓実際に「紛失しちゃった!」とかで検索してみてください
語られていた工夫
問い合わせを「登山」に例え、「返品」というゴールに対しては、不良品、壊れた、間違えたなど多様な入口があり、異なるキーワードで構成される質問文を大量に生成し、狙った回答ページにたどり着けるようにしている。
→登山が趣味ってこともあってイメージつきやすかった。同じ山に登るでもたくさんの登山口があって、それぞれぜんぜん違う景色、勾配があります。
ビットシフト演算と論理演算で高速に実行できる検索エンジン。動詞のゆらぎを吸収し、クライアント側でQAのjsonを処理させる仕組みも導入。
例えば、「乗る」、「乗せる」、「乗れる」といった表現のゆらぎを吸収する機能を持つ。
Helpfeelで見ているKPI:
お問い合わせ件数
FAQページへのアクセス数
no hit率
一覧・検索結果からの離脱率
【三人目】どこに何の問題があるだろう?HWからSWまでの全領域を横断した最速解決を支援する生成AI活用
ビットキーは、スマートロックをはじめとするハードウェアデバイスを軸に様々なサービスを展開しているそうです。顧客環境で発生する問題の特定と解決を支援するため、生成AIを活用した社内ヘルパーボットを開発したという話がありました。
トラブル対応の難しさ
bitkeyにはtoCとtoBがあり、toBがとにかく大変だとのこと。
toC領域: トラブル対応は原則的にコールセンターで行われる。プロダクトが限定的であり、ユースケースもある程度限られるため、比較的対応しやすい状況。
toB領域: 企業向けの場合、カスタマーサクセスの担当者が直接対応する。ハードウェアデバイスの種類が多く、環境の違いやユースケースが複雑で、開発相談になることも非常に多い。このため、自己解決できる顧客は少なく、対応が難しい。
具体的には、ハードウェアのロット、ファームウェア、スマホアプリのバージョン、事象発生時のSaaSのバージョン、海が近いと防水性能に影響が出るなど、複合的な要因が大量に重なり、最善の対応を取るのは非常に難しい。その結果、とてつもない脳内辞書を持つ職人が生まれ、その職人がいるかどうかで回答の速さに影響が出てしまうことがある(属人化)。
じゃあ職人をAI化しよう!という取り組み
属人化の問題を解決するために、蓄積されたナレッジをもとに生成AIボットを開発。
社内用のSlackボット
誰でも気軽に質問・相談できるように、Slackボットとして導入。
Slackボットは応答結果を評価できる仕組みにしてチューニングしている。
Claude 3 SonnetやGemini 1.5 ProといったAIモデルを切り替えて使用している。
最初はGoogle CloudのVertex AIをベースに開発したが、結果が良くなく早々にAWS BedRockに移行。今のところモデルはGemini 1.5 Proが非常に高評価とのこと。
Claude 3 SonnetもいいがGemni1.5proが非常に高評価。
生成AIを使いこなすには時間がかかる
それっぽいものは簡単に作れる。それっぽいものを現場で使おうとすると、うまくいかないことがほとんど。生成AIを使いこなすには、いろんなチームを巻き込み、フィードバックをたくさんもらい、何度も試行錯誤とチューニングが必要。
生成AIを効果的に活用することで、問い合わせが発生する前に問題を解決し、顧客を困らせないようにすることが目標。
とにかく、「問い合わせが発生する前に解決したい」 => 自己解決エンジニアリング
パネルディスカッション
CSチームとの目線合わせや連携をどうやっていますか?
メルカリ
PdMとは別にCSのカウンターパートの役割を持った方がプロダクトチームのスクラムに参加している
bitkey
プロダクトマネージャーがいるので、PdMからお客様の生の声を聞いている
定期的なMTGの場で共有を受けている
CSと個人的に雑談する文化があり、そこで顧客の名前の声を聞く機会が多い
生成AI使ってぶっちゃけどう?うまくいってる?
メルカリ
まだ道半ば。正式に採用されていないがテストはしている。お問い合わせに使っているが課題がある。約束事をしてはいけないし、CtoCのマーケットプレイスなのでお困り事が複雑。どの領域で使うかをしっかり検討する必要がある。チャレンジは引き続きしたい状況。
ヘルプセンターを主務としている方々の今後のキャリアはどうするべき?
変化についていけるが大事。ヘルプセンターに限らずエンジニアも同じ。何に変わっても同じ。今あるものだけ解決しようとしていると仕事がなくなっていくのでいろんなことを武器として使っていけるようになるのが大事
参加した感想
生成AIの活用はまだまだ各社試行錯誤中なんだなと強く感じました。AIは嘘も言うからなかなか現時点で外部向けに提供していくのも、ハードルが高そうです。ただ、内部向けのソリューションとして使っていくのは、本当に活用シーンが多く取り入れていきたいと思いました。
自己解決してもらうにはどうすればいいか、そもそも問い合わせを起こさせないためにできることは?問い合わせが起きてしまったら二度とその問い合わせが起きないようにするにはどうする?みたいなことはまさにCREの役割であり、他社の事例を少しでも知れたことは良い機会となりました。
やはりこういったイベントで他社の方と交流できるっていうのは良い刺激になります。
この記事が気に入ったらサポートをしてみませんか?