お客様が自分自身で疑問を解決できるようサポートサイトを作ったものの、思うように問い合わせが減らない。加えて、サポートサイトをどのように改善すればいいかわからない。

このような悩みはありませんか？

サポートサイトを改善するには、お客様がつまずくポイントを把握する必要があります。

では、どのように「お客様がつまずくポイント」を見つければいいか？

本記事では、お客様の自己解決を促すための、サポートサイトの改善点を見つける方法をご紹介します。

サポートサイトを構築する上で忘れてはいけない指針

サポートサイトの改善点を見つける方法の前に、サポートサイトを改善するにあたって事前に把握しておきたい指針を解説していきます。「サポートサイトを構築・改善し、ユーザー体験を高める」ために欠かせない考え方ですので、ぜひご一読ください。

サポートサイトは「疑問が発生しないわかりやすいサービス」のためにある

そもそも、企業が目指すべきは「疑問が発生しないわかりやすいサービス」です。当然のことながら、サービスを誰もが簡単に使いこなせれば、サポートは必要ありませんよね？

とはいえ、「疑問が発生しないわかりやすいサービス」を作るのは難しい。また、忘れてはいけないのが、お客様にとって電話での問い合わせは面倒であり負担になることです。

そこで、サービスの利用中にわからないことがあったお客様が、電話が面倒だからという理由で離れてしまわぬよう、サポートサイトが必要となります。

先ほども述べた通り、目指すべきは「疑問が発生しないわかりやすいサービス」を構築することです。そのためには、お客様の疑問発生をサービス改善のためにフィードバックする仕組みが欠かせません。

お客様が疑問を簡単に自己解決できるためにサポートサイトを改善したうえで、そのお客さまの疑問が発生しないようサービスも改善することが、顧客満足度を高めるためには重要です。

サポートサイトで重要なことは「お客様がすぐに疑問を解決できたか」

とはいえ、サポートサイトの担当者が、サービスそのものの改善に取り組めるとは限りません。一見当たり前ですが、「サポートサイト担当者が確実にできることは、疑問が発生したお客様が疑問を簡単に解消できるサポートサイトを作ること」です。

では、サポートサイト作りで重要なことは何か？

それは、お客様が「ここを見たらすぐに疑問が解消できた」というサポートをきちんと提供することです。そのために、わかりやすいサイト動線や、読んだらすぐに理解・解決できるFAQが必要になります。

自己解決が"すぐに"できないサイト設計になっていると、お客様は「面倒くさいから、問い合わせた方がいいじゃん」と思い、電話などで問い合わせます。それでは、「自己解決の促進、問い合わせの削減」につながりません。

また、「電話での問い合わせ削減＝企業のため」だけではない、ということもおさえておきましょう。

繰り返しになりますが、電話での問い合わせはお客様の負担になっています。この負担を取り除くためには、お客様がサポートサイトで自己解決できなくても、手軽に疑問を解決できるチャネル（有人チャットやLINEなど）も用意しておくことが重要です。

そうしないと、お客さまが「疑問は解決できない。とはいえ、わざわざ電話するのは面倒だから、サービスの利用をやめる」と考える可能性すらあります。

参考記事：vol1.定義・総論編

お客様の自己解決を促進しつつ、離れてしまわないようにするためには、「お客様が疑問をすぐに解決できる」サポートサイトが不可欠です。

そこで、「どのようにサポートサイトの改善点を見つければいいか？」を紹介していきます。

サポートサイト改善の第一歩：お客様のサイト行動を確かめる

お客様の自己解決を促進し、電話での問い合わせを減らすためには、そもそも「お客様が特にどこで困っているか」を把握しなければいけません。そのために、まずはどういった問合せがきているのかの「内容」、どれくらいきているのかの「件数」を可視化する必要があります。

問い合わせ内容がわかれば「お客様がサポートサイトを使って自己解決できていない問題」が明確になりますし、問い合わせ件数がわかれば「どこから改善すると効果が大きいか」が見えてきます。

具体的には、「誰が」「いつ」「何で」困っているかを把握するために、まずはお客様のサイト行動の確認から始めましょう。サイト上でお客様が離脱しているポイントを改善できれば、お客様の自己解決を手助けできる可能性が高くなります。

一般的なサイト分析ツールを使った方法

ツールを使ったサイト行動分析は、ページ軸で来訪回数に区切って分析するのが一般的です。その他にも、購入やサービス利用の有無で区切る方法もありますが、今回はほとんどのツールが対応している「サポートサイトのマイページに訪れたユーザーを、来訪回数で区切った例」を紹介します。

来訪回数に区切ってサイト行動を分析すると、お客様がサポートサイトに訪れた目的を推測できます。

例えば、以下のようなデータがあったとします。

これを来訪回数で区切ると以下のようになります。

このように、来訪回数によって「マイページを訪れた目的」が違うことがわかりました。

お客様の目的がわかれば、お客様が求めているページへスムーズに案内でき、自己解決を促せます。例えば、マイページに初めて訪れたお客様の目的が「住所を変更したい」というものであれば、「初めてマイページにログインしたお客様に対して、ログイン後に表示する最初の画面で会員情報の変更方法を案内する」といった具合です。

また、お客様がサポートサイトに訪れた目的を踏まえ、下記のようなお客様の行動を把握できれば、サポートサイトの何を改善すればいいかの仮説が立てられます。

• 最初に遷移しているページはどこか？
• どこのページで離脱しているのか？
• サポートサイトをどのように使っているのか？

ちなみに、サイト分析ツールのひとつ「KARTE RightSupport」なら、ページ軸だけでなく人軸でも分析でき、一人一人の行動を深堀りできます。

補足：サポートサイト内で会員特定できていない場合

お客様のサイト行動を把握する際、会員の特定ができていない場合は、まず会員特定から始めましょう。会員を特定する方法はいろいろあるので、もしお悩みの際には問い合わせいただけたら無料で相談に乗ることも可能です。
>>https://rightsupport.karte.io/#form

さらにお客様の自己解決を促進するために、把握しておくべき2つのポイント

サイト行動を分析したうえで、もう一歩踏み込んでサポートサイトの改善点を見つける方法を2つ紹介します。

• ハイレベルサイトマップを作成し負の発生場所を視認する
• ユーザー体験上の負を把握する

ハイレベルサイトマップを作成し負の発生場所を視認する

ユーザーの疑問が発生する場所を把握するためには、ハイレベルサイトマップの作成がおすすめです。

ハイレベルサイトマップとは、サイト構造を可視化するための地図のようなものです。ユーザー行動を把握するためのハイレベルサイトマップでは、目的に合わせて特定のページ群だけを深く作成します。

ハイレベルサイトマップは、マーケティング部門などですでに作成していることが多いので、作成前に他部署に聞いてみましょう。

ただし、サイト構造の大枠しか可視化していないため、既存のハイレベルサイトマップをCS観点では使えないケースもあります。その場合は、上記画像を参考にして、新たに作成してみてください。

ハイレベルサイトマップを作成してわかること

ハイレベルサイトマップを作成することで、鳥の目で広くサイト構造を視認でき、次のようなポイントがわかります。

• お客様がどういうルートでサイトに訪問してどう回遊するか
• しっかりと自己解決に向けて流れているか
• サイト内に行き止まりはないか

サイト構造を可視化することで「俯瞰して作戦を考えられ、その作戦が個別最適になりすぎることを防げる」といった効果があります。

ユーザー体験上の負を把握する

お客様が自己解決できていても、ユーザー体験が良くないケースがあります。このような「ユーザ体験上の負」を把握することも、お客様に満足してもらうためには大切です。
例えば、操作方法を説明するためのシールが大量に貼られているコンビニのコーヒーマシン。

参考：コンビニコーヒーから考えるCX改善の落とし穴

