見出し画像

"ヘルススコア"という甘いアイスクリーム

かじ | LayerX PdM & CS

こんにちは。LayerXバクラク事業部で現プロダクトマネージャー、春までカスタマーサクセス部のマネージャーを務めていたかじ(@kajicrypto)です。

ここ3ヶ月ほど、ヘルススコアについて相談したりされたり実際に自分で手を動かすことも多くあり、よく思っていたことを自分の脳内整理のためにアウトプットします。

勢いでばーっと書き出したもので丁寧なnoteではないので、結論だけ知りたい方はこの2つのポストをご覧ください。


ヘルススコアの罠

”ヘルススコア”

カスタマーサクセスについて学び始めるとゲシュタルト崩壊するほど出てくるこの言葉。

たくさんの変数を比重を加えながら組み合わせて、全お客様のヘルシー度合いを点数化ないし緑黄赤に可視化でき、そこから解約防止やエクスパンションの種をある程度見つけることができる、らしい。

とても魅力的で、顧客数が増えて全社にハイタッチして状況把握することが難しいフェーズに入ったCS組織は、必ずこのヘルススコアを求め始めます。それは活動として正しいと思います。

ただし、とても注意深く取り掛からないと、すぐにヘルススコアの罠に陥ります。そういう話もよく見受けるように思うし、僕も罠とわかりつつえいやで飛び込んで何か変わるか確かめたこともあるけど、やっぱり罠だった、と思っています。

それは何かというと、ヘルススコアのスコアリングロジックを考える作業自体が楽しいということ。そしてその作業は、必ずしもお客様への活用促進に直結しない、むしろ遅らせているということです。

ヘルススコアの魅力に取り憑かれて、良さそうなヘルススコアを作ることが目的として作業が先行してしまうのです。

具体的にヘルススコアを作ろうとするとこんなことをすると思います。

  • データソースを整えたり

  • 契約情報とプロダクト利用データを統合したデータ基盤を作ったり

  • BIツールを入れて個社別の状況を可視化していったり

  • DEARフレームワークなどを参考にしながら重要そうな変数を洗い出して

  • ハイタッチからの定性情報もどう足すか検討して

  • 定性情報をできるだけ数値化するためにNPSを取ったりCRMの入力項目を増やしたり

  • QBRのタイミングでお客様ミーティングを増やしてヒアリングしたり

  • 解約アンケートを設計したり

  • 過去の解約を時期別セグメント別利用状況別に分析したり

  • こうやって洗い出した情報をもとにどの変数を採用して、どれくらいの比重にして、どう点数化するか考える

この作業、ヘルススコアを作りたいといって取り掛かるデータや数値が好きな方からすると、とっても楽しいと思うんです。難しいけど出来上がったらすごい効果を出しそうだし、この複雑性こそが面白さだし、カスタマーサクセス組織が次に進むために絶対に必要なパーツだと思いたくなります。

でも、実際やってみると上に書いたような方法ではめちゃくちゃ難しいしたくさんの人の力が必要だし時間がかかる。気付いたらデータを見たりスコアリングロジックを考える時間が増えて、お客様に向かう時間がどんどん減っていく。振り返ると、良さそうなヘルススコアを作ることが目的になっている。

ヘルススコアに求める成果は、お客様の状態を可視化して、アラートを出して、お客様に対してアクションして、結果としてお客様の利活用が進んだりKPIに跳ねることだと思います。

上に並べた作業をしている間、お客様に対するアクション、1つもやっていないんですよね。これが罠です。

利用状況アラートという代案

手段の目的化を防ぐためにはヘルススコアをなぜ作るのかが大切です、という話ではあるのですが、それを具体的にプロセスに落とすとどうなっていくと考えているかを書いていきます。

ヘルススコアについて聞かれたら、僕はいつも利用状況アラートという代案を提案します。

まず、”ヘルススコア”といういかにも甘くて美味しいアイスクリームみたいな単語は忘れてください、そんなものは幻想です。

ヘルススコアを作って何をしたいかというと、たいていの場合CS組織のKGIはNRRになっていて、NRRを分解するとKPIとしてChurnMRRとExpansionMRRが出てくるので、ヘルススコアによってチャーン予備軍を見つけたり、アップセル/クロスセルできそうないい感じのお客様をpickupして、何らかの形でアクションして、結果としてお客様の行動が変わり、KPIに繋げることだと思います。

仮にここに12個の変数をきれいに組み合わせたヘルススコアがあったとします。定量情報も定性情報も入っていて、日々自動で更新されて、点数化もされていて、緑黄赤の変化した際のアラートも出るとします。素晴らしいと思います。

