見出し画像

事業成長を高速化する「ヘルススコア設計」について

こんにちは、freeeカスタマーサクセスで企画・戦略を担当しているtaroです。
今日から始まるfreee Success Advent Calendar 2021の第一日目を担当します。他の日も面白い記事がたくさんになる予定なので乞うご期待ください。

さて、初日となる本記事では「ヘルススコア」についてお話します。私はfreee会計というプロダクトのヘルススコア設計・運用に行いはじめて1年半ほど経ちます。その中でSaaSビジネス、カスタマーサクセスにおけるヘルススコアの奥深さを感じてきたので備忘録がてらにまとめて置こうと思います。

ヘルススコア設計に悩んでいるカスタマーサクセス担当者の方、freeeのカスタマーサクセスがどんなことに取り組んでいるか興味がある方にとって、参考になる記事になれば幸いです。

ヘルススコアに関する情報は意外と少ない

多くのSaaSプロダクトのカスタマーサクセスにおいては、「churn rate改善」「契約更新率向上」を事業上の重要な結果指標(以下、KGI)においています。最近はそこにアップセルクロスセルの要素を加えたNRRの向上を重要視する流れも強くなってきていますね。

そうしたKGIの達成のために行われることに「ヘルススコア設計」があります。このヘルススコアをより効果的に運用するためにどんな事が重要なのでしょうか。

「SaaS ヘルススコア」みたいなワードでググってみるといくつか記事は出てきます。次のような記載がされていることが多いです。

ヘルススコアは効率的なユーザータッチに役立つから作るべき
指標は測定可能であるべき、指標は多すぎないほうがよい
例えば次のようなものが有効である
・ログイン回数
・担当者のNPS
・利用状況
・ライセンス数

これらはもちろん正しいことではありますがヘルススコアをどう構築するかの直接的な答えになっていないようにも感じます。

カスタマーサクセスはPDCAサイクルが回りにくい

カスタマーサクセスはKGIに対する因果が紐解きづらく、それによってPDCAサイクルを回すのが難しい領域です。これは次の2つの観点から説明することができます。

①時間軸の長さ

1つ目がKGIが出るまでの時間軸の長さです。
大きく分けるとユーザーに価値が届くまでのリードタイム、そして契約更新タイミングまでのリードタイムです。BtoBにおいては年間契約は一般的であり、複数年の契約単位になっていることも珍しくありません。
例えば、1年契約のユーザーが多いプロダクトの場合、特定の時期を境にchurn rateが上がったときに振り返るべき期間が1~2ほど年になります。「1年前ってどんな施策やってたっけ」と考えることは日々状況の変化するベンチャーにとってはかなり難しいことです。土曜日の夕飯が何だったかを思い出すことより10倍くらい難しいです。


②変数の多さ
カスタマーサクセスはバリューチェーン上の最終工程にあり、プロダクト、マーケ、セールスなど上流工程の影響を強く受けます。ユーザー体験につながる全ての要素の答え合わせが、カスタマーサクセスのKGIに現れると言っても過言ではありません。

例えばユーザーがchurnした際に原因には次のような原因が考えられます。
・カスタマーサクセスの支援は十分か
・プロダクトの価値は十分か
・セールスの獲得プロセスには問題はないか
・正しいマーケットを攻めることができているか
・プランプライシングは妥当か

もちろんそれぞれの要素は更に細かい変数に分解されます。更にその多くの要素が複雑に絡み合い、ユーザーの体験を構成しています。


このように1年以上の長期間で多くの要素から何がKGIに最もクリティカルな影響を与えたかをを特定することは簡単ではありません。
とはいえ、「なぜ悪化したかわかりません」「よくわからないけど数字が良くなりました」なんてことを言っているとPDCAサイクルが回せません。SaaS隆盛のこのご時世に置いていかれてしまいます。
そうなると定量的なファクトを待たず定性情報を元に意思決定する、という判断もありえますがそうすると意思決定の精度、説得力は落ちてしまいますよね。

こうした構造的な課題がカスタマーサクセスという職種においてはあるように考えています。そこで重要になるのがKGIの先行指標になるヘルススコアを設計することです。

ヘルススコアを設計における3つのポイント

有効なヘルススコアを設計する上で意識するべき3つのポイントを記載します。もちろん「測定可能である」のようなことは前提とした上で、より実践的に事業の課題解決につながるヘルススコア設計をする際に必要な点をまとめたつもりです。

