Recruit Tech Blog
“自分の言葉で探せるFAQ”で、問い合わせを50%削減できた話
はじめに
はじめまして、佐藤です。
ICT統括室の中で、問題発見や施策のディレクションのような仕事をしています。
今回は、ある日突然社内ICTのFAQサポートの中の人になって、問い合わせを50%削減できたときの話をご紹介します。
少しでも皆さんにとっての、学びや気づきの参考にしてもらえるとうれしいです！
それでは、よろしくお願いします。
こんな方におすすめ、かも！
・ユーザーサポートに問い合わせがたくさん来て困っている！
→FAQを充実させて改善したいんだけど…うまくいかない
新しい製品に入れ替えたいけれど、どれがいいのかわからない！とお困りの方
・クライアントからの要件を実現させる…そんな仕事も楽しいんだけど
→自社サービスに向けた仕事ってどういうことをしているのか、さくっと知りたいな！という方
リクルートICTのユーザーサポートは、問題を抱えていた
リクルート全社業務を支える社内ICTは、利用者総数4.5万人
サポートに寄せられる問い合わせ件数は 月間 約2500件、年間にすると約3万件という巨大規模だ。
数年前に導入したチャットボットFAQにより、以前より問い合わせは少なくなっているものの、
ユーザーからの満足度アンケートでは「FAQでは探しているものが見つからない」
「結局はサポートに問い合わせないといけない」…との声が多数という問題を抱えていた。
この問題を解決するべく、
私はFAQの中の人となり、探しものがすぐに見つかり・問い合わせを生み出さないFAQ の構築を目指すことになった。
善は急げ
ユーザーが「探しもの〜問い合わせ」をしている時間は生産性のない時間…。
それが年間に３万件も発生していることは、サポートのみならずリクルート全体に関わる大問題だ。
早速取り掛かる。
まずは、検索をしてもFAQが見つからない原因は、
・探している答えがFAQとして存在していないのではないか？
・検索キーワードが登録されておらず、Nohit（該当なし）が多いのではないか？ と当たりをつけて調査を開始した。
日々の問い合わせの回答に該当するFAQをチェックした結果、予想に反してFAQは潤沢に用意されていた。
それもそのはずで、サービスの担当者は日々寄せられる問い合わせを確認して、必要な回答をFAQとして用意していたし、
検索されるであろうキーワードも、日々チャットボットに登録させていたからだ。
ふむ
では、ユーザーは見つけたFAQを読んでいるのに、その上で問い合わせに進んでいる、ということか？
そこで次に、ヒットした候補FAQの押下状況を調査すると、なんとユーザーの多くはヒットしている結果を押下することなく
素通りして有人サポートチャットへ進んでいることがわかった。
ここまでの結果をまとめるとこうだ
１．チャットボットには必要とされているFAQは用意されている
２．検索キーワードも充足しているため、ユーザー検索がNohitになることは少ない（≒ユーザーは回答を”ヒット”させている）
３．（にもかかわらず）ユーザーの多くは検索結果に目もくれず、有人サポートを選択している
答えがあるのに見ることもなく先に進むというユーザー行動に混乱したわたしたちは、解決を製品機能に求めた。
漠然と「検索性能が高いFAQ製品」を導入できれば、ユーザーはFAQを見るようになるだろう、との考えに収束したのだ。
そして世にある製品を探し回り、数々のベンダーの説明を受けたが、いずれもが「正解」に聞こえてくる…。
しかし、それが「答えがあるのに素通りするユーザー」にとっての正解か？との問いには答えることができず、思考停止。
わたしたちのファーストアプローチは完全に頓挫してしまったのである。
ユーザーに憑依してミクロに追体験する
完全にとん挫した状況を打開するべく、わたしたちは頭を切り替え、問題解決の基本に立ち返って考えた。
問題解決の基本は、問題＝目指す姿と現実のGAP であるから、まずは解決するべき「問題」を明確にすることにした。
ここまでわかっているのは、
目指す姿：探しものがすぐに見つかり・問い合わせを生み出さないFAQ
現実：探しものの答えはヒットしているが、見つけてもらえず、結果問い合わせを生んでしまっているFAQ
ということである。
そして、そこから機械的にわたしたちのFAQが抱えている問題を言語化すると、
問題（GAP）：ヒットしている中にある正解を、ユーザーに見つけてもらえないこと となるに至った。
そうとわかれば、抽象的に解釈されたデータから示される推測ではなく、徹底的に一次情報にこだわり、
ユーザーに憑依してミクロに追体験することで、この問題を生んでいる原因を探しに行く。
方法は原始的だ。
とにかくユーザー問い合わせを１件ずつ読み込み、自分を困りごとを目の前にしたユーザー体験に憑依させる。
１．ユーザーの置かれた状況、直面した困りごとを、問い合わせ履歴から理解する
２．自分をその場に飛ばして…困りごとを抱えた状態でPCに向かい合い、FAQを立ち上げる
３．頭に浮かんだ自分の言葉を打ち込み、画面に表示された検索結果を確認する
100件、200件と同じ作業を繰り返す…探している答えは見つけられるか？
結果は…まったくヒットしない。
憑依体であるわたしはためらわず「サポートへ問い合わせ」ボタンを押してしまう。
なぜだ？
問題解決を考える自分に魂を戻して、再度考える。
FAQは潤沢に用意されているし、統計的には正解が”ヒット”している確率も高いはずなのに…？
そこで今度は、問い合わせ履歴の続きを読み漁り、解決に至った経緯を１件ずつ確認する。
結果的には回答に当たる「FAQ」を紹介され、それによって解決に至るケースが多い。
しかも、どこかで見たようなFAQばかりだ。
そこでもう一度FAQを検索すると、なんと正解のFAQは”ヒット”している。
でも、このFAQを開こうという気にならない。なぜ？
そのとき、脳に鋭い電流走る
表示されているタイトルが、自分の抱えている困りごとの解決方法に見えないのだ。
ユーザーは自分の求める答えに出会っていなかった
どういうことか？つまり…
現在のFAQは「事象と答え（困りごとと解決方法）」をセットで理解している作成者によって作成されているため、
様々な事象の答えを、１つのFAQで表現し、それに代表的な事象を表すタイトルが名付けられている。
例えば
事象：➀パソコンがフリーズした、➁PC画面が暗くなった、➂動作が重くなった…
答えのタイトル：パソコン故障交換方法
のように➀～➂の異なる事象であっても、提供する答えが１つなのであれば、
代表的な１つの回答を表すタイトル、例で言えば「パソコン故障交換方法」が名づけられている。
つけられるタイトルは１つなのだから「事象：答えのタイトル＝N：１」の関係になってしまうことは避けられない。
しかしこの状態では、あらゆる事象の答えを知っている作成者側が、
➀➁➂ですね！それは全部PC交換なのでこちらを見てくださいね！との意図で用意している正解FAQであっても、
事象を目の前にするユーザーたちは「フリーズを解消したい」「軽くしたい」「修理をしたい」への答えを探しているため、
「パソコンの故障交換」と言われても「聞きたいことはそれじゃない→サポートに聞くしかない」となってしまう。
（日常生活でバス停に立って、目的地を知っている人ならば、○○行きと書かれたバスが来たら迷わず乗り込めるが、
そうと知らない人は…「運転手さーん、これってXXXには行けますか？」と尋ねることになるように！）
答えはあっても素通りをしてしまう、が完全に再現された。
言われてみれば簡単な、しかし全く気付かなかったユーザー体験がそこにはあった。
しかし、この体験によって、ようやく求めていた問題の原因にたどりつき、
そこから、わたしたちが今回作りたいFAQの姿を言葉にすることができた！
問題：ヒットしている中にある正解を見つけてもらえないこと
原因：ユーザー自身が考えている「言葉」で回答されていないこと
ならば？
わたしたちは “ユーザーが自分の言葉で探せるFAQ” を構築してこれを解決する！
今度こそ。定めたゴールへ向けて走り出す
作りたいFAQの姿が明確になり、製品に求める機能も同時に明確になったため、改めて製品探しを再開した。
最終的に、ユーザーが入力した「自分の言葉（検索ワード）」と「正解のFAQ」の間を「翻訳」した表現で
検索結果を表示する機能を持つ製品の導入を決めた。
＜ユーザーの言葉を「翻訳」してくれる検索機能＞
検索ワード：➀パソコン フリーズ、➁PC 画面 暗くなる、➂動作 重い …
検索結果（翻訳）：➀パソコンがフリーズした、➁PC画面が突然暗くなった、➂動作が重くて動かない…
答えのタイトル：パソコン故障交換方法
こちらであれば、ユーザー自身が考えている「言葉」に導かれて、こちらが案内したい答えにたどり着いてもらえる。
実現したい姿が明確になってから、わずか二週間のスピード決定だった。
製品選定を終えた後は、「翻訳」の精度を高める作業に着手。
大量の問い合わせデータを全員で手分けして読み込み、黙々とユーザーの言葉を取り出す。
わたしたちのチームは、降霊師の集団と化した。
１．問い合わせ経緯を確認し、ユーザーが認識している事象を言葉にする
２．回答に当たるFAQと言葉を紐づける
３．言葉：回答＝N:１の関係に整理し、ユーザーから求められていないFAQを削除する
この結果、いくつにも分割されていたFAQがおもしろいように集約・整理され、不要なFAQも整理された。
ここまで、チャットボットで提供している情報を「FAQ」と表現してきたが、
・よく聞かれる質問：FAQ（Frequently Asked Questions）と
・聞かれるかもしれない想定質問：QA（Question and Answer） が、混在していることにも気づくことができた。
・”よく聞かれる”質問が集まり
・”自分の言葉”で質問をすると、翻訳されたタイトルが提示され
・確実に探していたFAQを見つけることができる
わたしたちは “ユーザーが自分の言葉で探せるFAQ” を、ついに完成させたのである。
今回の成功を振り返ってみる
”自分の言葉で探せるFAQ”のリリース後の効果測定は、以下の通り。
・問い合わせ発生件数：前年比約50%削減
・FAQによる自己解決率：85%（約15%アップ）
新しいFAQの高い信頼度が早くも認知され、利用者数も大きく増加した上での、
自己解決率向上、問い合わせ発生件数削減によって、新FAQ構築の大きな成功を確認することができた！
しかし！成功の余韻にひたるその前に、
仕事を続けていく中で、成功体験を積んだ際にはすぐさま「ふりかえり」をすることで、
この大事な資産を自分の血肉に変えて、今後の成功の再現性を高めることが成長の秘訣だ。
早速、わたしたちと同じくユーザーサポート、FAQ構築に試行錯誤されている方々へのシェアも込めて、
今回の成功を引き寄せたポイントは何だったのかを振り返ってみる。
すぐさま頭に浮かんだのは「視座と解像度」だ。
なぜ、最初のアプローチが失敗したのか？要因は以下にあったと今なら考えることができる。
＜失敗の要因＞
・「FAQ作成者側」一方からの視点で解決を考えた
・ユーザーが「見つけられない」原因をあいまいにしたまま、「検索機能」による解決に固執した
・一次情報を確認せず、抽象的に解釈された情報で答えを探した
上図を見ての通り、ユーザー不在の着眼点だったことを、今となれば理解できる。
一方、決めつけや固執を除いて、成功を引き寄せたアプローチでは以下のように変化する。
＜成功の要因＞
１．徹底的に高い解像度
・抽象的に解釈された情報ではなく、一次情報からユーザーの声を聞く
・ユーザーが「見つけられない」に出会っている瞬間にまで、ミクロに追体験する
２．点に固執せず視座を上げて捉える
・どうすればFAQによる自己解決が成立するのか、役割に捉われず一段高い視座で考える
現代の成熟した社会、組織で、わたしたちが直面するテーマは非常に抽象的で、答えが分かりにくい一方、
身の回りの情報・技術の進歩によりあらゆる選択肢が提示されている状況。
答えがわかりにくい × 選択肢だけやたらと多い＝思考停止 …に陥りやすい。
しかし、今回の活動を通して、そんな状況に立ち向かい、原始的な情報から事実を得て、
高い視座で構造的に考えることで、この難問に答えを出すことができ、大きな自信と成功体験となった。
また、この学びが、ここまで読んでくださった皆さんへ、
思いがけず共有できる財産にもなったことで、さらに充実を感じる結果となった。
最後に
わたしたちの “自分の言葉で探せるFAQ”は、その後も進化を続けている。
・ユーザー問い合わせデータへAI要約を加え、正確なユーザーの声を簡単に集められるように
・FAQのUI／UXデザイン・ライティングも日々アップデート
・FAQの解決のみならず、さらに上流…サービスそのものの品質改善で困りごとそのものの撲滅…など
ひとことに「サポートFAQ」構築と言っても、
問題解決、データ分析、エンジニアリング、UI/UXデザイン・ライティング、
プロジェクトマネジメント、サービスディレクションを総動員した仕事であることがわかる。
リクルートICTの仕事には、自分で問題を探し出し、そこへあらゆるスキルを総動員、こだわって解決を目指し、
その解決の効果が、大きなリクルート組織全体へ波及していくことを実感できるというおもしろさがある。
これは、クライアントからの要望を受けた改善活動とはまた違った、
「自社ICTサービス」を司る場所だからこそできる仕事の楽しみ方ではないだろうか！
そんな環境で、わたしはまた新たな問題を探し、解決させる活動を続ける日々から、
自分のスキルアップ × 自社サービスの成長というシナジーを感じつつ、今後も楽しく仕事に向き合っていけそうだ。
このブログを読んでピンと来た方は、ぜひ一度採用サイトもご覧いただけるとうれしいです。まずはカジュアル面談から、という方も大歓迎です。
また、他にも色々な記事を投稿していきます！
過去の記事もご興味あれば、ぜひ他の記事もあわせてご参照ください。
・Recruit Tech Blog
・リクルート ICT統括室 Advent Calendar 2024
・リクルート ICT統括室 Advent Calendar 2023