fbpx

                   CS BLOG CSブログ

CS BLOG CSブログ
               
  • CSコミュニティ
  • CSブログ
  • [イベントレポート] #CS寺子屋 Vol.5 〜豊富なデータによる客観的な裏付けをもとに、顧客レベルを定義するヘルススコア設計〜

[イベントレポート] #CS寺子屋 Vol.5 〜豊富なデータによる客観的な裏付けをもとに、顧客レベルを定義するヘルススコア設計〜

2023年7月21日にKOMMONSでは「豊富なデータによる客観的な裏付けをもとに、顧客レベルを定義するヘルススコア設計」というテーマでコミュニティイベントを開催しました。

  • データドリブンな他社事例を知りたい方
  • 顧客情報の収集・分析・可視化を通じた課題解決のヒントを見つけたい方
  • 顧客情報を活用して業務効率化を可視化したい方

上記に当てはまる方は、今回のデータ活用に焦点を当てたイベントレポートがお役に立てるのではないかと思います。当日参加できなかった皆様も、改めてイベント内容をおさらいしたい皆様もぜひご覧ください!

パネリスト紹介

株式会社カミナシ
細見優太(ほそみ ゆうた)さん

2022年よりカミナシにジョインし、カスタマーサクセスとして導入完了後のアダプションやエクスパンションを担当。食品工場やホテル業界などホリゾンタルな業界の日常業務のデジタル化を支援。

モノグサ株式会社
亀井 雄太 (かめい ゆうた)さん

2018年IBMに新卒入社。人事コンサルタントとして主に製造業のクライアントに人事制度設計などの支援を行う。

2020年にモノグサへ入社し、1人目のカスタマーサクセスとして組織の立ち上げを行った後、現在はBusiness Planningとして全体支援施策や新領域の仕組み化を担当している。

株式会社hokan
石野 太一(いしの たいち)さん

新卒でアフラック生命保険会社に入社。そこでエンドユーザーの保険体験におけるペインの多さに課題を感じ、hokanに転職。hokanではSMB〜エンタープライズの顧客対応/コミュニティマネージャー/CS Ops/人材採用や育成に携わる。

「ヘルススコアのしくじり先生〜もう一度0から考えるならこうやるかも〜」ーカミナシ 細見さん

私たちカミナシは、「ノンデスクワーカーの才能を解き放つ」をミッションに掲げ、工場や店舗などブルーカーラーと呼ばれるような現場のデジタル化を支援するプロダクトを提供しています。ITスキルがないユーザーでもノーコードでアプリを作ることができ、特定の業界に限らずホテル・食品・製造・物流など幅広く利用いただけます。それゆえに業務内容が違えば利用方法も異なり、再現性が高くないという難しさがあります。

本日は、ヘルススコアを設計して1年が経った今、やり直すならどうする?という視点でお話しします。

最初に結論をお話しすると以下の3点です。順を追って説明しますね。

  • ヘルススコアが悪化したらどう動くか?もセットで考えるべし
  • 最初は細かく作り込むべからず。プロセスデータの残し方も考えるべし
  • へルススコアと連動するKPIも最初に整備しておけば尚よし

こちらがヘルススコアを設計するまでの流れです。

Kaminashiをリリースして2年目に、一人当たりの案件数が増えたり、予測できない解約(びっくりチャーン)が増えたりということがありました。それから3ヶ月でヘルススコアの設計〜実装を行い、顧客対応の中で検証した上で改修し、今再び実証実験をしています。

まず最初に行ったことは「何のためのヘルススコアか?」という目的を定めることでした。私たちは「びっくりチャーンを察知できる」ことに絞りました。ヘルススコアの指標を考える上では、過去にチャーンした顧客のログやデータを眺め、見えてきた傾向値から10個の指標に絞りました。

次のステップとして各指標の重みづけを考える際に、「この指標が悪いとチャーンするよね」という感覚で判断し、それを元に割合を決めてダッシュボード化しました。これがヘルススコア第一弾です。
出来上がったヘルススコアは、大きく分けて、①顧客の体制 ②導入目的 ③顧客との関係性 ④利用率 という4つの軸があります。お客様がアプリを作るというプロダクトの特性上、学習コストやリソースもかかるため、顧客の体制づくりは特に重要視していましたね。