1.プロダクトが届けたい価値に表した指標を置くこと
1つ目がプロダクトが届けたい価値を表していることです。
プロダクトビジョンが明確になっていれば、サクセスがユーザーに届ける価値は既に言語化されているはずです。(されていなければそこから考えたほうがよい)その価値が届いている状態を定量的に表わしたものを第一の指標の候補にすることが良いと思います。
そうすることでよりユーザーの価値にフォーカスしたサクセス活動が行えるようになるためです。
例えば、ログイン回数やNPSなどを単体でヘルススコアとして扱うことにはリスクがあります。ログインはあくまで手段に過ぎず、NPSは結果的に上がる指標に過ぎないからです。それらを指標として置き、上げることにフォーカスするといわゆる、「指標を上げるためだけの活動」になってしまいがちです。

2.KGIとの相関性が強い指標を置くこと
2つ目に重要なことがKGIとの強い相関性があることです。相関関係とは、一方が増加するとき、他方が増加もしくは減少する傾向が認められるという、二つの数値の関係性のことです。例えば、KGIがchurn rateである場合、ヘルススコアが上がればchurnは減り、ヘルススコアが下がればchurnが増える、という関係性が強ければ強い方がよいです。
SaaSプロダクトを立ち上げて複数年たったいれば既に契約更新を行ったユーザーが現れているはずなので、どのような利用状況だったユーザーがどの程度契約更新したかは機械的に算出できます。
また、KGIとの相関性があることが分かった場合、KGIにどの程度先行して現れるかという点も重要です。例えば、churn rateと相関が強いが契約更新直前にならなければ結果の出ない指標、のようなものは使いにくいです。churnを事前に予測してアクションすることができないため、ヘルススコアが変動した際にはすでにchurnが確定している、ということが起きかねません。

3.ヘルススコアがユーザーの実態と合致していること
最後にそうして設計した指標がユーザーの実態と本当に合致しているのかは丁寧に照らし合わせる必要があります。
このときに特に注意してみるべきは「ヘルススコアは良いが、churnしている」「ヘルススコアが悪いのに、契約更新している」という例外的なユーザーの存在です。そうしたユーザーのなかにはヘルススコアが実態を捉えきれていないケースが存在することが多いです。そうした例外からヘルススコアの改善点を集めアップデートをしていくことが重要です、
こうした例外パターンはついては最初は割り切って、時間をかけてヘルススコアを運用しながら細かい定義をブラッシュアップしていくことをおすすめします。実際freeeでも2年ほどかけて細かなバージョンアップを続けてきましたが、今でも実態と合致していない部分があります。

ヘルススコアを設計する5つのプロセス
実際に上記のポイントを意識しながらヘルススコアを設計するプロセスの例を記載します。ここはプロダクトの特性等によっても変わる部分ではあると思います。

~ヘルススコア設計のプロセス例~
①カスタマージャーニーを描く
・プロダクトが最も届けたい価値、ゴールを設定する
・それに至るまでユーザーはどのようなジャーニーをたどり、プロダクトの利用を進めるかを検討する
②カスタマジャーニーを複数の段階に区切り、定量的に表す
・ジャーニーをユーザーのステータスで分解して複数のステップに分ける
・それぞれのステップを定量的な指標で表す
③各段階ごとの事業上の重要な指標との相関関係を算出する
・それぞれのステップにいるユーザーとKGIの関係性を算出する
④定量的な指標とユーザー実態の整合性確認
・定量的な指標を満たすユーザーは実際にはどのようなステータスかを確認
・例外ユーザーはいないか、どのような要素を考慮できていないかを確認
⑤運用しながら改善サイクルを回す
定期的な見直し、ブラッシュアップの実施

↑のプロセスでは①②で「プロダクトが届けたい価値に表した指標」であることを担保し、③で「KGIとの相関性が強い指標」であることを担保し、④⑤で「ヘルススコアがユーザーの実態と合致していること」を確認しています。

こうしたプロセスでヘルススコアを設計することができれば前章で話したカスタマーサクセスの構造的な難しさを超えて、高速でPDCAサイクルを回すことができる組織を作ることができると考えています。
では実際どのようにこうして設計したヘルススコアをどのように運用していくとよいかを次章で記載します。

ヘルススコアがもたらす事業への変化


