SaaSが成長を続け、カスタマーサクセスという言葉や役職が流通していくなかで、従来の「カスタマーサポート」をどのような位置づけで考えるべきか、疑問の声を聞くようになった。
サービス事業者がサブスクリプションモデルへの移行でビジネスの成功を導き出す昨今の流れからすれば、スタートアップのみならず、今後は大企業も含めて起きうる課題といえるだろう。
そこで、クラウド名刺管理サービスなどを提供するSansanでカスタマーサクセスに従事し、著書『カスタマーサクセス実行戦略』を持つ山田ひさのりさんに、あらためてカスタマーサポートとカスタマーサクセスについて、その使命から始まる位置づけや役割、両者の最新トレンドまで、さまざまに寄稿いただいた。
連載初回ではテクニカルサポートとカスタマーサクセスの違いをイシューから見ていった。第2回では、テクニカルサポートを事業部内の位置づけから見直すことを勧めた。今回は、2021年現在の「トレンド」がテーマ。これを踏まえることで、組織の理想形を把握する手助けになるという。
ーーーーー
『おもてなし幻想 デジタル時代の顧客満足と収益の関係』という本をご覧になったことはあるでしょうか。2018年7月に出版され、原著は『The Effortless Experience』という題でした。
主にBtoC向けのカスタマーサポート組織を意識して書かれており、「世の中のデジタル化が猛烈に進む中、顧客に過剰なロイヤルティを与えるのではなく、むしろ人の手を借りずに迅速に問題を解決できる方がより価値がある」といった主張が展開されています。
同書の主張は示唆に富み、私も興味深く拝読しました。その論理展開を大まかに要約すると以下のとおりです。
- サポートチャネルで顧客を喜ばせることは割に合わない。期待を上回るサービスを受けた顧客のロイヤルティは、期待が満たされただけのだけの顧客のそれよりも、ほんのわずかに高い程度に過ぎない
- カスタマーエクスペリエンスは、顧客のロイヤルティよりもディスロイヤルティを促進する機会が4倍も多い
- ディスロイヤルティ緩和のカギは、顧客の省力化にある。企業は顧客に課す作業量を減らし、喜びを与えるサービスよりも、手間のかからないサービスの構築に注力すべき
いずれもこれまでお題目的に叫ばれてきた「顧客満足度」に真っ向から対立する思想であり、その前衛性と納得度から同書は世界中のサービス関係者に読まれています。そして、この思想はSaaS業界にも影響を与え、テクニカルサポートにおけるトレンドの一つとなっています。
この本のキーワードに「低努力」があります。低努力とは「顧客自身の力で、最短かつ最小限の労力で問題解決方法を発見・理解できること」を表しています。そして、あらゆるサービスにおいて、より低努力で顧客自身で問題を解決できる方法を提供することが推奨されています。
SaaSに当てはめると、探しやすくわかりやすいヘルプサイトの構築や、そもそも使い方に迷わないプロダクトづくりに注力することに読み替えられます。この「顧客による低努力な問題解決」は、SaaSのテクニカルサポートにおいても意識すべき重要課題の一つとなっています。
サポートチャネルの多様化とライブチャットの出現
2010年頃からテクニカルサポートのいちチャネルとしてライブチャットが出現しました。ライブチャットは、「わかりにくいヘルプページを徘徊したお客様が、最終的にサポートの電話番号にたどり着いてコールするも、長く待たされて辟易する」といった体験をなくすために始まったものです。その後も進化を続け、現在ではそれをロボットの応用で自動化するチャットボットなども存在します。
2021年現在のSaaSスタートアップにおいては、ライブチャットを使ってテクニカルサポート業務を始めることがトレンドとなっています。その理由は3点あります。上述した「低努力の実現」、次に「顧客体験（Customer Experiense）の高さ」、そして「導入のしやすさ」です。
ライブチャットはヘルプやFAQといった「ナレッジベース」にある大量の情報から、欲しい情報にたどり着けないユーザーのために出現したサービスです。前述したような最悪の体験で失望させることなく、顧客の望むものをクイックに提供することを目指した手法であるため、低努力かつ顧客体験が高いのは当然で、多くのSaaSベンダーがこのメリットに目をつけています。
また、サービス提供者側が導入しやすいのもメリットです。対応する人的リソースは必要ですが、提供サービスに明るい人材がいれば、手軽に始められます。それゆえに、アーリーフェーズのSaaSスタートアップでも活用されやすい手法といえるでしょう。
ただ、ライブチャットはカスタマーサクセスが顧客対応の一環として行うことも多いため、その活用がテクニカルサポートをカスタマーサクセス寄りの組織へ近づけるバイアスとなって働く面もあるようです。現に、ライブチャットではないものの、オンボーディング期間中にSlackなどを使って顧客とダイレクトにコミュニケーションを行うことも、この派生系という見方もできます。
一見するとメリットの多いライブチャットですが、実はその存在には大きな「罪」もあると私は見ています。Sansanを始めとするサービス提供歴が10年を超えるようなSaaSの場合、サービス立ち上げ時にライブチャットが存在しなかったため、テクニカルサポートのメインチャネルとして活用されていないことも多いです。それゆえに、ライブチャットがもたらすマイナス面が目についてくるのです。
ライブチャットがはらむ、5つの罪
1：顧客努力は下がるものの、運用負荷が大きい
顧客に良質な体験を与えようとすると、運用負荷はどうしても高くなります。電話と比較しても、リアルタイム性を担保されたままで、コミュニケーションが音声からテキストへ移り変わっただけともいえるので、丁寧さが必要になるのも変わりません。対応側のリソースを多く消費します。
2：計画性をもったサポートがしづらい
インタラクティブ（同期）なサポートチャネルであるため、クイックな対応を求められます。メールや問い合わせフォームならば、タイムマネジメントをしながらの計画性を持った対応も可能ですが、常にリアルタイムな回答を求められるライブチャットでは、「一日に◯件対応する」などの現場目標の設定もしづらくなります。
3：クイック解決に資するKPIを設定しにくい
問い合わせをフォームで受け付けているSaaSは、「一度で顧客の納得する回答を素早く作る」といったKPIを設定できます。しかし、ライブチャットの場合はそうはいきません。
インタラクティブな会話では、よほどの技量を持った方でない限り、クイックに回答するというKPIを達成できません。テクニカルサポートの生産性を計測することは困難です（第2回で書いた「顧客努力指標」はその代替案でもあります）。
4：ナレッジベースを蓄積しにくい
一般的に会話ベースで物事が進むため、問い合わせのあった内容をナレッジベースに反映し、育てていくという考えが弱くなりがちのようです。
ただ、最近のライブチャットは人間が対応する前に、顧客へ選択肢を提示しつつ要求を絞り込んでいくものもあるので、それらの記録を上手く使うなど、工夫次第でこの問題は回避できるでしょう。
5：顧客の自助努力のトリガーを奪いやすい
ここは重要な部分なので詳しく説明します。問い合わせをしてくる顧客にとってもっとも重要なことは、“できるだけ早く回答を得ること"です。
皆さんおなじみのヘルプ＋問い合わせフォームは非同期サポートチャネルです。このチャネルを前にした顧客は「自分で調べるのと、問い合わせフォームに投稿して答えを待つのとでは、どちらがより早く回答を得られるか？」を暗黙のうちに自問します。そして「自分で調べたほうが早い」と感じる顧客はヘルプを引くため、自助努力する顧客が一定の割合で存在します。
一方で、ライブチャットは同期サポートチャネルであり、顧客は即時の回答を期待しています。これは顧客の自助努力の機会を暗黙のうちに奪っていると見ることもできます。これはライブチャットがもたらす大きなデメリットなのです。
2021.9.14追記
評判の良いサポートチャットサービス（SaaS）をいくつか深めに調べましたが、サービスによっては、上述の1～3はさまざまなフォロー機能の実装により、すでに問題ではなくなっていました。「顧客から同期性を求められやすい」という側面は未だ存在しますが、計画性を持った対応とクイックレスポンスが両立できるサービスもすでに存在するようです。
ライブチャットを上手く導入するためにできること
しかしながら、ライブチャットは上手く使えば、顧客体験の向上と低努力を両立できるポテンシャルを持っています。特にSaaSの初期フェーズにおいては、その手軽さから有効な戦術の一つになります。
ただ、サービスの提供年数が5年、6年と経過してくると、発生する問い合わせ数は無視できないものになり、テクニカルサポートの工数を圧迫し始めます。サービス提供側にとっては事業スケールの足かせともなり得ます。
サービス事業者は顧客が低努力かつ運用工数を圧迫しない形で、自身で問題を解決できる方法を模索しますが、ライブチャットだけでこの壁を突破することは難しいようです。この問題については、ナレッジベースの構築が効果的です。
サービスのスケールに欠かせない、ナレッジベースの構築
ヘルプやFAQなどのナレッジベースは、一世代古いソリューションというイメージがあるかもしれません。しかし、実はこのナレッジベースの構築こそが、顧客の低努力と運用側の負荷軽減を両立するカギを握っているのです。
10年以上続いているSaaSの場合、多くはヘルプサイトが充実しており、その情報を見て問題が解決しなかった場合は、フォームから問い合わせるという設計になっています。ともすれば古臭いサポートフレームにも見えますが、現在のサポートトレンドである「顧客自身の力で、最短かつ最小限の労力において問題解決方法を発見・理解できること」にマッチしているのです。
上述した「ライブチャットがはらむ5つの罪」も、ナレッジベースの構築と問い合わせフォームの設置を掛け合わせれば解決するものばかりです。こう考えていくと、サービス事業者は、顧客努力と運用負荷を良いバランスで保てるサポートチャネルを選ぶ必要があることがわかります。
下の図は、顧客努力の高低と運用負荷の高低を軸に、サポートチャネルをマッピングしたものです。
サポートチャネルのマッピング位置は私の個人的な感覚に過ぎませんが、マッピングがどうあろうと、サービス事業者はマッピング右上のエリアを目指す必要があります。
しかし、現実的にはそこに置ける理想的なサポートチャネルはまだ存在していません。サービス事業者は、自身が置かれているフェーズに応じた最適なポジションを都度模索しなくてはなりません。
SaaSスタートアップの初期フェーズにおいては「ユーザーに良質な顧客体験を与えることを優先する」という意思決定もあるでしょう。しかし、事業の拡大によって人的リソースを他のパートに振り分けねばならなくなった際に、顧客体験を多少犠牲にしても運用負荷が少ない方法を選ぶ必要が出てきます。このマップには、その意思決定を補助してくれる効果があります。
ただ、フェーズがどうであれ、私のSansanでの経験を踏まえて言うと、ナレッジベースの構築はSaaS事業の拡大においてはなくてはならないものです。SaaSの顧客は理論上無限に増えるため、探しやすく見やすいナレッジベースを構築することは、のちの問題解決コストを大きく下げます。
ナレッジベースを構築する際のポイントは、「見通しの良さ」と「情報の探しやすさ」
ナレッジベースを構築する際のポイントは、「見通しの良さ」と「情報の探しやすさ」であり、これらを両立させるプラクティスがあまり知られていないことから、「ヘルプは見づらい、使いにくい」と思われているに過ぎません。
この部分さえ改善できれば、ユーザーの低努力と高い顧客体験を両立することも不可能ではありません。要は、作り方次第でまだまだ発展する余地を残したソリューションなのです（※）。
また、10年オーバーSaaSにおいて典型的な、整理されたナレッジベース＋問い合わせフォームというサポートチャネルは、計画性をもったサポートの提供やクイック解決を目的とした現場KPIの設定なども実現できるため、チームを組織化しやすいというメリットも生み出します。サービス・プロダクトのフェーズによっては、非常に有効なサポート手段といえます。
この連載も3回を経て、カスタマーサクセスとテクニカルサポートの違いに始まり、最新トレンドまでも踏まえてくることができました。次は最終回として、いよいよテクニカルサポートの組織化するためのステップについて書いていきます。
※編集部注：今回の連載ではナレッジベース構築の詳細にまでは触れませんが、機会を見て、それに注目したコンテンツも検討しています。この部分はまだ世の中にナレッジが少ないため、もう少し研究が必要です。