プロダクトの中で付箋をたくさん貼っている状態は、本来の目的である「疑問が発生しないわかりやすいサービス」とはかけ離れていますよね。サービスサイトに置き換えると、ポップアップやウィジェットの追尾などでお客様に情報を提示している状態です。

サービスそのものがわかりやすければ、「付箋を貼る」「ポップアップで情報を提示する」というサポートは不要なはず。

本質的には「サイトやサービスがわかりやすく、ポップアップが不要な状態」を目指すべきです。とはいえ、誰もが疑問を持たずに使えるサービスの構築は難しいため、「短期的な修正として、目の前の課題をポップアップ機能で対応する」というのが、サポートのあるべき姿ではないでしょうか？

また、ポップアップのようなサポートが多いと、ユーザー体験を損ねてしまう可能性もあります。ポップアップのようなサポートは1画面に1つまでが理想です。2つ以上あるなら、サイトやサービスを見直すタイミングと言えます。

すぐには改善できないかもしれませんが、サービスそのものを改良しながら、不要なサポートを取り除いていきましょう。

ちなみに、「KARTE RightSupport」なら、ユーザーの行動を可視化したうえで深掘りでき、データを取ってサポートサイトの改善につなげられます。

おわりに

お客様の自己解決を促すために、まずはサポートサイトの改善点を見つけなければいけません。そのために、サイト分析ツールを使ってお客様のサイト行動を分析してみましょう。次回は「分析して得たデータを、どのようにしてサイト改善に活かせばいいか」について解説していきます。

「お客様の自己解決を促すため、サポートサイトの構築に力を入れているが、電話やメールがなかなか減らない」

このような悩みを持つ方に向けて、サポートサイトの改善方法について事例を交えながら解説していきます。

• どんなデータを集めればいいか
• 集めたデータをどう活かせばいいか
• どのような施策を打てばいいか

といったことをまとめていますので、ぜひ最後までご覧ください。

サポートサイト改善のためのデータのまとめ方

サポートサイトでお客様の自己解決を促すためには、お客様のサイト行動を把握することが重要です。サイト行動が掴めれば、お客様が「サイト内のどこでつまずいているか」がわかり、「なぜつまずいているか」を予測しながら改善策を考えられます。

では、どのようにサイト行動を把握すれば良いか？

サイト行動を把握するために集めるデータはいろいろありますが、経験上は次のようなデータをそろえていることが多いです。

• 遷移先
• 対象ページ
• アクセス日
• ユーザーID
• リファラURL
• 滞在時間
• デバイス
• ブラウザ

これらのデータをまとめたものが以下の表です。

お客様のサイト行動とハイレベルマップを組み合わせることで、「お客様がサポートサイトのどこでつまずきやすいか」が可視化されます。

ハイレベルサイトマップは、目的に合わせて特定のページ群だけを可視化させたサイトマップのことです。お客様がサイト内をどのように回遊しているかを把握するのに役立ちます。

ハイレベルサイトマップの概要や作り方は下記記事で解説していますので、合わせてご覧ください。

>>お客様の自己解決を促す、サポートサイトの改善点を見つける方法

まとめたデータをサイト改善につなげる方法と事例

まとめたデータをサイト改善につなげるために着目したいのが「対象ページ」と「滞在時間」です。

問い合わせに遷移しているユーザーの対象ページと滞在時間を見て、仮説（どのような課題があるか）を考えていきます。

ここからは、「お客様のサイト行動を分析し、サポートサイトの改善につなげた3つの事例」を紹介していきます。

サイトの改善事例1：カテゴリーページでの滞在時間が短い

1つ目にご紹介する事例は、「カテゴリーページの滞在時間が極端に短いユーザーが、カテゴリーページから問い合わせていた」ケースです。

カテゴリーページとは、お客様の疑問の解決方法が書かれた記事へ誘導するために、FAQの一覧を載せているページのこと。カテゴリーページの滞在時間が短いということは、お客様がFAQ一覧から記事を探すことなく問い合わせていると考えられます。

では、なぜお客様は記事を探さずに問い合わせへと流れているのか？

このときの原因は「カテゴリーページの情報の並べ方や見せ方が悪かったこと」でした。ページいっぱいに文字だけが並んでいると、その中から自分が探している情報を探すのは大変ですよね。

ユーザー目線に立つと、カテゴリーページに並んでいる記事タイトルの一覧から、目的の情報を探すのは負担になっているはずです。カテゴリーページを見た瞬間に「情報を探すのは面倒だから電話しよう」と思うお客様がいてもおかしくありません。

改善策：情報を探してもらう構造から情報を選んでもらう構造へ変える

解決方法として「情報を探させる構造から情報を選ばせる構造にすればいいのでは？」という仮説を立てました。読みながら探してもらうのではなく、読まずに選べるようなUIに変更するということです。

この仮説をもとにして、「カテゴリーページをパネル形式に変更した」ところ、お客様が疑問の解決方法が書かれた記事にたどり着けるようになり、自己解決の促進に成功しました。

サイトの改善事例2：記事の滞在時間が短い

2つ目にご紹介する事例は、「カテゴリーページから情報が書かれた記事にアクセスしているものの、記事の滞在時間が極端に短い」ケースです。

記事を読んでもらえていないため、「記事の内容」に改善の余地があると想定できます。例えば、文字がずらっと並んでいると、パッと見たときに読みたいと思えません。

改善策：記事を読んでもらえるよう視認性を上げる

そこで、お客様が記事を読もうと思えるよう「タイトルを大きな文字で見やすくする」「文字の装飾をして視認性を上げる」といった改善策を実施しました。

また、一問一答形式で情報を提示することで、記事に訪問したお客様が疑問の解決方法を簡単に把握できるようになりました。

ちなみに、記事がきちんと読まれているかを判断するために、「各記事を読むのにどのくらいの時間がかかるか？」を把握しておくことも必要です。その時間を基準として、お客様の滞在時間が極端に短い場合、読み終えてないのに離脱（次のページに遷移）していると判断できます。

サイトの改善事例3：記事の滞在時間が長い

3つ目の事例は、「記事の滞在時間が長いお客様が問い合わせている」場合です。

このようなお客様は、記事をしっかりと読んだものの、疑問が解決されなかったため問い合わせていると想定されます。

なぜ、記事を読んでもお客様の疑問が解消されなかったのか？

その原因は3つありました。

• お客様が求めている情報が書かれていない
• 内容が難しくてお客様が理解できない
• どこに疑問の解決方法が書かれているかわからない

改善策1：「どう行動すればいいか」を最初に提示する

当たり前ですが、記事の中にお客様が求めている情報が書かれていなければ、お客様の疑問は解消されません。しかし、「読んだうえで、どう行動すればいいかがわからない」というケースは意外に多いものです。

記事を読んだ上で「結局どうすればいいの？」という状態になったお客様は、電話やメールで問い合わせることになります。

そこで、問い合わせにつながっている記事は「問題の解決方法がわかりにくいのではないか？」という仮説を立てました。そして、「まずはどう行動すれば良いかを提示し、そのあとに詳細を書く」という構成に変更することで、お客様の自己解決を促せるようになりました。

改善策2：誰でも理解できる表現に直す

お客様が求めている情報が書かれていても、記事の内容が難しいとお客様は十分に理解できず、問い合わせへとつながってしまいます。

「これくらいはわかるだろう」と思っている用語でも、実際は多くの人が理解できないというケースは少なくありません。専門用語は噛み砕いて表現し、事前情報がない人でも理解できる文章に直す必要があります。

今回の事例では、新入社員に記事を読んでもらい、難しい単語や表現をピックアップしてもらいました。このように、専門知識をそれほど身につけていない人（＝お客様と知識量が近い人）に記事を読んでもらうことで、お客様が理解しにくい部分を把握できます。

改善策3：1記事あたりの情報量を調整する

書いてある内容そのものは簡単でも、記事内の情報量が多いため、「疑問の解消方法が書いてある場所を見つけられない」「途中で読むのをやめてしまい自己解決に至らない」という記事もありました。

