【イベント参加レポート】ヘルプセンターを支える技術 ── 生成AI時代の自己解決エンジニアリング
イベント概要
検索技術とエンジニアリングをテーマに、顧客が自身の課題をスムーズに解決できる環境を構築する取り組みについてトークセッションとパネルディスカッションを通して紹介します。
顧客体験向上のため自己解決促進に取り組むメルカリ、ビットキー、Helpfeelの3社から以下を例に様々な切り口で取り組みを伺います。内製ヘルプセンターの意義や目的
自己解決が難しいドメインにおける挑戦と苦労
生成AI技術を活用した自己解決手段の拡大
参加した目的
他社のサポートではどのような工夫をしているのかを知りたい
生成AIを使った自己解決の事例を知りたい
他社のエンジニアの方と交流することで価値観をアップデートしたい
なにか良い知見があれば自社にも展開して「自己解決」について議論して改善したい
今回のスピーカーは3社。ざっくりメモは以下。
【一人目】ヘルプセンターを支える技術 生成AI時代の自己解決エンジニアリング
メルカリでは、顧客サポートの質を向上させるため、ヘルプセンターの内製化に取り組んでいます。本セッションでは、内製化の意義や取り組みの詳細について紹介します。具体的には、自己解決率の向上、CPT（Contact Per Transaction）削減、検索機能の最適化に向けた戦略や実施した施策について共有します。また、メルカリグループでの新規ビジネスのスケーラビリティーの向上を狙った、Help Center Platforming に対する取り組みについても紹介します。
※メルカリの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では、独自の検索エンジンを搭載した「Helpfeel」を事業展開しています。顧客企業に届く膨大な問い合わせを削減したり、成長企業に届く増え続ける問い合わせを抑制するのに貢献しているHelpfeelは「自己解決率」向上のために「検索ヒット率」を高めています。この実装と改善の取り組みをご紹介します。
Helpfeelは、正直知らなかったのですがGyaza（スクショのサービス）を提供している会社のプロダクトのようでそれでピンときました！AIを活用したFAQシステムおよびナレッジベースサービスで、ユーザーにストレスなく必要な情報にたどり着くために、これまでにないFAQの体験を提供するサービスとのこと。
導入事例として紹介されていたのが伊予銀行のよくある質問ページの検索フォーム。ここに曖昧な言葉を入れても、正確に必要な情報に素早く到達できるデモがされていました。↓実際に「紛失しちゃった！」とかで検索してみてください
語られていた工夫
問い合わせを「登山」に例え、「返品」というゴールに対しては、不良品、壊れた、間違えたなど多様な入口があり、異なるキーワードで構成される質問文を大量に生成し、狙った回答ページにたどり着けるようにしている。
→登山が趣味ってこともあってイメージつきやすかった。同じ山に登るでもたくさんの登山口があって、それぞれぜんぜん違う景色、勾配があります。
ビットシフト演算と論理演算で高速に実行できる検索エンジン。動詞のゆらぎを吸収し、クライアント側でQAのjsonを処理させる仕組みも導入。
例えば、「乗る」、「乗せる」、「乗れる」といった表現のゆらぎを吸収する機能を持つ。
Helpfeelで見ているKPI:
お問い合わせ件数
FAQページへのアクセス数
no hit率
一覧・検索結果からの離脱率
【三人目】どこに何の問題があるだろう？HWからSWまでの全領域を横断した最速解決を支援する生成AI活用
ビットキーではスマートロックをはじめとするハードウェアデバイスを軸においた様々なサービスを展開しています。
顧客環境で発生する問題がハードウェア領域なのか、はたまたソフトウェア領域なのか、どこで何が起きているのかを特定することは非常に難易度が高いです。
創業6年を迎え、様々な問題と解決方法を蓄積したデータベースが充実してきました。
それらのナレッジを活用し生成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の役割であり、他社の事例を少しでも知れたことは良い機会となりました。
やはりこういったイベントで他社の方と交流できるっていうのは良い刺激になります。