データアナリストが関わったカスタマーサクセスのステージ設計と活用
年末だけnoteに登場する人になりました、freee Analyticsチームの岡田です。
freee Success Advent Calendar 2021の13日目を担当します。
今年はカスタマーサクセス（CS）やプロダクトマネージャー（PdM）と一緒に作ったCSステージの設計とデータ活用について、Analyticsチームとして関わったことを中心に書きます。
データの乱立から理想ドリブン設計へ
freeeではAnalyitcsチームに限らず、様々なチームで日々データ分析と意思決定が行われてます。CSチームも例外ではなく、解約の要因分析をはじめ、色々なセグメントカットで分析を進めてます。
一方、分析が活発になると、
「○○機能を使ってるユーザーは解約率が低いよ」
「このセグメントは△△機能を使った方が更新率が高いよ」
など、データに思考が引っ張られて機能単位の利用率をKPI化してしまい、プロダクト全体のユーザー体験状況が見えづらい指標になったりします。
また、場合によっては現状の使われ方（＝必ずしも理想の使われ方とは限らない）をより助長するような施策を打ち、理想とのギャップがさらに開いてしまうケースも起こり得ます。
そこで、freeeでは理想ドリブンの考えで、
ユーザーにとってのマジ価値（ユーザーにとって本質的な価値）は何か？
プロダクトの理想的な使われ方はどんな使われ方か？
をカスタマージャーニーへ落とし込み、それを表現できるデータを計測・モニタリングすることでユーザーのサクセス状態を把握し、改善していこうという方針を立てました。
CSステージ設計の概要
CSステージの大きなフロー自体は特殊なものではなく、①Onboarding（導入）、②Adoption（使いこなし）、③Expansion（利用拡大）に準じて設計してます。
各プロセスにおける設計ポイントとしては以下になります。
Onboarding（導入）
freeeのプロダクトは勿論すぐに使い始めることができますが、ユーザーの組織体制や実運用の特徴に合わせた設定を行うことで、その後、より効率的な使い方ができます。
そのため、ユーザーが本運用する前の準備プロセスを正しく行なえているか、ファネルで判断できるステージを定義しました。
また、導入初期時に設定すれば、その後は何度も設定しなくて良いような機能についてはストックアクションとして過去に完了したことがあるかを記録し、定期的に使う必要がある機能についてはフローアクションとして決まった頻度でモニタリングできるように区別してます。
Adoption（使いこなし）
ここはマジ価値に関わってくる部分で、企業やプロダクトの目指すべき方向によって最も特徴が出てくるステージだと思います。
freeeではビジョンに沿って、どの程度ユーザーの業務を自動化・効率化できているか、モニタリングできるようにステージを定義してます。
バックオフィス業務を統合することで、自動化と業務全体の効率化。さらに経営全体を可視化することで、これまでにないスマートかつ最適なアクションまで実行できるプラットフォームへと進化させていきます。
サラッと「ビジョンに沿って定義しました」と書きましたが、実はこの部分が一番理想と現実のギャップが大きく、議論に時間を費やす箇所だと思います。
具体的には理想と考える使い方をしてなくても、使いこなし続けているように見えるユーザー層が一定数いることです。
この現実を見ると、ステージ設計メンバーでも理想と現実との間で葛藤が生まれ、議論が盛り上がります。（個人的にはCSやPdMの熱い思いと葛藤が聞ける胸熱の時間です）
freeeでは、上記のような葛藤はあるものの「理想ドリブン」の考えを捨てず、現場ヒアリングや数多くのユーザーリサーチを重ねて、ステージ定義を理想に近づけるために進化させてきました。
今後は、ユーザーの経営状態が可視化され、スマートで最適なアクションが実行できているか、まで議論を深めていけると、よりマジ価値に近づけると個人的には考えてます。
Expansion（利用拡大）
このステージでは、以下のような定義が考えられますが、正直freeeでも議論の余地が残されている領域だと思います。
プロダクトがユーザー組織にどれだけ広く・深く浸透しているか（アクティブID利用率やプラングレードなど）
1つの業務プロセスだけでなく、どれだけユーザーの業務プロセスを統合・カバーできているか（クロスセル状況など）
ステージ設計でAnalyticsチームとしてやったこと
データアナリストでKPI設計と聞くと、「よーし！探索的にデータ分析して、KGIに効きそうな指標やセグメントを見つけるぞー！」と思うかもしれませんが、ステージ設計を考える段階ではデータ集計や分析などは、ほとんど行いませんでした。（「じゃぁ、なんでお前はいるんだ？」というツッコミが聞こえてきそうですがw）
理由としては、前述の通り、『ユーザーにとってのマジ価値』『理想の使われ方』を定義してほしかったためです。
データ分析で分かるのは、過去や現在の状態であって、目指すべき理想の状態ではないと思ってます。しかし、例えば、契約更新率と機能利用状況の相関データなどを出してしまうと、更新率の高いセグメントが必ずしも理想的な使い方をしているわけではない（一定の利便性は感じてくれているのだとは思います）にも関わらず、思考が現状に引っ張られて、理想ドリブンで考えにくくなります。それは避けたいと思いました。
そして、カスタマーサクセスやプロダクトの理想を描くのは、私よりも日々探求し続けているCSやPdMのメンバーの方が断然解像度は高いので、理想ドリブンのステージ設計を考える段階でデータ分析は必要ないと考えました。
上記以外にステージ設計の議論で私が気をつけていた主な点は以下の3つを確認することくらいです。
Changeable
ユーザーのステージ（状態）を定義しても、その状態を変えられるような打ち手を考えられなければ意味がありません。そこで、個々のステージをクリアする施策・打ち手もセットで考えてもらうように議論を促したりしました。
また、ユーザーの状況によって、ステージを進められないケースが出てくるのであれば、ステージ定義を見直してもらう必要があると思います。
Shareable
ステージ活用を進めるためには、CSやPdMなどの関係者がステージによってユーザー状態を理解できる定義・数になっている必要があります。
ステージだけを聞いて、「あー、この状態まで使われてるのね」とみんながパッと理解できるくらいまで浸透するのが理想だと思います。数で言うと、プロダクトフェーズにもよりますが、ステージ5〜9が限界だと思います。ステージ数が多過ぎると覚えにくくなりますし、少な過ぎるとステージの中でも状態に幅ができて認識ズレの原因になります。定義については、『運用設計完了』『本稼働開始』など、一言で状態名称をつけてもらうと良いと思います。
Manageable
管理可能な粒度・頻度でステージが定義されているかという点も気にしてました。
同じステージ中でも詳細なユーザー状態を把握したいため、定義を条件分岐したくなるケースが出てくると思いますが、どちらにも同じ打ち手を打つのであれば、条件分岐による意思決定は変わらないため、分岐させない方が良いです。また、ステージ情報の更新頻度についても同様で、日次で打ち手を打つ or 打たないの意思決定ができないのであれば、日次の更新頻度は必要なく、週次 or 月次の頻度などでも問題ないので、オペレーション体制の話もセットで議論するようにしてました。
最後に、ステージ設計を考える段階では、ほとんどデータ分析は行ってきませんでしたが、ステージ定義がおおよそ決まった段階で、自分たちが考えているマジ価値や理想の使い方がユーザーに届いているのか、更新率などとの相関は確認しました。
結果として、相関は確認できましたが、ここで大事なのは綺麗な相関を追い求めることではなく、自分たちが考えたマジ価値や理想がどれだけユーザーに届けきれているかを理解することではないかと思います。もし、やや弱い相関なのであれば、「ユーザーにプロダクト価値をしっかり伝えきれているのか？」、「ステージ定義で考慮できてない点はなかったのか？」を考えて、進化していくことではないかと。
CSステージを作って良かったこと
ユーザーにとってのマジ価値と理想ドリブンでステージ設計した結果、向き合うべき課題がクリアになり、メンバーの腹落ち感は高いと感じました。当然と言えば当然ですが、理想から考えたので、現状とのギャップを明確に課題であると認識しやすかったです。
（KPI設計で良くある（？）「この機能の方が、もっとKGIに効くのでは？」みたいな追加分析の話も出てきませんでした👍）
もう一つ良かった点は、それまでCSとPdMで異なる定義で目標を立てていましたが、ステージが共通言語となり、同じ定義で目標が立てられるようになった点です。その結果、コミュニケーションスピードも上がり、より同じ方向を目指して活動に取り組めるようになりました。
ステージデータをどのように活用しているか
最後に、CSステージのデータとユーザーの属性データを組み合わせた活用事例を少しだけご紹介します。
KGIの先行指標
1つ目はKGIの先行指標として、ステージを活用しています。
具体的には、プロダクト導入Nヶ月目時点の各ステージ別にKGIの期待値を算出し、KGI達成のために必要なステージ推移をシミュレーションしてます。
例えば、契約更新率やNRRなどの結果指標は、何か施策を打ったとしても結果が分かるのは、数ヶ月後、1年後などになってしまい、PDCAサイクルをスピーディに回しづらいですが、KGI期待値が分かれば、施策のFBがより早く得られるようになります。freeeでもKGI期待値をベースに予実管理や上振れ/下振れの要因分析などを定期的に行ってます。
CSによるプロダクトへのフィードバックループの重要性は以下のnoteが参考になりました。
また、ユーザー個別のステージ推移と目標ステージ推移を比較することで、迅速なフォローアップも可能になります。
よりニーズの高いユーザーへの提案活動
2つ目の活用事例としては、CSハイタッチのニーズがより高いユーザーを推測し、オンボーディング支援などの提案活動を行ってます。
SaaSプロダクトに限らず、人が介在した支援がなくてもサービスを使いこなすユーザーもいるでしょう。もし、そういうユーザーに対して「私たちが丁寧に支援します！お時間をいただけないでしょうか？」と提案しても、ありがた迷惑になってしまう可能性が高いです。
一方、人が介在することでサクセスするユーザーもいるはずです。そのため、CSハイタッチのニーズがより高いユーザーを早く正確に見つけ出すことができれば、サクセスするユーザーを最大化できると考えてます。
また、この考えはオンボーディング支援だけでなく、他の自社プロダクトを提案（クロスセル提案）するケースにも当てはめて考えることができます。具体的には、他のプロダクトのニーズが高いユーザーを見つけ出し、提案することができれば、win-winの関係を構築できます。
今年もありがとうございました！
最後まで読んでいただき、ありがとうございました。
年に1度のアドベントカレンダーを通して、自分でも今年一年の振り返りができました。
CSやPdMのみなさん
サクサク分析を進めないくせに、色々な質問（指摘？）をしてしまった私を最後まで見捨てることなく、プロジェクトに参画させていただき、ありがとうございました🙇♂️🙇♂️🙇♂️
来年もデータの更なる有効活用を考えていきたいので、よろしくお願いします！
Analyticsチームのみなさん
ワクワクドリブンで分析テーマや自由研究テーマを決めていたにも関わらず、自由にやらせてもらったり、付き合わせてしまったり、日々感謝してます。ありがとうございます🙇♂️🙇♂️🙇♂️
来年は、よりAnalyticsチームやテーマの進化に貢献できればと思いますので、よろしくお願いします。
今年のアドベントカレンダーは、まだまだ続きますので、お楽しみにー
freeeは「あえ共freee」というマガジンから、freeeの事業や組織に関する情報を「あえて、共有」しています！ぜひフォローをお願いします(^^)
この記事が気に入ったらサポートをしてみませんか？