1記事当たりの情報量が多いと、お客様はその中から自分の疑問の解決方法を探さなければいけません。

そこで、情報量が多い記事は、情報を複数記事に分けました。

1記事につき1つの情報を一問一答形式で掲載し、カテゴリーページにてわかりやすく案内することで、お客様は自分が求めている情報へスムーズにたどり着けるようになりました。

おわりに

サポートサイトの改善のために必要なデータや、データの活用方法をご紹介してきました。次回は「Webサポートを設計するために必要なKBOツリー作成」について解説していきます。

「お客様が必要としているWebサポートを実施しているつもりだが、思うような効果が感じられない」

このような状況を脱却する手段のひとつとして「KBOツリー作成のワークショップ」が挙げられます。

KBOツリーとは、目標を達成するために"やるべきこと"を体系化したものです。ゴールを定めたうえで、そのゴールに向けてやるべきことを考えることで、本当に必要なアクションが明確になります。

ワークショップ形式でKBOツリーを作成することで、チーム全体で目線を合わせて目標達成に向けて動けるようになるのです。

そこで今回は、KBOツリーとは何かを説明しつつ、「KBOツリー作成のワークショップ」の進め方をご紹介します。

KBOツリーとは？

KBO（Key Business Objectives）とは、あるゴールに向けた具体的なアクションのことです。ゴールに向けてやるべきことを落とし込み、つなぎ合わせたものをKBOツリーと呼びます。

KBOツリーを作成することで、ゴールのためにどんなアクションが必要かを具体的・体系的に把握できます。

では、KBOツリーはどのように作れば良いか？

KBOツリー作成はさまざまな方法があり、中でもおすすめなのがワークショップです。

ワークショップを開くことで、メンバー全員の目線を合わせ、ゴールに向けて行動できるようになります。また、同じ商品・サービスでも、お客様によって必要なサポートは違うものです。そのため、複数人で意見を出し合うことで、さまざまな視点を持つお客様の立場になりきって「どんなWebサポートが必要か」を考えられます。

ワークショップ成功の鍵を握るファシリテーターの選び方

ワークショップの進め方の前に、成功の鍵を握る「ファシリテーターの選び方」をご紹介します。

ファシリテーターとは、ワークショップの進行を務める人のことです。ワークショップのファシリテーターは、テーマに関する領域に詳しくない人の方が向いています。

それはなぜか？

経験上、ワークショップのテーマについて詳しい人ほど、自分なりの意見を持っていることが多い傾向にあります。そんな人がファシリテーターを務めると、参加者の意見を無自覚に自分の思う意見に誘導してしまうかもしれません。

しかも、詳しい分「合理的で、まともな意見」を持っていることがほとんどです。すると、そのファシリテーターが思うまともな意見を元にスムーズに議論が進みすぎるため、まだ発見できていない新しい考えや課題を見落とす可能性があります。それだと、ワークショップ形式でKBOツリーを作成する意味が薄れます。

言い換えると、ファシリテーターに向いているのは「中立的な立場の人」です。

社内であれば違う部署の人を選びましょう。Webサポートをテーマにワークショップを開くなら、CXのマーケティングを担当している社員にお願いするという具合です。

他部署の人にファシリテーターをお願いする際は、必ず相手のメリットも伝えましょう。

KBOツリーはサポート領域にしか使えないものではありません。なので、自分の部署のファシリテーターをお願いする代わりに、相手の部署のKBOツリー作成のファシリテーターを担当することを提案するのがおすすめです。そうすることで、お互いの目標を共有できますし、それぞれの目標達成に向けて協力し合えることが見つかれば、Win-Winの関係が築けます。

また、予算があれば外注するのも選択肢のひとつです。

過去にファシリテーターを外注したときは、ワークショップがスムーズに進んだうえ、さまざまな視点の意見が出てきました。ファシリテーターがテーマに詳しすぎないからこそ、参加者の意見に対して「これってどういうこと？」と、一つ一つの意見を深堀りできるというメリットもあります。

KBOツリー作成のワークショップ

KBOツリー作成のワークショップの目的は、目標であるKGI（Key Goal Indicator）に向けての具体的なアクションを可視化することです。

メンバー全員が腹落ちした状態で動けるよう目線を合わせ、「アクションを何のためにやるか」「そのアクションが何に効くか」を、ベテラン社員も新入社員も説明できる状態を目指します。

KBOツリーの作成手順

今回は「Webサポートでのサポートコストを削減する」というKGIを設定したときのKBOツリー作成の例をご紹介します。

まずは、KGIである「Webサポートでのサポートコスト削減」に向けて、どのようなアクションが必要になりそうかを考えていきます。

このときは、「実現可能か」「本当に有効か」などは考えず、とにかく意見を出していくことが重要です。また、KBO（概念的な分解要素）ではなく、具体的なアクションが混ざっていても構いません。参加者が意見を出すハードルを低くし、全員が発言できる雰囲気でワークショップを進めていきましょう。

意見を一通り出し終えたら、それぞれの意見が「KBOか」「具体的なアクションか」を話し合いグルーピングしていきます。また、必要ないと判断したアクションは除外していきます。

今回の例では、「サポートが必要なお客様のサポートサイト利用率を向上させる」「サポートサイトでの自己解決率を上げる」と言う2つの大きなアクションに分けました。

ここまで来たら、大きなアクションの下に具体的なアクションが続くよう並び替え、ツリーを作成していきます。KBOを考えているときに具体的なアクションが出てきたら、KBOツリーの完成後に検討できるようメモしておきましょう。

これでKBOツリーは完成です。

KBOツリーの活用方法

KBOツリーが完成すると、KGI達成に向けた具体的なアクションが明確になります。しかし、この段階ではゴールに向けた道筋を可視化しただけです。

KBOツリーを作成したあとは「アクションの達成状況を確かめるためのKPI」や「具体的な施策」を定める必要があります。

KPIや具体的なアクションについては、次回以降の記事で順にご紹介していきます。

おわりに

Webサポート設計に欠かせないKBOツリーの作り方をご紹介しました。メンバー全員が同じ目的意識を持って行動できるよう、ぜひワークショップを開いてKBOを作成してみてください。次回は「サポートサイトにおけるKPI設定の落とし穴」についてご紹介する予定です。

サポートサイトに限らず、目標を達成するためには「現状、どうなっているか」を把握する必要があります。そのために、目標に対してどれくらい進んでいるかを数値化したものが「KPI（Key Performance Indicator）」です。

しかし、このKPI設定に失敗すると、「KPIは達成しているものの、目標が達成されない」という状態になりかねません。

そこで本記事では、「サポートサイトにおけるKPI設定のよくある失敗例」をご紹介しつつ、KPIをどのように設定すればいいかを解説していきます。

KPI設定の前にやっておきたいKBOツリー作成

チームでKPIを設定する前には、KBOツリーを作成しておくことがおすすめです。

KBO（Key Business Objectives）とは、ゴールに向けたアクションのことを指します。

KBOをツリーにして可視化し、それぞれのKBOに対してのKPIを考えていくことで、目標達成に必要なKPIを漏れなく設定できます。

KBOツリーの作成方法については、下記記事で紹介していますので、ぜひご覧ください。
 >>vol.10 Webサポート設計に欠かせないKBOツリー作りのイロハ

サポートサイトにおけるKPI設定のよくある2つのミス

サポートサイトにおけるKPI設定には、よくある失敗があります。今回は、実際にあった事例と対策を交えて、2つの失敗例をご紹介していきます。

• 1つの指標だけで目標達成度を見ようとしている
• 目標達成に対して、ズレたKPIを設定している

1つの指標だけで目標達成度を見ようとしている

KPIを設定する際に、1つの指標だけで目標の達成度を見ようとしているケースがよくあります。

例えば、「サポートサイトでの自己解決率を上げる」というKBOに対して、「FAQ記事を評価してもらうgood/badボタンの集計結果」だけをKPIとして設定しているというものです。

