ヘルプセンターを支える技術 ── 生成AI時代の自己解決エンジニアリング に参加してきた。
イベント概要は以下(上記イベントページから引用)
検索技術とエンジニアリングをテーマに、顧客が自身の課題をスムーズに解決できる環境を構築する取り組みについてトークセッションとパネルディスカッションを通して紹介します。
以下、各発表の(私の解釈した)概要と感想。
メルカリのヘルプセンター内製化:自己解決率向上とCPT削減への挑戦(仮)
メルカリのヘルプセンターの紹介から、お問い合わせまでの導線、ヘルプセンターの指標とその改善についてのお話。 お問い合わせへの対応が24時間と聞いてすごい!となった。お問い合わせに対応する拠点も複数あり、拠点ごとに特定の問い合わせはA拠点に割り振ったり、問い合わせ全体のN割はB拠点に割り振ったりとロードバランシングしているとのことで、圧倒的ユーザー数を持つサービスはやることが違うな…となった。
ヘルプセンターの目的は「お客様に自己解決してもらうこと」。これ自分の中の意識として弱かったので反省。
初めて使うサービスで機能の操作説明なんてまぁ読まない。ヘルプページを見るタイミングはわからないこと、困ったことを解決したい時なんですよね。
自己解決してもらうことが目的であれば当然指標もそれに沿ったものになるので、問い合わせ率や記事の「役に立った」率などが指標になっていた。 お問い合わせに関してもお問い合わせから解決にかかるまでのリードタイムを指標にしていた。
内製化やそれのメリット、データ分析への活用など未来に向けたお話もあり参考になった。
自己解決を支える検索技術と改善サイクル
HelpfeelでのFAQの検索の手法、仕組みについてのお話。
意図予測検索という言葉は初めて聞いた。 伊予銀行さんのサイトのデモがわかりやすく、ユーザーが入力する文章から課題を予測し、その課題を解決するための記事をヒットさせる仕組み、だと思う。多分。 ヘルプページのデモ、顧客のサイトをそのままデモに活用できるの強いな!と感じた。
一つのFAQの記事にたいして、ユーザーがそこに行き着くまでの道筋も様々で、登山で例えている例もわかりやすかった。
インクリメンタルな検索をする場合に、一文字入力される毎にDBに問い合わせていたらレスポンスに影響があるので、あらかじめFAQを取得しておいてそこを検索するという仕組みは目からウロコで、FAQのボリュームゾーンは500記事〜 程度なのでできる戦略らしかった。
どこに何の問題があるだろう? HWからSWまでの全領域を横断した最速解決を支援する生成AI活用
社内の自己解決支援にAIを活用しているお話。
ハードウェアとソフトウェアを販売しているビットキーさんの事例で、特にハードウェアの技術的な問い合わせは非常に難易度が高いらしい。 ハードウェアのバージョン、ファームウェアのバージョンだけではなくロットの差異など要因は様々。そこに更に環境要因(温度、湿度、海風)も加わるため非常に難易度が高いとのこと。聞いただけで難しさが予想できる。大変だ。
そういった状態で生まれるのが「とんでもない脳内辞書をもった職人」でどうしてもその職人に依存してしまうという問題。 これは会社に1人はいる「あの人に聞けば大抵のことは解決する人」でわかりみが深かった。
そういった職人をAI化できないかという試みのお話。Slackボットにして質問ができ、応答結果にvote(+1, -1)できる仕組みで運用している。 精度を高めるためには投入するデータが重要で、ユーザープロンプトだけでなくシステムプロンプトも重要とのことだった。このあたり詳しくないのでなるほどわからん状態だった。
あと大事なこととして、AI開発者と利用者の関係ではなく、一緒に作り上げる仲間として取り組むのが大事と。うん大事だ〜となった。
パネルディスカッション
CSチームとの目線合わせ、ぶっちゃけ生成AIどうよ?、ヘルプセンターを主務としている方々の今後のキャリアについてのパネルディスカッション。 色々おもしろいお話が聞けたけどパネルディスカッションなので念の為記載しないでおく(お酒が回ってきてメモとってなかったとも言う)
全体の感想
会社のサイドプロジェクトとして、技術的問い合わせをどう解決、改善していくのかをやっていて、そのヒントとなるものがあれば、と参加したのだけれど、色々と参考になるお話が聞けた気がする。
社内ナレッジの蓄積、社内ヘルプページ、生成AI全部必要なきがするし欲しいやつな気がする。
あと、運営スタッフの方の中にRubyKaigiのイベントでご一緒した方もいて縁を感じた。
出張ついでに勉強会に参加するというムーブは流れで参加できるので継続が楽だと思いつつ、今の時期はたまたま出張が多く流石に疲れがたまってきた。 次の出張は健康的な時間に新幹線に乗ろうと思う。