SaaSが成長を続け、カスタマーサクセスという言葉や役職が流通していくなかで、従来の「カスタマーサポート」をどのような位置づけで考えるべきか、疑問の声を聞くようになった。
サービス事業者がサブスクリプションモデルへの移行でビジネスの成功を導き出す昨今の流れからすれば、スタートアップのみならず、今後は大企業も含めて起きうる課題といえるだろう。
そこで、クラウド名刺管理サービスなどを提供するSansanでカスタマーサクセスに従事し、著書『カスタマーサクセス実行戦略』を持つ山田ひさのりさんに、あらためてカスタマーサポートとカスタマーサクセスについて、その使命から始まる位置づけや役割、両者の最新トレンドまで、さまざまに寄稿いただいた。
連載初回ではテクニカルサポートとカスタマーサクセスの違いをイシューから見ていった。続く第2回では、さらにテクニカルサポートを深堀りしていく。
テクニカルサポートの事業内での位置づけ
テクニカルサポートとカスタマーサクセスの違いがわかった上で、テクニカルサポートのミッションを考えてみましょう。私は現在のSaaSにおける彼らのミッションは「問い合わせを発生させない」と「発生した問い合わせに迅速に対応する」だと考えています。
前者を聞いて「それはプロダクトの責務ではないか？」と思う方もいらっしゃるかもしれませんが、そのとおりです。さらに、その疑問はそのまま、テクニカルサポートのSaaS事業内での位置づけの議論へ発展します。
私は多くのSaaSベンダーからカスタマーサクセスの相談を受けますが、中には「テクニカルサポートをどう整備していけばいいのか」という相談も含まれていました。そして、彼らと会話していくことで、テクニカルサポートを組織内でどのように位置づけているのかに違いがあることに気づけました。
テクニカルサポートをプロダクトの一部に位置づけるのか、あるいはカスタマーサクセスの一部に据えるのかです。
.png)
実は、初期段階でどのように位置づけるかによって、テクニカルサポートはその後の進化形態が決まっていくところがあります。順に違いを説明していきましょう。
プロダクトの一部として位置づけられている場合
この場合、そのSaaSベンダーでは「ヘルプはプロダクトの一部」という哲学があり、延長線上でテクニカルサポートがプロダクト部門に属しているわけです。
連載第1回で見たように、テクニカルサポートの存在意義はファンクショナルなイシューを解決することでした。その実現にはヘルプ・マニュアルページの制作が欠かせません。見通しが良く、わかりやすいページを作ることは、ユーザーのスムーズな利用を促し、ファンクショナルな問題を発生させないことにつながるからです。
ただ、近年においては「真に優秀なプロダクトはヘルプ・マニュアルが不要」という考え方があり、それらのページがないことが理想とされます。もっとも、プロダクト・サービスの複雑度やユーザーのテクニカルリテラシーによって、ヘルプ・アニュアルページはまだまだ必要なのが実状です。
そして、顧客への説明の責務は、多くの場合、テクニカルサポートに委ねられます。
このタイプの組織では、「どこまでをプロダクト内部で説明し、どこまでをヘルプに任せるか？」という議論が活発となり、ヘルプ整備のワークフローが整備されていきます。結果として、新機能のリリースに際しては、ヘルプも同時公開されることが多くなります。
もし、あなたの所属するSaaSベンダーのヘルプリリースが新機能に合わせたタイミングになっている場合、テクニカルサポートはプロダクト組織に内包されているか、極めて密な連携をしていると考えられます。ヘルプ・マニュアルページも洗練されたものを提供できるようになるはずです。
カスタマーサクセスの一部として位置づけられている場合
こちらの場合は「ヘルプの参照や問い合わせ回答もユーザー体験の一部」と考えている傾向があります。
ユーザーのヘルプ閲覧や問い合わせを顧客のタッチポイントとみなし、カスタマージャーニーの一部として見ています。顧客に良質な体験を提供することを重んじた形態といえます。
連載第1回で書いたとおり、カスタマーサクセスとテクニカルサポートは本質的に異なるイシューを扱います。ただ、カスタマーサクセスの業務には「顧客からの（ファンクショナルな）問い合わせに対応すること」が多く含まれるため、同じ体験内で解決できたほうがユーザーにとっても負担が少ないという発想につながりやすいのです。結果として、カスタマーサクセスの一部に位置づけられるように整理されているわけです。
このタイプの組織では「顧客が抱いた疑問をいかにストレスなく解決するか」というUXに着目した議論が活発になされる傾向があります。ユーザーの負担を低減するためにチャットサポートを導入したり、Customer Effort Score（顧客努力指数）を積極的に推進したりするところもあります。
また、顧客からの問い合わせはタッチポイントですから、問い合わせ頻度や内容をヘルススコアの要素として検討するケースも見られます。
テクニカルサポートのミッションとは？
テクニカルサポートのSaaS事業内での位置づけを見た上で、改めてミッションを考えてみましょう。
SaaSのゴールは「プロダクトを通じて顧客の成功を後押しし、ビジネスの成長を達成すること」に他なりません。カスタマーサクセス及びテクニカルサポートはその達成を異なる手段で助けているといえます。
そのために、テクニカルサポートが解決すべきイシューに絞って考えると、ミッションは以下2点に整理できそうです。
- 顧客にファンクショナルな疑問を持たせない
- 持たせてしまった疑問は、迅速に調査・解決する
これらのミッションはSaaSプロダクト・サービス上で実現できることがベストですが、現実はそうはいきません。顧客が疑問を感じた際は、理想を言えばプロダクト部門の稼働を奪わずに問題を解決すべきです。
そこにこそ、テクニカルサポートの存在意義があります。
テクニカルサポートの位置づけによって、数年後に発生するメリット・デメリット
テクニカルサポートの事業的な位置づけが数年単位で固定化することで、それぞれに長所・短所も生じてきます。
これは私が何社かのテクニカルサポート組織に細かくヒアリングをして行き着いた結論です。それぞれ、以下のようにまとめてみました。
＜プロダクトの一部に位置づける場合＞
- 「ヘルプはプロダクトの一部」という考え方が根付く
- ヘルプの制作 → 公開の業務フローが洗練されていく
- プロダクトとの接合も強くなり、どのようなポリシーでヘルプを充実させるかのも決まりやすい
- 全体的なバイアスとして「顧客に自己解決してもらう」という意識になりやすく、ヘルプやFAQが洗練される
- テクニカルサポートを「重要な顧客接点の一つ」と考えにくくなる
- 運用相談を解決する機構が存在しない場合、ヘルプに運用（オペレーショナル）の話題が入ってくるようになる
- 全体的なバイアスとして「顧客努力を減少させるべき」という意識になりにくく、顧客に強いる発想を持ちがち
＜カスタマーサクセスの一部に位置づける場合＞
- 「顧客の困りごとを解決すること」が最優先となるので、顧客努力を軽減させるバイアスが働く
- テクニカルサポートを「重要な顧客接点の一つ」と考え、同組織へのタッチ頻度で顧客ロイヤリティを計測するなどの発想を持つようになる
- カスタマーサクセスとの接合が強くなり、操作・設定と運用の相談を合わせて解決しようとするため、顧客からすると便利
- UXが向上しやすく、組織的にも顧客志向になる
- ヘルプ制作の業務フロー及び掲載ポリシーが決まりにくいので「ヘルプはどうあるべきか？」がブレやすい
- プロダクトの操作方法や仕様に対するナレッジがカスタマーサクセスマネージャー（CSMs）のみに蓄積され、外部に広く公開する手段が育たない
- 全体的なバイアスとして「ヘルプ不要なプロダクトであるべき」という意識になりにくく、ホスピタリティのみが向上する
- 問い合わせが増えるのに対し、スケールアウトによる解決がしづらい（CSMsはそう簡単には増えない）
何社かにインタビューしてわかったことは、5年以上継続しているSaaSの場合、日本にカスタマーサクセスの概念が出現する前からテクニカルサポートを用意する必要があったため、「プロダクトの一部」と整理されている場合が多いです。
逆に、ここ数年で立ち上がったスタートアップSaaSでは「カスタマーサクセスの一部」となりがちなようです。
理想的なテクニカルサポート組織のあり方を考える上でも、連載第2回では「位置づけ」と「ミッション」について深堀りしていきました。
実は、これらの違いには重要な示唆が隠されており、それはSaaS事業の成長を左右しかねない問題でもあります。その問題は次回以降に解説をしていきますが、まずは2021年現在のテクニカルサポートのトレンドを知っておくことが、組織の理想形を把握する手助けになるため、次回は先にそちらについてお話しましょう。