FAQ記事への評価は、サポートサイトのKPIとしてよく使われます。しかし、あくまでも「自己解決率を測る指標のひとつ」です。

良い評価が多いからといって、サポートサイトで自己解決できたお客様が多いとは限りません。

例えば、

• 問題が解決したけどリアクションしていない
• 解決策が見つかったと思いgoodを押したが、実際は問題が解決できず電話で問い合わせている

このような人が多くいるかもしれないため、FAQ記事への評価は、実際の自己解決率と一致しない可能性が高いと考えられます。

他にも、何か1つだけの指標を見て、自己解決率を測ろうとするケースはよくあります。

以前、「サポートサイトの記事ページからの離脱率だけをKPIに設定していた」という事例がありました。

サポートサイトを読んで問い合わせをせずに離脱している人は、自己解決できていると判断していたのです。

確かに、「記事を読んで問題が解決したから、問い合わせをせずに離脱した」と考えることもできます。

しかし、サイレントカスタマーを考慮していないため、離脱率だけではサポートサイトでの自己解決率を評価できません。

サイレントカスタマーとは、「FAQを読んだもののよくわからないし、わざわざ問い合わせるのも面倒。なので、購入をやめる・解約する。」といった、「何も言わずに去ってしまう人」です。

サイレントカスタマーは実数を把握するのが困難なうえ、意外にも多くいるものです。

このように、1つの指標だけで目標の達成度合いを測定するのは無理があります。厳しい言い方をすると「一部しか見ていないのに、全体を見た気になっている」だけです。

では、どのようにKPIを設定すればいいか？

KPIを設定する際は、1つのアクションに対して複数の指標を用意しましょう。

例えば、「サポートサイトでの自己解決率を上げる」というKBOに対するKPIを考えるなら、「FAQ記事への評価」や「離脱率」に加えて、「読了率」「滞在時間」などがKPIの候補となります。

目標達成に対して、ズレたKPIを設定している

設定したKPIがズレているケースもよく目にします。

以前、「サポートサイトに訪問してもらう」という目標に対して、「SEOでの流入数」をKPIに設定していたことがありました。

問題ないと感じるかもしれませんが、「サポートサイトへの訪問」のためにSEOでの流入を狙う。そのために「SEOで上位に上がるためのライティング・施策を必死に頑張る」のはナンセンスです。

それはなぜか？

サポートサイトは「検索で調べないと解決策がわからない状態」ではなく、「問題が発生したときに、メルマガに記載したURLや紙資材に載せたQRコードなどから、サポートサイトのFAQに直接訪問してもらえるような状態」を目指すべきだからです。

「困った人が困ったタイミングで、すぐに問題を解決できる」というのがサポートサイトの理想ですよね。そのためには、「困ったときにサポートサイトへ直接アクセスしてもらうための施策」が重要だと思いませんか？少なくとも、一生懸命SEOで上位に行くためのライティングを頑張ることではないと思います。

このように、KPIを設定する際は、目標を達成するためにどんな施策を優先的に進めるかを考える必要があります。

今回の事例では、「既存会員のサポートサイト来訪数」や「問い合わせユーザーのWeb利用数」といったKPIを設定し、新たに施策を考え直しました。

そもそも、KPIはどのように考えればいいか？

KPIはKBOを分解しながら考えるのがおすすめです。

具体的なKPIの設定は、経験や知識がないと難しいものです。また、KPIを運用する際は、「木を見て森を見て、また木を見る」のように、個別のKPIと全体の目標達成度合いをバランスよく見る必要があります。

KPIの設定・運用を失敗しないためには、マーケティングの担当者など、社内に経験や知識がある人にアドバイスをもらいながら進めていきましょう。

もし社内に経験者がいない場合は、問い合わせいただけたら無料で相談に乗ることも可能です。

>>https://rightsupport.karte.io/#form

おわりに

KPI設定のよくある失敗例をご紹介してきました。次回は、「具体的な施策の考え方」について、具体例を挙げながらご紹介していく予定です。

サポートサイトでお客様の自己解決を促すためには、どのような施策を実行すれば良いか？

本記事では、事例を交えながら、サポートサイトの目標達成に向けた具体的な施策の考え方をご紹介します。

「KBOやKPIは決まったものの、具体的な施策が思いつかない」

「施策を試しているものの、目標達成に近づかない」

このような問題に直面するケースは珍しくありません。施策が思いつかなかったときの対処法や、よくある失敗例もまとめていますので、ぜひ最後までご覧ください。

具体的な施策を考える2つの方法

さっそく、サポートサイトの目標達成に向けた施策の考え方をご紹介いたします。

施策は大きく2つのパターンで決めていきます。

• KBOツリー作成で出てきた施策を整理する
• 新たに施策を考える

どちらもKBOツリーがあることを前提に話を進めていますので、「KBOツリーって何？」という方は、下記記事も合わせてご覧ください。
>>vol.10 Webサポート設計に欠かせないKBOツリー作りのイロハ

KBOツリー作成で出てきた施策を整理する

まずは、「KBOツリー作成のときに" ついでに " 出てきた施策案」を整理していきます

KBOツリーとは、目標達成のためにどのようなKBO（アクション）が必要かを可視化したもののことです。KBOを考えていると具体的な施策も思いつくことがあり、メモとして残しておくことで施策を考えるときのアイデアとなります。

メモとして残しておいた施策案について、どのKBO・KPIに結びつけられるか整理していきます。

整理の際は、「この施策を実施すると何に影響するか」を考えながらKBO・KPIにつなげてツリーになるよう記載していきます。

例えば、メモにある「サポートサイトへの動線を増やす」という施策を実施した場合、サポートサイトに訪れる人が増えそうだと予想できますよね。この予想に該当する「サポートサイトに訪問してもらう」というKBOや「既存会員のサポートサイト来訪数」というKPIを達成するための施策として結びつけます。

このように、メモに残していた施策案を1つずつKBO・KPIに結びつけていきます。

実際に施策を実施してKBOやKPIが達成されるかは試してみないとわからないことが多いため、まずは「このKBO・KPIに効きそう」という予想ベースで考えていきましょう。

新たに施策を考える

新たに施策を考える場合、「末端のKBO・KPIを達成するためにはどんな施策が考えられるか」という軸で思いつくものを書き出していきます。

具体的な施策例として、「コンテンツを読んで問題を解決してもらう」というKBOに対する施策の考え方をご紹介します。

このときに考えたいのは、「お客様はなぜ記事を読んでも問題を解決できないのか？」という原因です。

KBOが達成されない原因を考えたあとは、その原因を解消するためにはどうすればいいかを考えていきます。

どうしても施策が思いつかない場合には、他社がどのような施策に取り組んでいるかをリサーチしてみましょう。詳しくはこのあと紹介していきます。

過去の事例では、以下のような施策を実行することに決めました。

• わかりやすい表現、文言に変える
• 記事の冒頭に要約を追加する（問題の解決方法を端的にまとめる）

サポートサイトはさまざまなお客様が読むものです。製品やサービスに詳しい人だけでなく、初めてその製品・サービスを利用する人も多くいるはずですよね。すべてのお客様が記事を読んで問題を解決するためには、難しい表現や専門用語をわかりやすい言葉に変えることが必要です。

また、しっかり読まないと解決方法がわからない状態では、「読むのが面倒だから電話で問い合わせよう」と思うお客様がいてもおかしくありません。このようなお客様にも問題を自己解決してもらうためには、ページを開いた瞬間に問題の解決方法がわかるようなUIに変更することも重要です。

このような流れで残りのKBOに対する施策も考えていき、次のようなツリーが完成しました。

あくまで一例ですので、すべてのサポートサイトが同じ施策で目標を達成できるわけではありません。とはいえ、ツリー構造で考えていく方法はどのサポートサイトでも活用できるので、ぜひお試しください。