運用を検証する際は、スプレッドシートでスコアを可視化し閾値を超えると赤くなるようにしました。6ヶ月実施してみて分かったことが3つあります。

1つ目は、「スコアが下がった時のアクションをCSメンバーが想起できる状態にするべし」ということです。スコアを改善するために何をすべきか設計できておらず、スコアが単なる数値となってしまっていたのです。CSメンバーがアクションを想起しやすい工夫が必要だと感じました。

2つ目は、「スコアの信頼性は担保すべし」です。例えば指標の1つであるログイン率が下がった時に、繁忙期だからしょうがない、と判断するケースがありました。スコアの信頼性が担保されていないとスコアが形骸化してしまったり、主観での判断余地が生じてしまいます

最後が一番の反省点ですが、「CSメンバーの業務プロセスに配慮したスコアのフロー設計にするべし」と伝えたい。スコアの変数が多いと、データの収集やCSメンバーの対応ログの入力作業も大変になります。日常的な業務での運用が難しいと、せっかく設計しても机上の空論になってしまいます

それを踏まえて、今年4月から新しい取り組みを始めています。

まずは、NRRを頂点としたKPIツリーの策定を進めているところです。また並行してスコアの項目を追加するなど、プロダクト特性を加味したチューニングを行っています。CSメンバーが運用しやすいようにフロー設計も改善中です。

直近ではGainsightを導入して、CSメンバーが日々の対応記録を残し、それを見える化することにチャレンジ中です。また1年後くらいに経過をご報告できればと思います!(笑)

最後にあらためて結論をまとめます。これからヘルススコアを設計する方に少しでも参考になれば嬉しいです。

「作りっぱなしで終わらない、本当に使われるヘルススコアの作り方」ーモノグサ 亀井さん

モノグサは、教育業界を中心にご利用いただいているSaaSを提供しています。利用者が教育機関ということもあり、学校の学期に沿って契約期間が固まっているという特徴があります。新学期前の3月に契約開始・リニューアル、4〜6月にオンボーディング、7〜2月にアダプションを進めるという具合です。

ヘルススコアの話をする冒頭でこれを言うのもなんですが、ヘルススコアは作りにくいし、使いにくいと思っています。ある調査によると、ヘルススコア自体を作ったことがない企業が70%程度、作っていて見直せている企業は10%程度のみという実態があるようです。

今日の内容は、特に「ヘルススコアを作ってみたけど運用に載せきれていない方」に向けてお伝えしたいと思います。

まず、ヘルススコアが使われるには3年かかります。時間がかかるし億劫ではあるものの、やはりヘルススコアは作った方が良いです。弊社では、OKRの評価指標としていたり、Salesforce上のダッシュボードで毎週眺める機会があったり、来期のチャーン予測に役立てたり、株主定例との資料にも推移として示していたり、とヘルススコアが全社で利用する指標になっています

また弊社では、200点満点で換算されるヘルススコアと別に予測解約率を設けています。ヘルススコアはCSの行動指針に、予測解約率はForecast算出に活用しています。

これらは、最重要指標として置いているARR目標を達成するための中間指標として機能します。ARR目標から逆算して、予測解約率を使って達成すべきForecastを算出し、予測解約率を下げるためにヘルススコアをどれくらい上げるべきか、上げるためにどんなアクションをすべきか、とすべてが一本の背骨として通るように設計しています。

では、ヘルススコアが使われるようにするためにはどうすれば良いのか。まとめると「組織目標に紐づいた設計」「日常オペレーションへの組み込み」「スコアの信頼性の検証」の3要素になります。

どれも教科書的かもしれませんが、正直なところすべて実行するのは難しい。

例えば「組織目標に紐づいた設計」を取ると、事業やプロダクトのフェーズによって目標やサクセスの形が変わり続けるためコントロールできません。いきなり全ての要素を満たす、というのはハードルが高いので、注力すべきポイントを決めることをお勧めします優先度に応じて3要素を順に追っていくサイクルを3度回すことで、より筋が通った状態になると思います。

弊社は、ヘルススコアをこれまで年1回、計4回のバージョンアップをしてきました。

1年目は文字通り「肌感期」でした。プロダクトができた直後でデータやチャーン件数も少なかったため、主にオンボーディング完了有無の判定で使っていました。良かったのは、全員がどう考えても重要だと認識する指標にすること、Bizメンバーの肌感覚と合っていること、そして毎週更新することをめげないことでした。