さて、実際にあるお客様が緑から黄に変わってアラートが出たとき、どういうことをするでしょうか。

なぜ黄に変わったのか、12個のうち何の変数がどれくらい悪くなったのか、結局個社別の利用状況の詳細を確認しにいきませんか？そうしないとお客様への正しいアクションを判断できないからです。

そしてそれが分かったら、状況に合わせてサポートするメールを送ったり、使ってもらいたい機能のガイドを送ったりしていくと思います。

・・・ここで気付きます。

結局お客様の行動を変えるためには、アラートの中身を変数1つのレベルまで確認して状況に応じたアクションを取るので、ヘルススコアとしてどんな変数をどういう比重で組み込むかとか、それを作るためにデータをいろいろ掛け合わせられる基盤を作るとか、不要だったんじゃないかと。

「いやいや、作らないと緑から黄をそもそも検知できないじゃないですか！」という心の声が出てきます。

それは12個の変数をかけ合わせた複合的なアラートである必要がありますか？1つ1つの利用状況についてそれぞれ簡単にアラートを作って検知するのと違いますか？むしろ1つ1つのほうが作るのも簡単だしお客様にアクションするまでが早くないですか？

「いやいや、利用状況アラート12個も作ってアラート出されても結局アラートが出過ぎて管理できないし、どれが重要かを判断して活動に優先度をつけるためにヘルススコアを作るんですよ！」という声も聞こえてきます。

その優先度をつけていく過程って、結局1つ1つのアラートについてお客様にアクションをとって、お客様の行動が変わったかをモニタリングして、アラートが本当に機能するものかどれくらい重要なものかを判断して組み込んでいくわけですよね。

もちろんデータで見えて決まるものもありますが、実際のデータからCSMが想像する状況とお客様の状況が違うことは多々あるので、優先度付けのプロセスは机上で考えていても答えは簡単に出るものではありません。

優先度は実際にアラートが出たお客様に対して地道にアクションして振り返った結果として見えてくるものです。ヘルススコアが優先度を示すのではなく、優先度は1つ1つの利用状況アラートから導き出されて、それをより効率的に可視化するためにヘルススコアがあるのです。

しかも、12個のアラートが出ても管理できないのだとしたら、そもそもそのヘルススコアも12個の変数をかけ合わせている意味がないですよね。6個でいいのではないでしょうか。

ということで、まず分かりやすいデータやハイタッチの結果見つけた重要そうな値から利用状況アラートをシンプルに出し、お客様にアクションを取りながら正当性を確認していく。

求めるKPIの結果に対してアラートが1つで足りなければ2つにしその2つのアラートに対するアクションをやり切る。それでも足りなくなれば3つ目、4つ目と増えていくわけです。その過程で、どっちのアラートのほうが”やばそうか”など探りながら優先度はついていきます。

アラートが出てもアクションしきれないほど多くの変数を組み込んだヘルススコアはどれだけ頭が良くてすごそうに見えても、お客様に何も価値を提供するものではありません。

すごいヘルススコアを作ることよりも、1つ1つの利用状況アラートを出すことと、それをやり切ることがずっと大切だと考えています。

※ 言葉として利用状況アラートと言っていますが、プロダクトの利用データに限らず、お客様と連絡がすぐに取れるかどうか、決済者と会えているか、などの定性情報も含んで良いと思っています。

ヘルススコアは”できあがっていく”もの

そうして利用状況アラートを正しく積み上げていった結果、できあがるものがヘルススコアと呼ばれている概念が指すものだと思います。

様々なアラートが出て、そこには優先度がついていて、上からできるだけアクションをやり切って、お客様の行動を変える。ヘルススコアを作ったときに結果として取るアクションと同じではないでしょうか。

その上で、アラートを”複数種類かけ合わせて”優先度を決めてネクストアクションを自動的に見える化するとか、お客様数が数千社になってきてもっと効率的にデータを見れるようにするなどの重要性が増してきたら、いわゆるヘルススコアを作ると良いのではないかと思います。

ヘルススコアは”作る”ものではなく、お客様のサクセスを求めて1つ1つのアラートに向き合って泥臭くアクションを続けた結果”できあがっていく”ものだと思っています。

もちろんそれには時間がかかるので最初にデータや感覚からえいやで変数を決めて動くことはありますが、それはヘルススコアとは呼ばず、仮説検証中のアラートです。

甘い誘惑を断ち切り、泥臭いアクションをやり切っていきたいと思います。

まとめ