具体的な施策を考えるコツ

具体的な施策を考えるコツは、あまり難しく考えないことです。

長い時間をかけて施策を考えても、思い通りの効果が出るとは限りません。施策の効果がどの程度あるかは、試してみないとわからないものが多いと感じます。

そのため、まずは「こういう施策が良いのでは？」というアイデア・思いつきベースで考えていきましょう。施策を出せるだけ出して、そのあとに優先度を考えていきます。

施策の優先度を決めるためには、KBOツリーだけでなくカスタマージャーニーマップも必要です。カスタマージャーニーマップや施策の優先度の決め方は、今後紹介します。

施策が何も思いつかないときはどうする？

施策を考えているときに、案が何も出てこないこともあると思います。また、施策案は思いつくものの、どれもピンとこないケースもあるでしょう。

そのようなときは、他社で何をやっているかを調べて参考にするのがおすすめです。Webサイトやマーケ系の施策、お楽しみ系の施策をリサーチし、自社の目的達成のために応用できないか考えてみます。

例えば、会員同士で疑問を解決し合うコミュニティや、ゲーム感覚でサービスの使い方が身につくコンテンツなど、そのまま自社で採用できなくてもアイデアの元になる可能性はあります。

また、デジタルマーケティングの担当者など、Web系の施策に取り組んだことのある経験者に相談してみるのもひとつの手段です。

「他社をリサーチしても思いつかない」「社内に経験者がいない」といった場合は、問い合わせいただけたら無料で相談に乗ることも可能です。

>>https://rightsupport.karte.io/#form

施策を考える際のよくある2つの失敗例

施策を考えるときに、よくやってしまいがちな失敗例が2つあります。

• 1つの施策を複数のKBO・KPIに結びつけてしまう
• 工数やお金がかかりすぎる、壮大な施策を優先してしまう

1つの施策を複数のKBOやKPIに結びつけてしまう

まず紹介する失敗例は、「1つの施策を、複数のKBO・KPIに結びつけてしまう」というものです。

施策の中には複数の要素に影響するものも少なくありません。しかし、1つの施策を複数のKBO・KPIに結びつけると、1つのKBO・KPIは達成されるものの、もう一方のKBO・KPIは達成に遠ざかってしまうことがあります。

以前、「サポートサイトへの動線を増やす」という施策を、「サポートサイトに訪問してもらう」「コンテンツを読んで自己解決してもらう」という2つのKBOに結びつけていたことがありました。

サポートサイトへの動線を増やすことで、サポートサイトに訪問する人が増えそうですし、その結果、コンテンツを読んで自己解決できる人も増えそうですよね。

実際に、動線を増やすことでサポートサイトのPVが増え、「サポートサイトに訪問してもらう」というKBOは達成しました。

一方で、「コンテンツを読んで自己解決してもらう」というKBOは達成できないどころか、KPIのひとつに設定していた「記事の読了率」や「滞在時間」が設定した数値から遠ざかってしまったのです。

その理由は、サポートサイトへの動線を増やしたことで、問題を抱えていないのに訪問する人も多く訪れたためでした。

このように、1つの施策を複数のKBOに結びつけることで、どちらかのKBOは達成されるものの、もう一方のKBOは達成に遠ざかってしまうケースはよくあります。

ではどうすれば良かったか？

施策が複数のKBO・KPIに影響しそうなら、どちらがより効きそうかを考え、より効きそうな KOB・KPIにだけ結びつけるのがおすすめです。

今回の事例では、「サポートサイトへの動線を増やす」という施策は、「サポートサイトに訪問してもらう」というKBOにだけ結びつけました。そのうえで、「コンテンツを読んで自己解決してもらう」というKBOに対しては、「コンテンツの内容のブラッシュアップ」や「UIを整える」といった施策を新たに考えました。

その結果、サポートサイトの訪問者を増やせたうえ、記事を読んだお客様の解決率も向上し、2つのKBOが達成できました。

工数やお金がかかりすぎる、壮大な施策を優先してしまう

施策を決める際に、「工数やお金がかかりすぎる、壮大な施策を優先してしまう」という失敗例もよくあります。

施策決めの際に忘れてはいけないのは、「施策を通してKGI（最終目標）を達成することが最も大切」ということです。サポートサイトにおいて、何か1つの施策だけを取り組んでいれば、KGIが達成できるわけではありません。

サポートサイトのUIやコンテンツ作りに力を入れても、集客できなければコンテンツを読んでもらえませんし、集客だけに力を入れてもコンテンツがわかりにくければ、サイトに訪問したお客様は疑問を解決できませんよね。

大切なのは、各施策をバランスよく実行していくことです。

経験上、1つの大きな施策だけを進めるのではなく、さまざまな施策をバランスよく進めたほうが、目標達成には近づきやすいです。

おわりに

今回はサポートサイトの具体的な施策の考え方を、事例を交えて紹介しました。次回は、カスタマージャーニーマップについてご紹介していく予定です。

自社の製品やサービスを利用するお客様に対して、「どのタイミングでどのようなサポートが必要なのか」を把握できていますか？

適切なタイミングで適切なサポートができれば、お客様は疑問を解決する方法を探したり、問い合わせたりする必要がありません。

では、どのようにして「どのタイミングでどのようなサポートが必要なのか」を把握すればいよいか？

その方法のひとつとして「カスタマージャーニーマップ作り」が挙げられます。

本記事では、カスタマージャーニーマップとは何かを説明したあとに、カスタマージャーニーマップの作り方をご紹介します。

カスタマージャーニーマップとは？

カスタマージャーニーマップ（CJM：Customer Journey Map）とは、お客様が商品やサービスを知ってから、その商品やサービスを利用するまでの体験や感情を時系列に沿って可視化したものです。

参考：カスタマージャーニーに沿った施策を生み出すには｜KARTE | CX（顧客体験）プラットフォーム KARTE

カスタマージャーニーマップを作ることで、お客様が自社の商品・サービスと接したときの行動や感情がわかります。そのため、お客様がマイナスな感情を持つタイミング、つまり「改善やサポートが必要なタイミング」を把握できるのです。

また、カスタマージャーニーマップと問い合わせデータをかけ合わせることで、「どのタイミングで何に困っている人が特に多いか」も見えてきます。詳しくは、このあと事例を交えながら解説していきます。

カスタマージャーニーマップ作りはワークショップ形式がおすすめ

カスタマージャーニーマップは、ワークショップ形式で作るのがおすすめです。

同じ商品・サービスでも、お客様によって必要なサポートは違いますよね。1人でカスタマージャーニーマップを作る場合、さまざまな視点を持つお客様の立場で行動や感情を考えるのは難しいものです。ワークショップなら、複数人で意見を出し合えるため、おのずといろいろな角度からお客様の行動や感情を考えられます。

そのうえ、ワークショップを開くことで、「メンバー全員の目線を合わせ、ゴールに向けて行動できるようになる」というメリットもあります。

ワークショップでカスタマージャーニーマップを作るときの注意点

サポートサイト改善のためにカスタマージャーニーマップを作成する際は、「サイトの設計者」にもワークショップに参加してもらいましょう。

サイトの設計者不在でお客様との接点を書き出すと、お客様と自社商品・サービスとの実際の接点とズレてしまうことがあるためです。

ただし、サイト設計者に参加してもらうと、「サイトの見直したほうがいい点」を指摘しにくくなるというデメリットもあります。特に、サイト設計者より立場の弱い社員は、上長かつサイトを作った本人がいる場で、改善点を指摘するのは勇気がいるものです。

しかし、忖度していては自社の課題を改善できないため、正直な意見を出すことをワークショップのルールとして参加者に周知しておくことも大切です。

サイト設計者には事前に厳しい意見を言うこともあると伝えておきつつ、「当時は正解だったけど、今は状況が変わったから変えた方がいい」のようなフォローをしながらワークショップを進めていきましょう。