裏返しになりますが、こだわりすぎて肌感と合わない指標を作る、無理やりオペレーションに組み込む、というのは、このフェーズでは避けた方がいいと思うところです。

2年目は「CS内の共通言語化期」でした。この時、CS内でリテンション率を持つことになり、”顧客がプロダクトを日常的に使えている状態” を前提に指標を作ったことで打ち合わせ資料にも使えるものになりました。半強制的にオペレーションに組み込んだことで、見るべき状態を作れたのは良かったと思います。一方で、プロダクトもまだ初期フェーズだったこともあり、このタイミングでのデータ分析は注力しないようにしました。

3年目は「全社活用期」と呼んでおり、結果指標との相関を見ながら全社で使うに値するものになってきました。この頃はリテンションだけでなく、アップセルもCSで担うことになったため、スコアが低いとチャーン、高いとアップセルが見込めるような設計を行いました。このフェーズになると、Devメンバーを巻き込みながら作りつつ、データ分析に基づく客観評価を適宜行いました。大量の指標から最終的に10くらいに絞り込む際に、CSが関与できないデータは除外することを意識しました。200点満点で先生用と生徒用でそれぞれ指標を作っており、週次でSalesforceのレポート上で指標の確認を行い、月次でチャーンとの相関を見ていました。

4年目は「数字へのコミット期」です。ヘルススコアに加えて予測解約率を算出し、Forecastの精度を高めることにコミットしています。分析は機械学習に頼っていることもあり、見栄えはできる限りシンプルな構成にしており、引き続き目標に紐づいた設計を行っています。

4年の検証を通して伝えたいのは、スコアではなくスコアの更新プロセスを定義しましょう、ということです。スコアは更新の度に変わりうるものですが、更新プロセスは型化してサイクルを回していくことが大事になるので、ぜひその点を持って帰ってもらえたら嬉しいです。

「プロアクティブなチャーン抑止アプローチに繋げるヘルススコア構築方法とそこから見えた社内のチャーン期待値調整の必要性」ーhokan 石野さん

株式会社hokanは、保険業界のスタートアップです。いくつかプロダクトがありますが、私が担当しているhokanは保険代理店向けのCRMです。ユニークな点としては、金融庁がトップにいる規制業界のため、単なる効率化だけでなく法律を遵守した上で、紙での作業がすべてシステム上で行えるというところです。

弊社で利用しているヘルススコアは、構築中も含めると3つありますが、本日はチャーンリスクを早期検知するための「顧客ヘルススコア」に焦点を当ててお話しします。現在、顧客ヘルススコアはスプレッドシートで見れるようにしています。

ヘルススコアの変遷について、我々も3つの期に分けてお話しします。

最初のヘルススコアが誕生したのは2020年8月(赤ちゃん期)です。スコアをベースとしたリスクフラグに該当しない企業でチャーンが発生したり、スコアと紐づいたアクションが明確でいなかったり、誰もヘルススコアを信用できていないという状態でした。

私が入社した後、2022年1月(幼少期)頃からヘルススコアの改善に着手していったという状況です。2023年4月(青年期)からはほぼすべてのチャーンをスコア上で予測可能になってきています

ヘルススコア構築までのフローは、前の2社と同じような流れで進めました。

まずはDEARフレームワークというフレームワークに沿って指標を洗い出したあと、データの取得が難しかったり目的にそぐわないものを除外していき、ロジックを作って検証・レビューしたものを運用するという具合です。

細かい指標は以下のスライドを見ていただければと思いますが、1つ特徴としてあるのは、ヘルススコアにROIを組み込んでいないという点です。エンタープライズ企業においてはQBRにおいてレポーティングを実施しています。

※ QBR (Quarterly Briefing Review) :四半期毎に顧客とカスタマーサクセスの間で行う会議。顧客の状況、および顧客を支援する方法について議論する。


構築時のポイントとしては3点にまとめられます。

①精度にも限界があるのでなるべくシンプルに
データを集めているとヘルススコアに多くの活用目的を乗せたくなりますが、メンテナンスコストがかかりますし、どのCSが見てもロジックを含めて容易に理解できて、信頼できて、かつ活用できるものである必要があります