1.ヘルススコアからKGIを予測し早期の意思決定を行う
KGIと相関の強いヘルススコアを設計することのメリットは、未来を予測し意思決定までのリードタイムを短縮できることです。
例えばchurn rateをKGIとしている場合、ヘルススコアを元に次のような計算式でKGI着地予測が可能になるイメージです。

churn rate予測値=
(各ステップのユーザー数(もしくはARR)×ステップごとに想定されるchurn rate)の総和

これが精度高く実施できれば、本来的にはカスタマーサクセスが難しいような定量的なエビデンスを持った早いPDCAを回す事業運営が可能になると考えております。
そうすれば、ざっと考えるだけで次のような利点があります。
・churnを生まないためにOnboardingの適切なゴールをどこに置くべきかを明らかにすることができる
・事業インパクトから逆算してどのようなユーザーにどのくらいリソースを投下すべきかを判断することできる
・どんなステータスになればアップセルクロスセルが生まれやすいかを明らかにし、NRR向上につながる
・獲得方針や獲得プロセスに対する早期のFB
・プロダクトアップデートがもたらす事業インパクトの早期特定

虫の目で見れば、次のようなことも可能です。
・個社別のchurnリスクの機械的な早期発見
・個社別のトスアップ予知の機械的な早期発見

2.プロダクトチームと一体になって、ヘルススコア向上を目指す
プロダクトが届けたい価値に表した指標にできていれば、プロダクトチームとカスタマーサクセスチームが強固なひも付きを持ってユーザー体験の向上にフォーカスできます。
カスタマーサクセスとプロダクトチームは連携すべき、ということはよく言われることですが、連携に悩んでいる方は多いのではないでしょうか。その主なの根本原因に「CSが事業目標、プロダクトが機能開発という別の目標を追っているから」というものがあるのではないでしょうか。
前章で記載したようなKGIと相関がある&プロダクトが届けたい価値に表したヘルススコアができていれば、そのヘルススコアの向上にフォーカスできるようになります。プロダクトチームはヘルススコアを上げるためにどのような機能開発が必要か、カスタマーサクセスはその機能価値をどう届けヘルススコアを上げるか、そのようなwinwinの協業関係をつくることにも寄与すると思います。
私はカスタマーサクセス及びSaaSのおもしろさはこのようにプロダクト進化、事業成長、そしてユーザー体験の3つを1つの物差しで捉えられることにあると思っています。


最後に

私達がこれほどヘルススコアを重要視するのは「スモールビジネスを、世界の主役に。」というミッションを実現するためです。freeeは基本的にホリゾンタルSaaSを扱っているにも関わらず、「スモールビジネス」とターゲットを明記しています。これはスモールビジネスの皆さんに価値提供することにこだわりの現れです。(この辺りのこだわりは直接話しましょう!)
言ってしまえば、本記事で記載したようなヘルススコア設計・運用は多くのユーザーにハイタッチでアカウントマネジメントができるような規模の顧客を対象としたSaaSではそれほど必要でない場合もあります。(ある程度定性情報で状況を把握できるため)
しかしあくまでfreeeはスモールビジネス、SMBの市場と向き合っています。全国に170万社あると言われるスモールビジネスを変えるためには、機械的なユーザー把握と最適なリソース配分が重要となります。私は本気でミッションを実現するために、こうしたヘルススコアを通してユーザーと強く向き合っています。

ここまで偉そうに書いてきましたが、freeeのカスタマーサクセスチームでも上記にあることを全て実践できているわけではありません。むしろ、やりたいことも課題もたくさんあるのに完全に手が回っていない状況です。ヘルススコアはあくまで意思決定を早めるための材料にすぎず、ダイナミックな進化を推進する仲間がいなければ全く意味がありません。

ということでfreeeカスタマーサクセスチームでは一緒に働く仲間を募集しています。
ということでここまで読んでいただいた方でfreeeのカスタマーサクセスに少しでも興味がある方、ヘルススコアについて語りたい方はお気軽に以下よりコンタクトをください!

私のツイッター@tarocha1431宛にDMいただいてもOKです!
単純にサクセスについて語りたい!というだけの方も歓迎です。

また今日からスタートしたfreeeカスタマーサクセスアドベントカレンダーはまだまだ続きます。12/25までぜひぜひよろしくお願いしますー!



この記事が気に入ったらサポートをしてみませんか?