カスタマージャーニーマップ作りのワークショップの進め方

カスタマージャーニーマップ作りのワークショップでは、お客様になりきって自社の商品やサービスを体験していきます。

ワークショップの進め方は以下の通りです。

手順だけではわかりにくいと思うので、具体例で解説します。今回の例は「インテリアECサイト」です。

1.ペルソナを設定する

まずは、実際のお客様になりきるために、ペルソナを設定します。

ペルソナとは、自社の商品やサービスを使うユーザー像のことです。年代や性別、職業、家族構成など、どのような人が自社の商品やサービスを使っているかを表しています。

このペルソナがズレた状態でカスタマージャーニーマップを作ってしまうと、実際のお客様がサポートを必要としているタイミングと、カスタマージャーニーマップ上でサポートが必要であろうポイントがズレかねません。

極端な例ですが、普段からネットショッピングを利用する若年層と、初めてECサイトで買い物をするご高齢の男性では、つまずくポイントが変わりそうですよね？慣れている人なら何事もなく会員登録できても、初めての人だと会員登録でつまずいてしまうかもしれません。

自社がターゲットとしているお客様がサポートを必要とするポイントを把握するには、実際に自社の商品・サービスを使う人になりきってカスタマージャーニーマップを作る必要があります。

ペルソナを設定する際のコツは、実際にターゲットとしているメインユーザーを思い浮かべることです。理想は実際のユーザーに取材しながらペルソナを作ることですが、できなければ営業担当やベテランのCSなどお客様に詳しい人へヒアリングをしてみましょう。

ペルソナを設定したら、その人格になりきって商品・サービスを体験していきます。

2.お客様の行動を洗い出し、商品・サービスとお客様との接点を書き出す

ペルソナが設定できたら、自社の商品とお客様との接点を書き出します。

具体的には、

• どのように商品やサービスを知るか
• どのように商品やサービスを検討するか
• 商品やサービスの購入前にどのような行動をとるか
• 商品やサービスの購入後にどのような行動をとるか

といったことを考えていきます。

まずは考えられるすべての行動や接点を洗い出し、その中からペルソナにあったものを整理していくのがおすすめです。

例えば、商品やサービスを知るきっかけは、SNSやテレビ、雑誌、店頭、友人・知人からの紹介などさまざまあります。その中で、「暇な時間はSNSを見ていることが多い20代女性」をペルソナとして設定しているなら「Instagramの投稿や広告で知る人が多そう」のように、ペルソナの行動を想像しながら考えていきましょう。

3.お客様になりきって体験してみる

次に、お客様になりきって「商品・サービスを知るところ」から「実際に購入して使うところ」まで通して体験してみます。

このときのポイントは「初めてその商品やサービスに接するお客様になりきること」です。

ワークショップの参加者は、自社の商品やサービスの特徴や他社商品との違いを把握しているはずですよね。その状態で体験してみても、初めて商品やサービスに触れる人が疑問に思う点に気付けない可能性があります。

完全にお客様になりきるのは難しいですが、意識するだけで本当のお客様にとって負となるポイントに気付きやすくなるものです。

4.時系列で商品・サービスと接したときに感じたことを可視化する

実際に体験したあとは、時系列で商品・サービスと接したときに感じたことを可視化します。

このときは、

• わかりにくかったところ
• イライラした/不安を感じたなどの感情
• 商品やサービスに魅力を感じたところ

といった「心の動き」を細かく観察しながら、言葉にして表現していくのがコツです。

具体的な心の動きを言語化するのが難しい場合は、「ポジティブとネガティブのどちらの感情になったか」を可視化しましょう。

5.データを見て、実際のお客様の行動と照らし合わせる

この時点で、お客様がサポートを必要とするタイミングが見えてきますが、あくまでも体験しているのは社員です。実際のお客様の心の動きと同じではないかもしれません。

どんなにお客様になりきっても、商品やサービスについての事前知識を持っている社員が、初めて商品・サービスに接する人と完全に同じ感覚で体験するのは困難です。

そこで、データを見て「実際のお客様の行動と照らし合わせる作業」が必要になります。数字を見て「やっぱり同じようなことを思っているお客様が多そうだね」というように、体験して感じたこととデータをすり合わせていきます。

情報がそろっていない場合は、最低でも直近1ヶ月の購入者や入会者の情報を準備しておくのがおすすめです。

分析に必要なデータについては、下記記事で紹介していますので、合わせてご覧ください。
>>vol.09 サポートサイト改善はじめの一歩【情報を探す構造から情報を選べる構造へ】

ちなみに、最初にデータを見てから商品・サービスを体験するのは、あまりおすすめしません。先にデータを見てしまうと、問い合わせが多いポイントばかりに気が向いてしまい、他のわかりにくいポイントを見過ごしてしまう恐れがあるためです。

初めて商品・サービスを利用する人になりきるためには、できるだけ情報を知らない状態で体験するのがおすすめです。

6.お客様がマイナスの感情になるポイントの原因や改善点を探す

お客様になりきって体験しデータと照らし合わせたあとは、各感情の要因を掘り、マイナスな感情が生まれたポイントの改善点を考えます。

例えば、

• 商品の使用例を紹介する画像を増やした方が、商品を使うイメージが湧きやすそう
• 送料について商品ページで詳しく記載した方が、購入へスムーズに進みそう

という具合です。

「こういう説明やサポートがあったら、マイナスの感情にはならなかったよね」と話し合いながら、どのようなサポートが必要なのかを考えていきましょう。

これでカスタマージャーニーマップのワークショップは終了です。

カスタマージャーニーマップの作成後は、実際に施策に取り組むために、施策の優先順位をつけていきます。優先順位のつけ方は次回の記事でご紹介します。

おわりに

今回は、カスタマージャーニーマップの作り方をご紹介しました。次回は、作成したカスタマージャーニーマップを使って施策の優先順位を決める方法をご紹介する予定です。

「サポートサイトの目標達成のために施策案を考えたが、どの施策から手をつければいいか決められない」

すべての施策案を同時に進められればいいですが、人手も時間も限られている中では、優先順位を決める必要がありますよね。

では、どのようにして施策の優先順位を決めれば良いか？

施策の優先順位決めにおすすめなのが、KBOツリーとカスタマージャーニーマップを活用する方法です。

今回は、KBOツリーとカスタマージャーニーマップの2つを使った施策の優先順の決め方をご紹介します。具体的な事例を交えて紹介していますので、参考にしていただければ幸いです。

施策の優先順位決めにはKBOツリーとカスタマージャーニーマップの2つを使うのが理想

施策の優先順位を決める際は、KBOツリーとカスタマージャーニーマップの両方を活用するのが理想です。

それはなぜか？

KBOツリーとカスタマージャーニーマップを使うことで、「チームとして取り組みたい課題」と「お客様にとって負となるポイント」をかけ合わせながら優先順位を決められるためです。

KBOツリーを見ることで「チームとして取り組みたい施策案」を網羅的に把握できます。しかし、「お客様がどの施策を求めているか」がわかりません。なぜなら、KBOツリーは事業の目標を達成するための施策を可視化したもので、お客様目線で考えたものではないためです。

KBOツリーだけを使って施策の優先順位を決めると、お客様が本当に必要としているサポートを後回しにしてしまう恐れがあります。

一方で、カスタマージャーニーマップを見ることで「お客様のつまずくポイント」を把握できますが、事業として取り組みたい施策はわかりません。そのため、お客様目線だけで施策を進めてしまい、事業として取り組むべき施策を後回しにしてしまう可能性があります。

極端な例ですが、カスタマージャーニーマップだけを見て施策の優先順位を決めると、お客様は喜ぶものの事業が続かないなんてことになりかねません。

KBOツリーやカスタマージャーニーマップを使って施策に取り組んだ事例

実際に、KBOツリーとカスタマージャーニーマップを使って施策に取り組んだ事例として、大型家電を扱うECサイトの例をご紹介します。

