.png)
SaaSが成長を続け、カスタマーサクセスという言葉や役職が流通していくなかで、従来の「カスタマーサポート」をどのような位置づけで考えるべきか、疑問の声を聞くようになった。サービス事業者がサブスクリプションモデルへの移行でビジネスの成功を導き出す昨今の流れからすれば、スタートアップのみならず、今後は大企業も含めて起きうる課題といえるだろう。
そこで、クラウド名刺管理サービスなどを提供するSansanでカスタマーサクセスに従事し、著書『カスタマーサクセス実行戦略』を持つ山田ひさのりさんに、あらためてカスタマーサポートとカスタマーサクセスについて、その使命から始まる位置づけや役割、両者の最新トレンドまで、さまざまに寄稿いただいた。
今回から4本の連載として、SaaSのグロースに不可欠となったカスタマーサクセス＆カスタマーサポートについて、理解を深めていきましょう。
はじめに
カスタマーサクセスの知名度が向上したせいもあり、「もうカスタマーサポートは古い。これからはカスタマーサクセスだ」という風潮も一部にあるようです。しかし、私は、強いカスタマーサポートがあればこそ、お客様に向き合うカスタマーサクセスが活動できることを熟知しています。
この連載では、カスタマーサクセスとカスタマーサポートの本質的な違いを明らかにし、SaaSビジネスを作り上げる上でこの2つの役割をどのように整理していくかを説明します。
また、現在のSaaSスタートアップのトレンドと、10年以上の歴史があるSansanのカスタマーサポートの歴史を踏まえた上で、私なりの「理想のカスタマーサポート像」を考えてみます。
カスタマーサポートからテクニカルサポートへ
カスタマーサクセスという言葉が現れる前、CSとはカスタマーサポート（Customer Support）を指していました。しかし、新たにカスタマーサクセス（Customer Success）という考え方とビジネスロールが出現したことで、CSの一般認知も変わりつつあります。
どちらも略語がCSで混乱するため、最近のSaaS業界ではカスタマーサポートのことを“テクニカルサポート（Technical Support）”と表し、“TS”と略することも多くなっているようです。
この連載でもトレンドに倣って、カスタマーサポートはテクニカルサポートと呼称することにします。私はテクニカルサポートという言葉を気に入っており、かつ非常に的を射た名称だなと思っています。
その理由はテクニカルサポートの扱うイシュー（問題）にあります。
テクニカルサポートの取り扱うイシュー
私は自著『カスタマーサクセス実行戦略』の第二章で、CSとTSの行動様式の違いについて、「カスタマーサポートは問題が発生してから対応するReactive。カスタマーサクセスは問題を発生させないProactive」と説明しました。
ただ、そのような行動様式の違いは実は一面にしか過ぎません。本質的な違いは、取り扱うイシューにあります。そしてこれこそが、カスタマーサポートがテクニカルサポートへ名称が変わりつつある理由でもあります。
カスタマーサクセスの最終目的は、自社の提供するプロダクト・サービスの利用を通じてお客様のビジネスを成功させることです。よってカスタマーサクセスに従事する人間は、自社プロダクト・サービスが最も効果を発揮するシーンや利用方法に精通しなければなりません。同時に、顧客へ利用方法のレクチャーも求められます。
SaaSが一般化する前、「精通」と「レクチャー」に関する課題は、以下のように整理されていました。
（A）：顧客の事業ドメイン、及び自社プロダクトの利用シーンに対する精通
→ 提供なし（サービスによってはヘルプページなどに記載することもあり）
（B）：提供プロダクト・サービスのエンドユーザーへのレクチャー
→ マニュアルやヘルプページなどを通じて提供。不明点が生じた際に顧客から連絡あり。
旧来のITサービスにおいては（B）のみが提供されており、カスタマーサポートのタスクと位置づけられていました。しかし、カスタマーサポートは顧客から（A）についてのアドバイスを求められることも多く、その場合は「お客様のご利用環境によるため弊社ではお答えできません」と回答せざるをえなかったようです。
一部の顧客志向の高いサービス提供者は（A）をカバーすることもあったようですが、一般的には「顧客の個別事情には踏み込まない」と整理されていました。
ご存知のとおり現在では、SaaSの台頭とカスタマーサクセスの出現によって（A）が顧客へ提供されるようになりました。そうなると、従来からのカスタマーサポートは、（B）の業務により集中することになります。
そして、その過程でカスタマーサポートの業務は、以下のように整理されていきました。
・提供プロダクト・サービスのヘルプ・マニュアル類の提供
・提供プロダクト・サービスの問題発生時のトラブルシューティング
上記についてじっくり見ると、カスタマーサポートがフォーカスすべきポイントは自社提供プロダクト・サービスの機能面での（ファンクショナル）サポートであることがわかります。それと比較して、上述のカスタマーサクセスがフォーカスする（A）は、顧客の運用面での（オペレーショナル）サポートといえます。
つまり、カスタマーサポートとカスタマーサクセスの違いは、それぞれが取り扱うべきイシューにあるわけです。
ここで一度、カスタマーサクセスのオペレーショナルなサポートが担うイシュー、カスタマーサポートの担うファンクショナルなサポートを整理してみましょう。
カスタマーサクセスが取り扱うイシュー
提供プロダクト・サービスのオペレーショナルなイシュー
（例）
- 提供プロダクト・サービスを顧客の社内に浸透させるための計画提案
- 提供プロダクト・サービスが効果を発揮する運用オペレーションの提案
- 提供プロダクト・サービスの効果を計測するためのKPIの検討、及び相談相手
カスタマーサポートが取り扱うイシュー
提供プロダクト・サービスのファンクショナルなイシュー
（例）
- 提供プロダクト・サービスの利用マニュアル（ヘルプ、FAQ等）の提供
- 提供プロダクト・サービスの不具合と思われる挙動の確認・調査・解決
テクニカルサポートの行動様式
私は著書で「カスタマーサクセスとテクニカルサポートは、「攻めと守りの関係」にある」とも説明しました。この両者は扱うイシュー以外にも、行動様式に大きな違いがあるからです。
前述のとおり、カスタマーサクセスが取り扱うイシューがオペレーショナルなものであるがゆえに、そのベストアンサーは顧客の事業や環境に依存します。正解が一つに決まらないため、サービス提供側が積極的に成功事例やプラクティスを提供し、顧客の事情に合わせて柔軟に問題解決方法をデザインしなければなりません。つまり、答えは顧客によって異なるのです。
それと比べて、テクニカルサポートの取り扱うイシューは顧客の依が少なく、ほとんどのケースで正解が存在します。例示すると、あるプロダクトを利用する場合の運用フローは個社ごとにありえますが、プロダクトの機能の操作方法は提供側が用意した数しか存在しません。
顧客がなんらかの問題で躓いた際に、唯一無二の正解を迅速かつ正確にお伝えすることが肝心となるのです。
つまりは、カスタマーサクセスとカスタマーサポートは、それぞれが取り扱うべきイシューを発端として、全く異なる行動様式が必要とされるわけです。この区別を理解しないまま議論を進めると、いずれ組織が拡大したときにカオス化する原因となってしまいます。
連載第二回では、テクニカルサポートの考え方とミッションに絞って、より考えを深めていくこととしましょう。
山田 ひさのり
『カスタマーサクセス実行戦略』の著者。ゲームプログラマーとしてキャリアをスタートし、Web開発のPG/SEを経て事業開発にキャリアチェンジ。その後、Sansan株式会社にてCS部門の責任者を歴任。現在はsasket LLCを設立し、2年間で約20社へのCSアドバイザリーを経験。
