見出し画像

ヘルススコアは手段なんだなぁという話(hokanでのヘルススコア構築事例を添えて)

皆様こんにちは!
適正な営業活動と組織の強固な監査体制を実現する
クラウド型保険代理店システム「hokan」を提供する株式会社hokan カスタマーサクセスの石野です!

ご縁があり、社外でヘルススコア構築に関してお話をさせていただく機会があり、これまで私が社内で実施してきたヘルススコア構築やそれを活用した活動をせっかくの機会なのでまとめようと思いこの記事を執筆しています!

以下のような方にとって少しでも参考になる情報をお伝えできればと思います!!
・ヘルススコアを作ってきたい(改修したい)と考えている方
・ヘルススコアを活用したアクションのイメージがわかない方
・ヘルススコアっているんだっけ?っていう疑問をお持ちの方


具体的な内容に移る前に、、
hokanという会社と現在リリースしているプロダクトに関して簡単に紹介させていただきます。

hokanの会社とプロダクト紹介させてください

弊社株式会社hokanは保険代理店様向けのCRMを提供しているいわゆる「バーティカルSaas」企業です。

日本の保険業界は60兆円という超巨大産業で、日本人の8割以上の方が保険に加入されています。

この記事を読まれている皆様も現在もしくは過去、なんらかの保険に加入されたご経験があるかと思います。
将来発生しうる何らかのリスクをヘッジする手段として保険を選ばれていると思うのですが、みなさまは今心から「安心している」と言えますでしょうか?

おそらく答えは「わからない、、」ではないでしょうか?
多くの一般消費者の方はご自身の加入されている保険に関して内容はおろか、毎月いくら支払っているかもわからない方が非常に多くこの、知っている人は知っている(保険会社サイド)知らない人はとことん知らない(一般消費者サイド)という情報の非対称性が大きな課題であり、その課題を解決し業界をアップグレードさせることが我々のミッションです。

そのための初めの一歩がこの業界の保険会社と一般消費者の間に立つ「保険代理店」へのシステム提供であり、そのほか様々な角度からこの業界の課題に切り込んでいます。

と前置きが長くなりましたが早速我々hokanのヘルススコア構築のこれまでをお話しできればと思います。

hokanでのヘルススコア構築方法

現在活用中のヘルススコア

弊社では現在以下のヘルススコアを活用(構築中)です。

少しだけですが、物もお見せします!

チャーン予測のための顧客ヘルススコア


拠点別ヘルススコア(こっちはサンプルです)

とこんな感じ!
現在スプシで構築したものとヘルススコア用のシステムで構築したものを並行稼働させている状況で、今後はシステムに1本化していく予定です。

hokanヘルススコアの変遷と構築に動いた課題感

弊社でのヘルススコア構築は以下のような変遷を辿っています。

これを執筆している2023年7月現在まで大きく分けると3つの期から成り立っていると考えています。

実はhokanではプロダクトの正式リリースの直後からヘルススコアは存在しておりました。(私がhokanに入社する前からありました)
しかし、以下のような課題がありヘルススコアを0から作り直すレベルの改修をかけることを決意いたします。

・簡単なリスクフラグが付くスコアだったが、リスクフラグ外からのチャーンが発生していたこと
・スコアを活用したアクションが明確でなく、有形無実化していたこと
・そのロジックや正確性への疑問からCSMが信頼して参照できる手段になっていなかったこと

結果からお伝えすると、現在お申し出をいただくチャーンのご連絡はほぼヘルススコア上最もリスクがあると整理している顧客からという精度で予測ができており、プロアクティブな対応が実施できているため、顧客数やID数が爆増している現在においても変わらず低いチャーンレートを維持しています。

この現状に至るまでのお話を以下に記載します!

ヘルススコア構築のフロー全体像

弊社の現在のヘルススコアは以下のようなフローに沿って改修を実施しています。
1️⃣DEARフレームワークに沿って指標を洗い出し
2️⃣データの取得不可、目的にそぐわない項目の消去
3️⃣ロジックの構築と重みづけ実施
4️⃣ユーザーデータのテストプロットしての検証
5️⃣CSメンバーからのレビュー
6️⃣レビュー内容を踏まえての微修正

必要項目の洗い出し

CS経験者の皆さまにはお馴染みかと思いますが、弊社でもDEARフレームワークに沿って必要な指標の洗い出しを実施しました。

Deployment
→プロダクトの利用をする上で、理想的な環境かどうか
Engagement
→顧客との関係が良好であるかどうか・顧客のhokanへの関与度
Adoption
→プロダクトの利活用状況が良好かどうか
ROI
→顧客がサクセスしているかどうか

なお、弊社におけるAdaptionはいわゆる「ライトサクセス」「ディープサクセス」でいうところの「ライトサクセス」状態における各種機能の活用状況を定量的にhokan側で基準値を置いたものを適応しています。

構築時のポイント

改修当時はさほど強く意識していたわけではないのですが、今振り返ればポイントであったと感じている点があります。