まずはKBOツリーを見ていきます。すると「サポートサイトにきてくれない」という課題がありました。サポートサイトに訪れず、電話で問い合わせているお客様が多くいたのです。

そこで、カスタマージャーニーマップを見て、問い合わせが発生しそうなポイントを探していきます。

すると、「エアコンの購入後に、取り付け工事の日程ついて気になる人が多そう」という仮説が立てられました。

実際に問い合わせ履歴を見てすり合わせると、会員登録をした直後にエアコンを購入しているお客様から「取り付け工事に関する問い合わせ」が多いことがわかりました。

サポートサイトの案内は、入会したお客様へ送っている紙の資料に載せています。しかし、その資料が届くまでに入会から1週間ほどかかるため、会員登録直後に商品を購入したお客様へはサポートサイトの案内が届いていなかったのです。これでは、電話やメールでの問い合わせが多く寄せられてしまいます。

では、入会直後にエアコンを購入したお客様にサポートサイトを使ってもらうには、どのような施策が必要なのでしょうか？

ここで、KBOツリーの施策案の中から、課題を解決できそうな施策がないか探してみます。

今回の事例では「入会後に送るメールで、サポートサイトを紹介する」という施策を採用しました。

加えて、「マイページで取り付け工事の日程がわかると便利そう」という案も出てきました。

マイページで工事の日程がわかるようにしておけば、お客様はサポートサイトに訪れるよりも簡単に工事の日程を把握できるはずです。そのうえで、商品の購入後に送るメールに、マイページで取り付け工事の日程がわかることを記載すれば、工事日程の確認方法を共有できます。

このように、KBOツリーとカスタマージャーニーマップを使うことで、お客様の困りごとを解決でき、事業として優先したい施策を優先的に進められるようになりました。

施策の優先順位を決めるポイント

施策の優先順位はどのように決めるのが理想なのか？

最も優先したいのは「お客様の不便を解決できる施策」です。続いて「チームの課題を解決できる施策」に取り組むのが理想です。（事業計画上の都合などで優先すべき指標があり、その施策を優先しなければいけない場合もありますが......）

当たり前のように思うかもしれませんが、お客様よりもチームの課題を優先してしまっているケースもあります。

例えば、サポートサイトの自己解決率を上げるために、「検索機能の強化」をチームの目標に設定しているとします。しかし、お客様が「検索機能の使いにくさ」よりも「サポートサイトのUIのわかりにくさ」に不満を持っている場合、検索機能を強化しても、UIが悪いため検索機能を使う前に離脱してしまうかもしれません。

お客様の自己解決を促すためには、お客様目線で必要な施策を優先することが大切です。

「お客様にとって不便になっているポイント」はカスタマージャーニーマップを見てわかり、「チームとして課題だと感じているポイント」はKBOツリーで把握できます。

「お客様の不便を解決できる施策」と「チームの課題を解決できる施策」の2つの視点で優先順位を決めていくことで、大きく3つに分類ができます。

• 重点施策
• 重要施策
• 余力があったら取り組む施策

優先順位は「重点施策>重要施策>余力があったら取り組む施策」の順です。

おわりに

今回は、施策の優先順位の決め方をご紹介しました。次回は、サポートサイトの改善について、よくあるパターンを事例付きで紹介する予定です。

「サポートサイトに十分な情報を載せているものの、お客様からの問い合わせがなかなか減らない」

このような問題の原因のひとつに「サポートサイトが辞書のようになっている」ことが挙げられます。

お客様の疑問を解決できる情報がサポートサイトに掲載されていても、お客様が目的の情報を見つけられなければ、問い合わせを減らせません。

ではどのようにサポートサイトを改善すれば良いか？

本記事では、辞書のようになっているサポートサイトの改善方法を、具体例を交えながらご紹介します。

サポートサイトが辞書みたいになっていませんか？

サポートサイトのよくある課題に「辞書のようになっている」というものがあります。

具体的には、FAQが一覧で紹介されており、お客様が一覧から自分の問題の解決方法を探さなければならない状態です。

どんなに情報が網羅されていても、辞書のような状態ではお客様に負担をかけてしまっています。お客様は情報の一覧から自分が必要としている情報を探さなければなりません。欲しい情報が見つからず、離脱しているお客様もいるでしょう。

「情報はそろえているから、あとは自分で探してね」という状態は、お客様に一方的な負担をかけてしまっている可能性があります。サポートサイトを使ってお客様に疑問を解消してもらいたいなら、お客様が疑問を簡単に解決できるようなサポートサイトを作るべきです。

では、どのようなサポートサイトが理想なのか？

サポートサイトは、「お客様に合わせて、必要なタイミングで必要な情報だけを届けられる」のが理想です。例えば会員制サービスの場合、入会前と入会後でサイトを分け、お客さまへ必要であろう情報だけを掲載するといった具合です。（詳しくは後述します）

いずれにせよ、お客様が自己解決できるサポートサイトを目指すなら、辞書からの脱却が欠かせません。情報を探してもらうのではなくて、情報を選んでもらうUIに変更しましょう。

辞書のようなサポートサイトを改善する方法

辞書のように情報を羅列しているサポートサイトの脱却は、大きく2つのステップで進めていきます。

1. 誰に何を見せるかを明確にする
2. 情報を整理する

1.誰に何を見せるかを明確にする

辞書のようになっているサポートサイトの多くは、すべての人が同じページを見ることが前提になっています。

例えば保険会社の場合、保険に加入する前のお客様と加入した後のお客様が同じページで情報を探しているようなものです。

保険への加入前と加入後で必要なサポートは違うはずですよね。それにもかかわらず、同じページに両者が求める情報が集まっています。お客様にとって不要な情報も多いため、お客様が欲しい情報を探すのに手間がかかってしまうのです。

お客様に合わせて必要なタイミングで必要な情報だけを届けるためには、お客様ごとに情報を出し分けなければなりません。それができるサポートサイトを目指すには、誰に何の情報を見てほしいかを明確にする必要があります。

裏を返せば、「誰がどんなときに、何のためにサポートサイトへ訪れているか」を把握したうえで、サポートサイトを構築していくということです。

そこで、誰に何の情報を見てほしいかを明確にするために、サポートサイトに載せている各情報が「お客様にとっていつ必要になるか」を考えていきましょう。

2.情報を整理する

「誰に何の情報を見てほしいか」を明確にしたあとは、お客様が必要な情報にたどり着きやすいよう情報を整理していきます。

その際に有効なのが「FAQツリー」です。

FAQツリーは、よくある質問を階層的な構造でまとめたものです。ツリー構造にまとめることで、関連する内容をグループ化しながら、どの情報を誰に見せるかを整理できます。

情報を整理する際は、感覚的に仕分けることがほとんどです。

例えば保険会社のサポートサイトの場合、加入前と加入後でどんな情報が必要かを考えながら、「保険プランについて」や「契約内容の変更について」のような大きなカテゴリーで分けていきます。

大きなカテゴリーに分ける際は、わかりやすいカテゴリー名を設定することが大切です。

カテゴリー名が分かりにくいと、サポートサイトに訪れたお客様は、自分の探している情報がどのカテゴリーにあるか判断できません。お客様が欲しい情報へ簡単にたどり着くよう整理しているため、カテゴリー名は誰でもわかる表現にしましょう。

大きなカテゴリーに分けたあとは、「各FAQがどのカテゴリーに結びつくか」を考えていきます。

ここまでできたら、お客様が探している情報をスムーズに見つけられるように、加入後と加入前でサイトやページを分けます。

できれば、お客様が情報を選びやすいUIへの変更も進めたいところですが、まずは情報の仕分けだけでも実施しておきましょう。

また、加入前後でサイトやページを分けたあとは、加入前後で各サイトへ直接アクセスできる仕組みを整えるのが理想です。

