プロダクトのフェーズによるCSMの役割の変化
こんにちは、くるくるです。
LAPRAS Advent Calendar 2021の記事として、CSMについての考察を書きました！
日本でもカスタマーサクセスについて様々な議論を目にするようになってきました。カスタマーサクセスマネージャーとプロダクト部門の連携方法についてや、セールスからの一貫したCXについてなど様々な議論が盛り上がってきた流れに触発されて、現場の感覚から思うところをまとめてみました。
※ここでカスタマーサクセスマネージャーとは、プロダクト導入後の顧客をプロダクト活用からプロダクト導入による事業貢献をサポートする職務を想定しています
※ CSはSaaSに限った話ではありませんが、一旦BtoB SaaSやそれに準ずるWebサービスを想定しています
執筆にあたり以下のnoteを参照させていただきました。
openpage藤島さんのnote。企業規模とフェーズごとにまとまっています。CSチームの成長を俯瞰するのに大変良い記事ですので、未読の方はぜひこちらも読んでみてください。海外トレンドなどの良質な記事をたくさん出されているので他の記事も必読です。
では本題へ。
改めて、カスタマーサクセスとは
あくまで私の理解ですが…
カスタマーサクセスは事業戦略
プロダクトを利用した顧客が成功することによって自社も恩恵を受ける収益構造になっていることを指します。顧客の成功指標と収益のアラインメントが取れていることが重要です。
カスタマーサクセスは顧客の状態の理想
収益が顧客の成功によってもたらされるために、自社が提供するプロダクトとサービスで顧客のどのような状態を達成するのかの理想です。
カスタマーサクセスを実現する責任を担っているのがカスタマーサクセスマネージャー
プロダクト単体ではサクセスが難しい場合にサービスをパッケージして提供したり、時にはプロダクトそのものに変更を働きかけることにより顧客の成功を実現する役割です。
と考えています。
2019年ごろまでは国内ではカスタマーサクセス＝職種の認知がされ、実質的には従来のカスタマーサポート職または既存顧客営業職の延長のように捉えられることが多い印象でした。そんな中、特にスタートアップ界隈ではここ1〜2年で事業戦略やカルチャーとしてこの概念を用いることが増えてきました。それに伴いいろいろな手法が出てきたことで、CSの言説におけるSFDCの圧倒的な存在感も少し薄まってきたような気がします。
色々なCS組織があるけど正解はあるの？
カスタマーサクセスが浸透してくるに従って、「これが正解」と思えるような素晴らしい事例が多く発信されるようになりました。その中には相互に矛盾するような事例もあります。いろいろな事例を取り込もうとしすぎて単なる全方位戦略になってしまったりすることもあるでしょう。
担当するプロダクトの成熟度、ユーザーの性質、MUST HAVE度合いによって、CSのチームが担うミッションは異なります。今回は表題の通りプロダクトの成熟度に焦点を当ててみたいと思います。
（成熟度はいわゆるプロダクトライフサイクルですが、現在のインターネットを活用したプロダクトを表すのに少し違和感を感じる事があるので、ここでは成熟度と表現しています）
プロダクトの成熟度によるCSのミッションの変遷
プロダクトの成熟度を、「立ち上げ期」「拡大期」「成熟期」とざっくり3ステージに分けて考えてみましょう。それぞれ「0→1」「1→10」「10→100」または「イノベーター」「アーリーアダプター」「アーリーマジョリティ」のイメージです。
プロダクトの立ち上げ期（0→1）
プロダクトの立ち上げの最初期はCS専業のスタッフを置かないケースが大半です。これは当然の話で、既存顧客の数が十分でないため業務量が多くないなど、分業するメリットが少ないからですね。
プロダクト初期の問い合わせ対応や支援コンテンツ作成等のCS業務は、プロダクトの性質によって営業担当またはプロダクト開発担当が担うケースが多いでしょう。新規プロダクトにおいては、まずは顧客を獲得して使ってもらわなくてはなりません。
体制が小さいうちはプロダクトのフィードバックループを早く回すため、導入時から話をしている営業担当やプロダクトを開発している人間が顧客の近くにいて顧客理解を深める方が、サポートの効率を上げることよりも重要です。
また、プロダクトの立ち上げ初期は顧客数もトランザクション数も少なく、取れるデータの種類も少ないため、データドリブンで精緻な意思決定をすることが難しい（個人的にはこのフェーズでは不可能だと思っています）ということを念頭に置き、定性情報からいかにして筋の良い仮説を導き出して検証できる体制にしていくかを考えましょう。
CSMがいないのにCSMのミッション…というのも不思議ですが、以下のようなことがこの時点でのCSMのミッションとして重要度が高いでしょう。
- 顧客理解
- プロダクトの方向性を見定めて、いつ、どのようなタイプのCS体制を構築するかを検討する
- プロダクト開発の代わりに手動対応で仮説検証
- プロダクトの「カスタマーサクセス」の発見
- VoCや顧客データの蓄積
プロダクトがこのフェーズにある時にやらない方が良いことは、基本的にはオペレーションの作り込みです。
- 標準ワークフローやプレイブックの作り込み
- ヘルススコアやKPI、ステージ管理の作り込み
- 複雑なコンテンツ配信シナリオの作り込み
これらは小規模ではあまり効果がなく、オペレーション規模が大きくなってきた時に威力を発揮するツールです。一度作ってしまうと変更コストが高く、変更時のミスも発生しがちなので、1→10のフェーズが見えてきた時に仕組み化することを考えましょう。
CSチームの立ち上げ
さて、顧客数が増え、サポート品質にムラが出てくるなど問題が多くなってきたらいよいよCSのチームを立ち上げましょう。立ち上げの際に優先すべきミッションは、プロダクトの性質により異なりますが、オンボーディングやカスタマーサポート領域に注力するケースが多いのではないでしょうか。
どのようなタイプのCSであっても、以下の3点は一旦立ち上げ時点で整備しておくことをお勧めします。
- 顧客および施策とその結果の紐付けが可能な状態にしておくこと
- 顧客からの声を社内のステークホルダーに届ける仕組みを作ること
- 顧客からの問い合わせ窓口やナレッジベースの整備
顧客が増えてきたということは、プロダクトの方向性が固まってきたということで、サクセスの仕方やプロダクトのユースケースにもかなりパターンが出てきているはずです。
ここまでくるとデータの蓄積が威力を発揮するようになります。データの蓄積には定義付けが必要です。プロダクトの方向性そのもので試行錯誤している段階ではあまり意味のある定量データを集めることができませんが、このくらいのフェーズに入ってくると顧客の性質に関するラベルデータを集められるようになっていると思われます。
CS専業組織を作ることによる課題も発生します。CSM以外のメンバーの顧客接点が減少し、顧客の声がCSMで滞留するということが起こります。これは分業する以上仕方ない部分でもあるのですが、顧客の声が長く届かない状態が続くとプロダクトの機能開発が迷走したり、手応えが減ってモチベーション低下を招く原因にもなるため注意しましょう。
プロダクトの拡大期（1→10）
プロダクトの利用顧客数が増え、CS組織も立ち上がりました。まだまだプロダクトに改良の余地がありますが、概ね事業ドメインや提供価値といった重要なものは定まっている状態で、ある程度成功パターンが見えてきたのがこのステージです。プロダクト的にはPMF前後をイメージしています。
このような状況でのCSMの役割はどのようなものでしょうか？このフェーズを超えると組織が急拡大し、一気に業務の複雑性が増大することになります。その時にできるだけシンプルに拡大できるように仕組みの整備を行っていくのがこのフェーズです。
以下のようなことを行っていきます。
- フィードバックループを高速に回すための仕掛けを作る
- サクセスへの基本的なワークフローを作る
- アーリーアダプター層のファン化
- カスタマーサポートの仕組みを整える
- テックタッチ施策へのシフト
- サービス商品の開発
- 「カスタマーサクセス」とレベニューのアラインメントを成立させる
- 顧客管理基盤の構築
「フィードバックループを高速に回すための仕掛けを作る」
CSというとカスタマーサポートやリテンションセールスの印象が強いのですが、もう一つ重要な役割として、「プロダクトフィードバックループを回す」というものがあります。CS組織を立ち上げることができた時点でプロダクトの基本的な形は定まっていることが多いです。しかし「使われ続けるプロダクトになるか？」という点については、このフェーズで成功パターンを作っていくことが重要になります。
記事をいくつか紹介。
LayerXかじさんのnote。プロダクトフィードバックループにおけるCSMの役割について詳細に解説されていて、明日からでも取り入れられそうな施策なども。
日本語のリソースがあまり見つけられなかったので海外SaaSのブログから。PM目線からCSMと連携せよという記事。はい、PMの皆さんぜひCSMをコーヒーに誘ってくださいね。
CS-PM連携では、CS組織のオーナーシップでVoCのデータベースを作り、PMと共有して管理する、というのが推奨されているようです。
「サクセスへの基本的なワークフロー構築」
ステージ設計やマーケ・セールスを含むCX整備、プレイブックの作成など、勝ちパターンが見えてきたプロセスを段階的に型化していきます。こちらも最初から全てを作り込むよりは、効果検証しながら少しずつ進めるのが現実的です。
イメージとしては、
「改善」→「改善」→「最適化」→「改善」→「改善」→「最適化」→…
といった感じで小さく効果を上げつつ、定期的にプロセス上の負債を解消していくのが良いのではないかと思います。マーケットの成熟やプロダクトの成長によって従来必要だったステップが必要なくなるようなケースもあるため、プロダクトと同様に継続的な改善を重ねていきましょう。
「カスタマーサポートの仕組みを整える」
カスタマーサポートはカスタマーサクセスの基本のキです。問い合わせ、通知、ナレッジベースの3点セットは、顧客層に合わせて構築しましょう。カスタマーサポート領域はCS業務の中でも比較的歴史が長く、効率化のプラクティスが蓄積されている領域でもあります。型化しやすいので効率化を進めたくなりますが、このフェーズではカスタマーサポートの典型的なオペレーション指標を追うことよりもプロダクトの改善への貢献を優先することをお勧めしたいです。
MUST HAVE度が低いプロダクトの場合、サポートの効率化以前に顧客から質問があまり来ない…というケースもあります。プロダクトがシンプルで分かりやすい！なら良いのですが、単に使われていないだけだったりするケースもあるため、喜ぶべきかは悩ましいところですね。
「テックタッチ施策へのシフト」
プロセスの標準化を進めていくと、常に同じ手順を踏むプロセスや、コンテンツにまとめた方が良いもの、ユーザーのアクションやステータスに合わせてメッセージを届けた方が良さそうなものが出てきます。そのような場合はいわゆる「テックタッチ」の手法を取り入れるタイミングかもしれません。
「アーリーアダプター層のファン化」
そろそろユーザー会を開催したり、コミュニティタッチでカスタマーサクセスを効率化したいと考え始めるかもしれません。しかし、大抵の場合この段階では顧客数が少なく契約中顧客だけでコミュニティを自走させることは難しい場合が多いと思われます。サクセス目的よりも、新規獲得を目的としてマーケティングやセールスのチームと一緒にエヴァンジェリストの育成などを検討しても良いでしょう。
「サービス商品の開発」
導入コストが高い製品やエンタープライズ向け製品の場合は、導入サポートや有料サポートなどのサービス商品が有効な場合もあります。また、有料のサポートを提供することで、より顧客の業務に深く入り込むことも可能になりますし、そこから得られた示唆をプロダクトに還元することでより良いプロダクト開発ができるでしょう。
ただし、サービス商品は導入顧客数が増えれば増えるほど提供のための人員が必要になります。プロダクトのスケールと同時にサービス提供も拡大するのか、立ち上げ時や定期的に「何を目的として販売するか」をしっかりと設定しておく必要があります。
「『カスタマーサクセス』とレベニューのアラインメントを成立させる」
カスタマーサクセスチームが存在するということは、カスタマーサクセス≒売上 の構図が成立していることが戦略上の大前提となります。ところが意外とこの時点で、「顧客のサクセスしている状態とは何かが定義されていない」「サクセスしているはずなのに解約される」「サクセスしていないように見えるが契約更新する顧客が多い」など、レベニューのドライバーとなる重要な要素が分からない…という状態になっているケースがあります。
- 顧客がサクセスしているとはどのような状態か
- サクセスしている顧客のうち十分な割合が契約継続に繋がっているか
- 顧客をサクセス状態へ導くKSFは何か
以上の問いは、このフェーズのうちに他部門と連携して解いておきましょう。この辺りをうやむやにして組織拡大すると…大変です。
「顧客管理基盤の構築」
上記の施策を滞りなく進めるためには、CRMやCS用のシステムを導入する必要があります。各ツールそれぞれ特徴があるため、プロダクトの性格に合ったシステム構成にしましょう。SaaSの場合はどんどん機能が追加されるので、細かい機能の有無だけでなくプロダクトの方針を見て決めることがお勧めです。また、いずれプロダクトからのデータ連携を実装する必要が出てきます。プロダクトの開発エンジニアにも導入に携わってもらうか、情報共有はできるようにしておきましょう。
手前味噌ですが、Intercomを導入した時の記事を参考に…。Intercomもこの時点からかなりグレードアップしています。
顧客データがきれいに蓄積できるようになっていくのと同時に、顧客数が多くなってくると個々への対応からセグメント分けが必要になってきます。toB SaaSの場合は企業規模、toCの場合はデモグラフィック属性で分けるのが典型的ですが、プロダクトにとって適切な分け方は必ずしも上記とは限りません。目的に合わせてセグメント設計を行いましょう。
このフェーズをクリアすると、本格的に分業化・組織化の段階に入ります。現在のところ、CSのスタッフはFSなどと同様、顧客数に比例して人数が必要になるケースが多いため、次のフェーズでは採用・育成が重要になってきます。
また、プロセスの標準化やテックタッチ化などをCSの施策として記載していますが、CS組織内で完結しないといけないということはありません。再現性の高いものはプロダクトに実装してもらったり、セールスやマーケに実行してもらうなど、他チームとの連携を忘れないようにしましょう。
プロダクトの成熟期（10→100）
プロダクトの姿がおおよそ固まり、CS単独で効率化が進む時期です。プロダクト共に組織がスケールし、会社内でもCS内でも分業化が進みます。
この段階にあるプロダクトのCSは、レベニュードライバー（＝カスタマーサクセス）が見えてきていることや、アップセル・クロスセル商材が整備されていることが多いことから、CSがセールス寄りのミッションを持つことで効率的なオペレーションが可能になる場合も多くなります。さらに、顧客数増に従ってサポートの効率化を進めることが必要です。顧客数が多ければ大抵の場合データ・ドリブンでの意思決定が非常に有効になっているため、CS専用ツールの活用を進めることが有効でしょう。
そして、採用です。CS組織は基本的に顧客数増に伴って必要な人員が増えるため、マネージャーは採用に追われることになるでしょう。チームの構成は顧客セグメント別や機能別（CSM、カスタマーサポート、カスタマーマーケ、カスタマーオペレーションなど）で分けられることが多いようです。
ビジネスがスケールし始めたら
あとはひたすら効率化を進めていくのでしょうか？いいえ、「振り出しに戻る」ことになるでしょう。
カスタマーサクセス戦略が成立するプロダクトは、常に進化するプロダクトです。一つのマーケットを攻略したら次なるマーケットを目指すことになるのです。その時はまたプロダクトの立ち上げ期からまた始めましょう。（ただし、リソースは潤沢な状態で「強くてニューゲーム」ができると思います）
例えばHorizontal系のサービスでも全ての業界で均等に使われている訳ではなく、成功しやすい業種とそうでない業種があるのが一般的です。そのような場合は、一つの業界向けに展開を成功させたら他の業界にスライドしていくことになります。
まとめ
CSのノウハウは数多く発信されるようになりましたが、その中には今のフェーズに合わないノウハウもあります。現在のプロダクトの状態に合わせて適切な施策を打っていきましょう。