②ユーザーの利活用状況を一目で読み取れるような分布が見れると良い
弊社のスコアは4段階評価で、各評価の分布をスコア上で色分けして資格的に分かるように工夫しています。細かい各社のスコアまで見らずとも、全体分布の崩れからユーザーの利用状況の変化を読みとり、一定の仮説を持って担当CSMやユーザーに状況確認ができるようになっています

③ヘルススコア設計プロジェクトの体制はしっかり構築するべし
弊社ではヘルススコア幼少期に入るタイミングから、ヘルススコア構築プロジェクトへエンジニアに入ってもらい、CSは常にロジックの精査とアクションに集中できる体制を構築できていたのは良かったと感じます。

ここからは、具体的にスコアを活用してどのようなアクションを取っているか?についてもお話しできればと思います。

エンタープライズ、SMBでそれぞれアクションを変えているのですが、エンタープライズでは主に活用状況をウォッチする目的で運用しています。サクセス状況を確認するMTGで、拠点単位のスコアを参照し、先にお伝えしたようにQBRでのレポートへ反映するなどをしています。

SMBでは、主にチャーンリスクを検知する目的で運用していますね。参照するタイミングとしては、週次MTGや顧客と接点を持った時で、月次で半年以内に契約更新を迎える企業でリスクがある企業を判定してハイタッチ対応に切り替えたり、スコアに変化があった企業をチェックして担当者から状況を伺ったり、といったアクションを取っています。

ヘルススコアを構築して得られた成果は2つあり、1つは低いチャーンレートの維持です。プロダクトの性質上チャーンレートは低めですが、導入社数やID数が倍増する中でも、チャーンレート0.13%という低い水準を維持できています。

もう1つは、社内におけるチャーンに対する期待値調整です。お伝えした通り、チャーンしづらい性質があり創業期に大きなチャーン実績もなく、会社全体で継続利用への期待値が高かったんですね。スコアを構築したことで、チャーン発生パターンの創出と、パターン内でのリスクマップを用意し、経営層に事前共有することで期待値調整にも繋がりました。チャーン発生パターンを整理すると、外部環境要因でCSではどうにもできないというケースもありました。それに対するプロアクティブなアクションを整理した上で回避することの難しさを経営層に発信し、納得してもらいつつリソースの最適化を図っていきました。

▼チャーンのパターン化とリスクマップ

その結果、チャーン回避余地がない顧客へCSが無駄に工数を割いたり、必要以上に精神的に凹んでしまう必要がない環境を作れたのは良かったと思います。

本日の内容が、これからヘルススコア設計に取り組もうとされている方に少しでも参考になっていれば幸いです。

本イベント内容についてより深く知りたい方はコミュニティにご参加ください!

本イベントのアーカイブ動画はCS KOMMONSのコミュニティメンバーに限定公開をしています。
イベントレポートを読んで、より具体的な話を登壇者から聞きたい方や、イベントに参加したけれども振り返りをしたい方は、ぜひコミュニティにご参加ください。すでにコミュニティに入っている方は、コミュニティポータルサイトのイベント一覧からアーカイブ動画をご覧いただけます。

カスタマーサクセスで副業案件に挑戦するならKOMMONS

株式会社KOMMONSは「働くを、傍楽(ハタラク)に」というVisionの元、国内最大級のカスタマーサクセスコミュニティを基盤に、カスタマーサクセス特化型の業務委託人材のマッチング・コンサル支援サービスを提供しています。

急速に拡大しつつあるカスタマーサクセス市場において、即戦力の人材を採用するのは非常に困難です。弊社では、オンラインコミュニティに登録する1,000名以上のカスタマーサクセス人材に向けて、カスタマーサクセスの副業案件を紹介しています。

また、カスタマーサクセスの副業案件に興味をお持ちの方に向けて、経験豊富なKOMMONS担当者による1on1のお悩み相談や採用面談フォロー、副業案件着手後のフォローも可能です。副業先との採用面談をする前のプロセスから寄り添うことで、カスタマーサクセス人材の成長に伴走し、必要に応じて適切なスキルセットの案件を副業・業務委託・転職といったさまざまな形で紹介することができます。カスタマーサクセスの副業にご興味がある方もぜひこちらからコミュニティにご参加ください