お客様に合わせて各サイト・ページに誘導する仕組みは、KARTE RightSupportを使って実装できます。問い合わせいただければ相談に乗ることも可能ですので、下記サイトをご覧ください。

>>https://rightsupport.karte.io/#form

ユーザーテストや社内テストを実施する

感覚的に仕分けたあとは、ユーザーテストや社内テストを実施し、サポートサイトを実際に使った人の意見を聞きながら修正していくのがおすすめです。

できればユーザーテストが理想ですが、難しければ社内テストでも構いません。

ユーザーテストの場合は、実際にお客様を集めてサポートサイトを使ってもらい、ヒアリングします。詳しくは別の記事で解説します。

社内テストも同じように、社員にサポートサイトを使ってもらい、わかりにくい部分やつまずくポイントを教えてもらいましょう。できれば、自社のサービスなどに詳しくない新人に使ってもらうのがおすすめです。

サポートサイトは改善を繰り返して精度を高める

サポートサイトを改善する際は、「1回の改善で完成度の高いサイトにはならない」と考えておきましょう。

経験上、一度情報を整理しただけで完璧なサポートサイトを作れることはほとんどありません。1回で完璧なサポートサイトを目指すと、いつまで経っても改善が終わらない恐れがあります。時間をかけて改善したサポートサイトが、お客様にとっては使いにくい場合も考えられます。

お客様が疑問を解決できるサポートサイトを作るには、リリースしてからもテストを繰り返し、育てていくことが大切です。リリースしないと改善のためのデータが集まらないため、まずはリリースすることを目標にします。

リリース後のサポートサイトを改善するためには、サポートサイトを育てるための計画も立てておきましょう。

具体的には、

• どのようなデータを集めるか？
• いつ頃を目処に修正していくか？
• どのタイミングでテストを実施するか？

といったことを決めていきます。

私の経験では、リリース後1週間を目処にターゲットごとのWeb行動の初動を確認し、「仮説通りの動きになっているか？」「新たな発見があるか？」などの視点で分析し、改善案を考えることが多いです。

また、サポートサイトを改善するためのデータを集める仕組みも必要となります。「誰がどこでつまずいているか」「どういう流れで問い合わせにつながっているか」といったデータを取れる環境の整備も進めていきます。

このようなデータは「KARTE RightSupport」で集められます。詳しくはサービスサイトをご一読ください。

>>https://rightsupport.karte.io/

おわりに

お客様が情報を探さなければいけないサポートサイトでは、お客様は問題を自分で解決できません。お客様の自己解決を促すためには、情報を選んでもらう構造に改善しましょう。次回は、カスタマーサポートの担当者が知っておきたい基礎知識として、主な指標についてご紹介する予定です。

お客様が疑問を自力で解決（自己解決）できるよう、データをきちんと取得・活用できていますか？

CSにとって、お客様から寄せられる問い合わせは少ないのが理想です。お客様が疑問を自力で解決できれば、サポートにかかるリソースを別のところに充てられます。

お客様の自己解決を促すためには、困っているお客様の行動を把握しなければなりません。しかし、実際はお客様の行動を把握できた”つもり”になっているケースが非常に多いです。

本記事では、「お客様の自己解決を促進するためにはどんなデータが必要なのか」や、「不足しがちなデータ」についてご紹介します。また、お客様の行動の全容を把握するために欠かせない、Webとコールのデータ連携についてもまとめました。

「お客様の自己解決を促し、サポートにかかるリソースを削減したい」というCS担当の方は、ぜひ最後までご覧ください。

自己解決を促すには現状の把握が必要

CSにとって、お客様が疑問を自力で解決できるような施策が重要になっています。お客様が疑問を自己解決できれば、サポートにかかる工数を縮小し、効率が向上するためです。

参考：vol.01 定義・総論編 

では、お客様の自己解決を促すためにはどうすればいいか？

まず必要なのが「困っているお客様の行動を把握すること」です。

当たり前ですが、お客様の行動がわからなければ、自己解決のために効果がある施策が考えられませんよね。また、仮に施策を思いついたとしても、その施策がどれくらい効果がありそうか見当がつきにくいものです。

そこで、困っているお客様の行動を数値化してまとめていきます。数値化する理由は分析するため、そして施策を決めるときの優先順位を決めるためです。

これらの行動をまずはデータとしてまとめましょう。

これをグラフ化して、分析のために視覚的にしたのが下記の画像です。

このようにデータで可視化することで「どういうお客様がどれくらいの数いて、そのお客様のをどのように行動させたいのか？」について考えられます。

このデータを集めるときに難しいのが、「自己解決したお客様をどのように特定するか」です。

お客様が「自分で解決できました」と報告してくれるわけではないため、こちらが「このお客様は自己解決できている」と判断しなければなりません。

では、どのようにしてお客様が自己解決したかを判断すればいいのでしょうか？

「お客さまが自己解決したか」を把握する方法

お客様が自己解決したかを判断するためには、「自己解決したであろう行動を把握する」必要があります。

このあたりは分かりやすいですよね。

しかし、上記のようなボタンは押さない人がほとんどです（むしろ役に立たなかったときに押されがちです）。

そこで、自己解決したであろうと「みなす」ことも必要になります。

FAQの一覧ページで離脱しているお客様は、おそらく疑問を解決できていないですよね？一方で、FAQの個別記事を時間をかけて読んでいたら、自己解決できていそうだと思いませんか？

このようにして、自己解決したであろう行動をピックアップし、お客様の行動を分析することで、自己解決しているお客様を把握できます。

ここまでで、「問い合わせてきているお客様」と「自己解決しているお客様」の行動がわかりました。

ただし、これだけでは困っているお客様の行動全体を把握しているとは言えません。
どういうことなのか？

データ活用が「みなし」で終わっていませんか？

データ活用において忘れてはいけない存在、それが「問い合わせしないで諦めた人」です。いわゆる「サイレントカスタマー」を指します。

実は、カスタマーサポートに問い合わせるお客様はほんの一部でしかありません。困っているお客様のうち、96％はサイレントカスタマーの可能性があると言われています。

サイレントカスタマーの中には、「調べても解決できないし、わざわざ問い合わせるのは面倒だから、他の商品・サービスを使おう」という人もいるはずです。このサイレントカスタマーの存在を無視していると、自社の製品・サービスに興味を持ってくれていた多くのお客様を、逃してしまうことになりかねません。

では、どのようにサイレントカスタマーを特定するのか？

サイレントカスタマーを特定するには、サポートサイト上でのお客様の行動を追う必要があります。

例えば、

• サポートサイトのFAQ一覧を見ただけで離脱している
• 問い合わせページにアクセスしたが、電話もメールもしないで離脱している

というお客様がいれば、サイレントカスタマーである可能性が高いです。

データの取得や活用にはWebとコールの連携が必須

実はWeb上のお客様の行動だけを見てわかるのは、自己解決したのかサイレントカスタマーなのかだけです。

しかし、実はよくあるのが、以下のようなパターンです。

上記のように、データの収集で「困っているお客様の全体」を把握するためには、Web（サポートサイト、FAQ、チャットボット、メールなど）と電話での問い合わせのデータ連携が欠かせません。

また、連携のためには個人を特定する必要があります。

Webと電話での問い合わせのデータがつながっているからこそ、「Webページを見て電話した」「Webページを見たけど、電話しないで離れた」というお客様を把握できます。

Webから電話へ流れているお客様の行動を把握することで、お客様の行動の全体がわかるのです。

なお、Webとコールのデータを連携するためには、「KARTE RightSupport」のようなツールが必要です。ご興味がある方は以下のページをご覧ください。

>>https://rightsupport.karte.io/

おわりに

今回は、自己解決促進のためのデータ活用についてご紹介しました。お客様の自己解決を促すためには、問い合わせやサポートサイトで疑問を解決できたお客様の行動だけでなく、解決できずに離れてしまったサイレントカスタマーの行動にも注目しましょう。