1つ目は「シンプルであること」
いろんな指標を出して、データを集めて、ロジックを組んでとやっていると元々は「チャーンの発生を事前に予測する」という目的で始まったはずのプロジェクトに、あれもやりたい、これもできるかもと様々な目的が乗ってきてもりもりのゴリゴリになりがち?ではないかと

ヘルススコアはあくまで手段ですので、初期に認識されている目的及び目標からブラさず、以降のメンテナンスコストやどのCSMが見ても容易に理解でき信用できるような「シンプルなヘルススコア」であるべきかと考えます。

2つ目は「分布の参照ができること」
弊社では最終的なスコアを4段階評価でプロットしているのですが、その4段階の適正な割合分布が存在し、そこからの乖離は「なんかあるぞ」というシグナルになっています。

顧客との打ち合わせ前などに個社のスコアを参照することはあるかと思いますが、毎日すべての顧客のスコアを参照することは難しいですよね。

全体分布割合を表示させ、その自社における適正値を把握しておけばその乖離に何らかの事象を認知することができるはずです。

実際弊社でも私は細かくこの分布を確認しており、その割合の変化から中長期的なリスク事案を検知でき、大きな影響が出る前にアプローチを実施できた過去があります。

3つ目は「然るべきメンバーを巻き込みプロジェクト体制を構築すること」
CSチーム内でヘルススコア構築をリードされる方がいらっしゃって、サポートとして他のCSメンバーの方が入られるケースがあるかと思いますが、弊社の場合は構築初期よりエンジニアのメンバーを1名巻き込み(現在は2名体制)プロジェクト体制を構築しての実施としています。

構築のロジックやそのアクションはCSのリード人材が実施すべきかと思いますが、実際構築に際してのデータ収集などでSQLを叩かないといけない場面、エンジニアのリソースを投下しなければならない場面が出てくるかと思います。

弊社ではCREというチームがdivサイドに存在しており、顧客のテクニカルな課題を解決したり、データ周りの整理、移行などを実施してくれておりました。 そのチームの1名に声をかけ、ヘルススコア構築のメンバーに参加してもらい、データの集約とスコア構築の裏側を一挙に担ってもらっています。

当時は「ちょっと手伝ってよ〜」ぐらいのノリではあったのですが、プロジェクトで役割を分担し、高速に構築と改修を繰り返しながら、ヘルススコア自体の有用性をチーム内外が認知してくれる中で、正式にエンジニアの一定リソースをヘルススコア構築、改修に割いてもらう環境を作れています。
(現在では、そのメンバーのOKRにはヘルススコアの構築と改修に関しての項目が入っています)

ヘルススコアを活用したアクション

ヘルススコアは「チャーンの発生を事前に予測する」ための手段、もっと言うと中長期的に発生しうるチャーンのリスクを最小化するアクションに繋がっている必要があります。

本来的には、テック/ロー/ハイタッチの施策にうまく連動し(特にテックタッチ周り)効率的、かつ効果的なアクションにつながっている必要があると思います。

弊社はまだこの点に課題があり、これからテック/ロー施策との連動を設計していく状況なのですが、現在のアクションを以下の通り記載します。
なお、弊社はCS組織内にエンタープライズチームとSMBチームに分かれているためそれぞれの観点で記載します。

エンタープライズチームの活用

弊社の場合エンタープライズ顧客へはQBRや定例MTGなどで、意思決定者層、プロジェクトマネージャー層含め細かい接点が確保できており、スコア以上に定性的な情報を常にEPCSチーム内で咀嚼しながらリスク判断ができているため「ヘルススコアだけを参照してのチャーン予測」は実施していません。

保険代理店様には全国各地(もしくは特定のエリア内)で複数の支社、支店を展開しており、導入/活用プロジェクトメンバーが所属していない拠点や利活用上のキーマンが所属している拠点の活用状況が見えず、アプローチの実施や時期を逃してしまうことが多く、EP CSチームでは拠点別のヘルススコアを参照し、拠点ごとのスコア差分などから示唆を見出したり、利活用向上のアプローチを実施したりしています。

など、ヘルスススコアのデータはQBR実施時のレポーティングなどに流用しています。

SMBチームの活用

SMBチームは見るべき顧客数もかなり多く、一定面で活用状況を捉え、リスク判断をしていくヘルススコアの本領発揮領域です。

ヘルススコアの参照は大きく以下の2つの文脈で実施しています。
・SMBチームの週次MTG実施時
・SMB顧客との個別接点実施時

 →月次で直近半年以内に契約更新を迎える企業を中心にリスクあり企業(4段階の内最も悪いRED)を抽出して、社内で状況を整理するとともに、ハイタッチでの状況確認、課題解決のためのMTGセットを実施しています。
 →また、週次のMTGで、前週からスコアに変化のあった企業(総合判定、Deployment、Adoption)に関して、チェックを実施。
気になるユーザーには電話、もしくはメールで状況を確認するアクションを実施しています。

ヘルススコア活用で創出された成果

現在までヘルススコアを構築し、活用する中で創出された成果は以下の2点です。
・変わらず低いチャーンレート
・社内チャーンの期待値調整

変わらず低いチャーンレート

この記事の前半でも記載しましたが、そもそもCRMという特性や競合の状況など相まって、それほどチャーンレートの高いプロダクトではありませんでした。

現在大幅なスコア改修をかけた2021年年末から比較して、導入企業数、ID数ともに爆増しておりますが、チャーンレート自体は低い水準を担保できております。

社内チャーンの期待値調整

何それ?
と思われるかもしれませんし、私自身もヘルススコアを作成、活用することでここに繋がる(繋げる)とは思ってもいなかったのですが、ヘルススコアちゃんと作って、ちゃんとアクションに繋げてて本当によかったなぁとこの観点で強く感じています。

そもそも弊社においてはプロダクトのリリース当初からあまりチャーンが発生していなかっただけに、会社のあらゆるレイヤーの方が、ユーザーの利用継続に高い期待値を持っている状況でした。
故に、事業収益への影響や、どうしてもCS(弊社)ではコントロールすることが難しいチャーンに対しても一定のCSMのリソースを割いて、抑止や回避のアプローチを実施する必要があり、一定の時期その活動によりCSのメンバーが精神的にも、物理的な工数含め疲弊してしまう期間がありました。
(全てのチャーンを許容したり、仕方ないと片付けて良いという話では全くなく、やることよりやらないこと、限られたリソースを適切に分配していくことが大切なスタートアップにとって、本当に全てのチャーンに一定のアテンションを張らなければならないのかという話です)

そこで、私を中心にこれまでの各CSMの顧客対応実施時の情報を集約し、チャーンが発生するパターンとそのリスクの高低をリスクマップとして可視化することとしました。

ここがヘルススコアの話と繋がるのですが、幸いなことに弊社ではそれなりの精度のヘルススコアを運用していたことにより、チャーンする前に顧客と接点を確保でき「これやってなかったらチャーンしてたやん!」というヒアリハットデータがたまっており、実際には発生していなくとも、こういう状況にあるユーザーは危ないよね、というグルーピングが容易に実施できました。

チャーンパターンの一例とマッピング

弊社では全部で6つのチャーンが発生するパターンにグルーピングでき、その中でもCSのコントロールが難しい3つのグループに関して高・中・低でリスクの程度を表現し、実際のユーザーをプロットしました。

マッピングに対してのアクション整理

そして、それぞれのリスクごとにプロアクティブ、リアクティブなアクションを整理し、CSとしてアクションを実施してもコントロールが難しいリスク群に関しては戦略的にアクションを実施しないという整理を実施しました。

このリスクマップを会社の経営層と共有し、実際ユーザーは爆増しており、こんなコントロールできないチャーンが発生している(今後発生する可能性がある)ことを可視化し、一定のセグメントに関してはあえてアクションしないことを合意し、社内のチャーンに関しての期待値を適切なレベルに下げるというアプローチを実施しました。

この整理を実施後、実際にチャーンのリスクマップ上戦略的にアプローチを実施しないと整理した代理店に対しては、今後の顧客対応に還元するための情報のキャッチアップには時間を割きましたが、抑止のアプローチは実施していません。

こんな面倒なことをやらなくても結果弊社と同じ状況にある会社様は多いかと思いますが、少ないリソースをどんどん増えていくユーザーに投下しているCSチームは、この方法出なくとも、どこかで社内の高すぎる(ないし低すぎる?)期待値を適正なレベルに調整する必要があるのではないかと考えます。

今後のトライ!

記事の中でも少し言及した部分がありますが、以下の2点に着手して行きたいと考えます。
・アップセル/クロスセルへのヘルススコア活用
・テック/ロータッチ施策へのヘルススコア活用

特に「テック/ロータッチ施策へのヘルススコア活用」に関しては
現在ヘルススコアのシステムを導入しての活用を検討しており、せっかくの正確な状況予測ができるヘルススコアですので、よりタイムリーに、ユーザー様の体験を向上できるようなテックタッチ/ロータッチ施策との連動を強化して行きたい次第です。

ちょっとまとめるつもりが、それなりのボリュームになってしまいましたが、これからヘルススコアを構築される、もしくは改修される方にとって参考になれば幸いです。

1つ言えるのはヘルススコアは手段ですので、目的はぶらさずに構築いただければと思います。 最初から目的をのせすぎずとも、結果アクションを繰り返していれば、弊社のように思わぬ効果に繋がることもあるかと思います。

他にも弊社内での取り組みをいくつかテキストにまとめられればと思いますので、もし次も読んでやってもいいという方がいらっしゃれば「❤️」ボタンをポチッと頂けますと、私の執筆のペースが上がりますw

個別に情報交換させていただける方がいらっしゃいましたらいつでもご連絡お待ちしております!!

https://www.facebook.com/i.taichi2022


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