ヘルススコアの設計と指標選定｜重要指標の選定とスコアリングモデルの構築方法
公開日 ・ 更新日 ・ 読了 20分
ヘルススコアを作ろうとして、どの指標を入れるべきか、どう点数化してひとつのスコアにまとめるべきかで手が止まっている、という声はよく聞きます。テンプレートを埋めてみても、そのスコアが実際の解約と結びついている確信が持てず、運用に踏み切れないという状態です。
この記事では、ヘルススコアを設計する手順を、理想状態の定義から指標選定、重み付け、閾値設定、そして作った後の検証・見直しまで、CS（カスタマーサクセス）の実務レベルで示します。立ち上げ期でデータが少ない組織が小さく始める方法から、解約データが貯まった組織が過去実績から逆算する方法まで、自社の段階に合わせて判断できるようにします。
ヘルススコアと解約防止の体系的な全体像はヘルススコアによるリスク管理と解約防止の全体像で解説しています。本記事はそのうち「設計と指標選定・スコアリングモデルの構築」に絞って深掘りします。
ヘルススコア設計で最初に決めるべきこと
ヘルススコアの成否は、指標を選ぶより前の段階で決まります。「何のために・誰の何を測るのか」を先に言語化しないまま指標から入ると、集めやすいだけで意味のない数字が並び、スコアが実態と乖離します。
まず決めるのは、健全な顧客の理想状態の定義、そのスコアで何を予測するのかという用途、そして手元で確実に取れるデータの3つです。この順で決めると、後続の指標選定と重み付けが機械的に進みます。逆にここを飛ばすと、指標選定の途中で「そもそも何を測りたかったのか」に何度も立ち返ることになります。
「健全な顧客」の理想状態を言葉で定義する
最初にやるのは、更新し続ける顧客がどんな状態にあるかを文章で描くことです。数値化する前に、言葉で理想状態を固定します。たとえば「複数の部署で日常的に使われ、管理者だけでなく現場のメンバーも週に何度もログインしている。四半期に一度は活用範囲を広げる相談が入り、こちらからの連絡に返信がある」といった具合です。
この文章が、後で選ぶ指標の元になります。「複数部署で使われている」は関与人数やアカウント数の指標に、「週に何度もログイン」はログイン頻度の指標に、「活用範囲を広げる相談」はアップセルや機能利用の広がりの指標に翻訳できます。
理想状態を言葉にしておくと、候補に挙がった指標が「本当にこの状態を測れているか」を照合できます。逆に理想状態が曖昧なままだと、測定しやすい指標を後から正当化する順番になり、スコアが目的から離れます。
何を予測するスコアなのかを1つに絞る
ヘルススコアの用途は複数あり得ます。解約リスクの先行検知、アップセルの見込み、オンボーディング完了の判定などです。これらを1つのスコアで兼ねようとすると、指標がぶつかってスコアがぶれます。たとえばアップセル見込みは「利用が拡大している顧客」を高く評価しますが、解約リスク検知では「利用が横ばいでも不満がなければ健全」と評価したい場面があり、重み付けの方向が変わります。
まず用途を「解約リスクの先行検知」に絞ることをおすすめします。CSが最初に必要とするのは、解約の兆候を早く掴んで手を打つための指標だからです。アップセルやオンボード完了は、別のスコアや別の指標セットで測れば済みます。1つのスコアに欲張らせないことが、後の運用のしやすさに直結します。
取得できるデータの棚卸し
理想の指標を並べても、そのデータが取れなければスコアには使えません。設計は「取りたいデータ」ではなく「確実に取れるデータ」から始めるのが現実的です。着手する前に、手元でどんなデータが継続的に取得できるかを棚卸しします。
主な取得元は、SFA/CRMに蓄積された案件・活動の記録、プロダクトの利用ログ、NPSやアンケートの回答、問い合わせ・サポートの履歴です。このうち「毎月・毎週など決まった頻度で欠損なく取れるもの」を優先します。
取得に手作業が必要なデータや、担当者次第で入ったり入らなかったりするデータは、スコアの土台にすると運用が止まります。棚卸しの段階で「理想では入れたいが今は安定して取れない指標」を仕分けておくと、次の指標選定で現実的な候補に絞り込めます。
利用状況・満足度・エンゲージメントの3軸で指標候補を洗い出す
指標を思いつきで並べると、特定の側面に偏ります。「利用状況・満足度・エンゲージメント」の3軸で網羅的に洗い出すと、軸のぶれを防げます。1軸だけでは解約リスクを捉えきれないためです。
利用は多いのに強い不満を抱えている顧客もいれば、満足はしているが利用が停滞して契約更新の意味を感じなくなる顧客もいます。3軸で候補を出したうえで、次のH2で少数に絞り込むという二段構えにします。ここでは各軸の代表的な指標と、選ぶときの勘所を押さえます。
利用状況の指標｜ログイン頻度・主要機能の利用率・アクティブ率
利用状況の指標は「契約しているが使われていない」状態を捉えます。代表的なのはログイン頻度、主要機能の利用率、アクティブユーザー率です。契約が続いていても、ログインが月に数回まで落ち込み、主要機能がほとんど使われていない顧客は、更新のタイミングで「使っていないから解約する」という判断に至りやすくなります。
注意点は、プロダクトによって「健全な利用頻度」がまったく違うことです。毎日使うことが前提のツールなら週数回のログインは危険信号ですが、月次の締め処理でしか使わないツールなら月1〜2回のログインが正常です。
他社のヘルススコアの数値をそのまま持ち込まず、自社プロダクトの利用実態に合わせて読み替える必要があります。目安として、自社の継続顧客の利用ログを見て「更新している顧客の下位ラインがどのくらいか」を基準に置くと現実的です。
満足度の指標｜NPS・CSAT・問い合わせ／クレームの傾向
満足度の指標は、顧客が製品や対応をどう感じているかを測ります。代表的なのがNPS（Net Promoter Score：推奨意向を問う指標）、CSAT（顧客満足度：個別の対応やタッチポイントへの満足度）、そして問い合わせ・クレームの傾向です。強い不満や繰り返されるクレームは、利用状況が良くても解約の引き金になります。
実務上の注意は、アンケート系の指標には回収率の偏りがある点です。回答するのは「特に満足している顧客」か「強い不満を抱えた顧客」に寄りやすく、無回答の顧客の状態は見えません。
NPSやCSATをスコアに入れる場合は、回答があった顧客だけでスコアが動くことの限界を理解し、回答がない顧客を機械的に中間点にするのか、別の指標で補うのかをあらかじめ決めておきます。問い合わせやクレームの履歴は、アンケートより欠損が少なく傾向を掴みやすいので、満足度軸の補完として有効です。
エンゲージメントの指標｜キーマン接触・関与人数・チャンピオン異動
エンゲージメントの指標は、顧客との関係性の強さを測ります。CS側との接触頻度、顧客側で製品に関与している人数、そして製品を社内で推進してくれるチャンピオン（推進役）の異動や退職の有無などです。関係性は解約の先行指標になりやすく、関与人数が1人に依存している顧客は、その人が異動しただけで一気に利用が止まるリスクを抱えています。
エンゲージメントは定量化しにくい軸ですが、諦めずに近似します。関係性そのものは測れなくても、「直近90日でCS側と何回接触したか」「製品にログインしている顧客側のユーザーが何人いるか」「主要担当者に異動・退職が発生したか」といった観測可能な事実に置き換えれば指標になります。定性的な印象で「あの顧客は関係が良い」と判断するより、こうした近似指標のほうがスコアに組み込めて再現性があります。
「重要だから」ではなく「測定可能で更新に効くか」で候補を絞る
3軸で候補を出すと、指標は自然と10個以上になります。ここで陥りやすいのが「どれも重要だから全部入れたい」という発想です。しかし「重要そう」と「スコアに使える」は別です。候補を絞る判断軸は、継続して測定できるか、解約との相関がありそうか、そしてその数字を見た現場が動けるか、この3つです。
たとえば「顧客の経営状態」は重要そうですが、安定して取得できず解約との相関も読みにくいので、スコアには不向きです。逆に「主要機能の利用率」は測定でき、下がれば解約と結びつきやすく、下がった顧客に活用支援という打ち手を出せるので、指標として機能します。次のH2で、この絞り込みをさらに具体的な基準に落とします。
指標を絞り込むための選定基準
候補が出そろったら「少数の効く指標」に絞ります。指標が多すぎると、毎回のスコア更新でデータを揃える負荷が増え、やがて更新が止まってスコアが古いまま放置されます。これは設計でつまずく典型的な失敗です。
最初は3軸あわせて4〜6指標程度から始めるのが現実的な目安です。少数から始めて、運用しながら「足りない」と分かったら足す順番のほうが、最初から盛り込んで運用が破綻するより安全です。ここでは絞り込みの具体的な当てはめ方を示します。
解約との相関で優先度をつける
候補指標のうち、どれを残すかの第一基準は解約との相関です。過去に解約した顧客が、更新前にどの指標で悪化していたかを振り返ると、相関の強い指標が見えてきます。たとえば解約した顧客の多くが更新の2〜3か月前からログイン頻度を落としていたなら、ログイン頻度は優先度の高い指標です。逆に解約顧客も継続顧客も同じような値だった指標は、スコアに入れても解約の判別に効かないので優先度を下げます。
立ち上げ期で解約データがまだ少ない場合は、統計的な相関は取れません。その場合は「理想状態の定義」に立ち返り、健全な顧客に共通する状態を最もよく表す指標を仮説で選びます。データが貯まった段階で相関を確認し、外れていた指標を入れ替える前提で始めます。
現場がその数字を見て動けるか
スコアは見るためではなく動くために作ります。指標を選ぶときは「その数字が悪化したとき、CSが具体的に何かできるか」を確認します。利用率が下がったなら活用支援の面談を設定できます。キーマンが異動したなら新しい担当者との関係構築に動けます。一方、動きようのない指標をスコアに入れても、悪化を眺めるだけで終わります。
アクションにつながらない指標は、たとえ相関があってもスコアの主役にはしません。動ける指標を中心に据えることで、スコアの低下がそのまま「次にやること」に翻訳される設計になります。
割合指標だけで作らない
利用率や継続率のような割合の指標は分かりやすいので多用しがちですが、割合だけで作ると分母の落とし穴にはまります。たとえば「主要機能の利用率90%」でも、そもそも使っているユーザーが1人だけなら実態は危険です。分母（母数）が小さいと割合が極端に振れ、スコアが実態を映さなくなります。
割合指標を使う場合は、分母を確認する実数の指標を併せて持ちます。利用率と一緒にアクティブユーザーの実人数を見る、といった具合です。割合と実数を組み合わせることで、母数の小さい顧客が割合だけ高くて健全に見えてしまう誤判定を防げます。
スコアリングモデルの構築｜重み付けとスコア化
選んだ指標を1つの総合スコアに合成するには、各指標を点数に変換するルールと、軸・指標ごとの重み付けの2つを決めます。ここで完璧を目指す必要はありません。重みは最初は仮置きでよく、運用してデータが貯まったら後から補正する前提で始めます。
統計的に最適な重みを最初から求めようとすると、いつまでも運用に入れません。まずは仮説ベースの単純加重モデルで動かし、実際の解約との照合で直していくのが現実的です。ここでは点数化から総合スコア算出までの手順を示します。
各指標をスコアに変換するルールを決める
指標の生の値はそのままでは足せないので、点数に変換します。よく使うのは段階評価です。たとえばログイン頻度なら「週5回以上＝10点、週2〜4回＝6点、週1回＝3点、それ未満＝0点」のように区切ります。区切りの基準は、前述の継続顧客の利用実態から決めます。
満足度のように値がすでに点数化されている指標は、スケールをそろえます。NPSのようにマイナスからプラスまで振れる指標は、そのままだと他の指標と足せないので、0〜10点などの共通スケールに変換します。
変換ルールを決めるときのコツは、後から見て「なぜこの区切りにしたか」を説明できる根拠を持っておくことです。根拠のない区切りは、見直しのときに直しようがなくなります。
軸・指標の重み付けの決め方
すべての指標を同じ重みで足すと、解約に効かない指標に引っ張られます。解約に効く軸・指標を厚くする重み付けをします。たとえば解約の先行指標として利用状況が最も効くと考えるなら、利用状況40%・満足度30%・エンゲージメント30%のように配分します。
重みの初期値は仮説で構いません。理想状態の定義や、解約顧客の振り返りから「この軸が効きそうだ」という当たりで置きます。統計的な最適化（どの指標がどれだけ解約を説明するかを回帰などで求める手法）は、データが十分に貯まってからで十分です。
立ち上げ期に精緻な最適化を目指すより、仮の重みで早く運用を始め、実データで補正するほうが早く精度が上がります。重みは頻繁に変えず、後述の定期見直しのタイミングでまとめて補正します。
総合スコアの算出とダッシュボードへの落とし込み
各指標の点数に重みを掛けて合計し、100点満点などに正規化すると総合スコアになります。正規化しておくと、顧客間の比較や時系列の推移が直感的に読めます。
ここで大事なのは、CSが見て判断できる粒度に落とすことです。総合スコアだけを表示すると「なぜ下がったか」が分からず動けません。総合スコアと並べて、軸ごとのスコアや、直近で悪化した指標が分かるようにダッシュボードを組みます。スコアを見た担当者が「利用状況が落ちている」とすぐ特定でき、次のアクションに移れる状態が理想です。
閾値の決め方とスコアの段階設計
総合スコアは数字が出るだけでは運用できません。「何点なら健全、何点なら注意、何点なら危険か」の閾値を切って初めて、CSが優先順位をつけて動けます。閾値の決め方で最も現実的なのは、既存顧客の解約実績データを後ろ向きに当てて逆算する方法です。過去に解約した顧客が更新前に何点だったかを見れば、危険域の境界が見えます。
ただし立ち上げ期は実績データが足りないので、暫定の閾値で始めて後から補正する前提を置きます。ここでは段階設計と、データがある場合・ない場合それぞれの閾値の決め方を示します。
3〜4段階のステータスに区切る
スコアは連続値のままより、健全・注意・危険といった段階に区切るとアクションに結びつきます。3〜4段階が扱いやすい目安です。段階を細かくしすぎると境界の意味が曖昧になり、粗すぎると打ち手を出し分けられません。
段階ごとに「その状態になったら誰が確認するか」の当たりだけ、この設計段階でつけておきます。たとえば危険域に入ったら担当CSがすぐ状況を確認する、注意域はマネージャーが週次でまとめて見る、といった大枠です。具体的なアクションの出し分けや検知の自動化は本記事の主題ではないので、詳細は後述の兄弟クラスターに譲ります。
過去の解約顧客のスコアから閾値を逆算する
解約データが十分にある組織は、閾値を逆算できます。過去に解約した顧客の、更新の数か月前の総合スコアを集計すると、多くが一定の点数帯に集まります。その帯が危険域の目安になります。同時に、継続している顧客のスコア分布も見て、両者が分かれる境界を注意域と健全域の区切りにします。
逆算のときは、解約したがスコアが高かった顧客と、低かったが継続した顧客を必ず確認します。この外れ値は閾値だけでなく指標選定そのものの見直しにつながる重要な手がかりで、次のH2で扱う検証の起点になります。
データが少ない立ち上げ期の暫定的な閾値設定
CSを立ち上げたばかりで解約実績がほとんどない場合、逆算はできません。その場合は暫定の閾値で運用を始めます。たとえば総合スコアを100点満点にしたなら「70点以上＝健全、40〜69点＝注意、40点未満＝危険」のように、仮の区切りをまず置きます。
暫定閾値は正しさより「運用を始めるための仮置き」と割り切ります。四半期ごとに、その間の顧客の動きと閾値のズレを見て補正します。
健全域にいたのに解約した顧客が続いたら閾値が甘すぎるので上げる、危険域が多すぎて手が回らないなら基準を見直す、といった調整を繰り返します。動かしながら実態に合わせていくのが、データが貯まる前の現実的なやり方です。
ヘルススコア設計でつまずく典型パターンと回避策
ヘルススコア設計の最大の失敗は、作った後に使われず形骸化することです。精緻なモデルを作っても、運用が回らなければ意味がありません。形骸化に至る典型パターンは4つあります。
指標を盛り込みすぎて更新が止まる、元データが入力されずスコアが実態とずれる、スコアはあるがアクションにつながらない、閾値や重みを頻繁に変えすぎて比較できなくなる、です。いずれも設計段階で回避できます。ここでは各パターンの兆候と対処を示します。
指標を盛り込みすぎて更新が止まる
「せっかく作るなら網羅的に」と10個以上の指標を入れると、毎回のスコア更新でデータを集めるだけで負荷が高くなります。手作業が必要な指標がひとつでもあると、忙しい時期に更新が後回しになり、やがてスコアが古いまま放置されます。
回避策は、前述のとおり4〜6指標程度から始めることです。更新が自動化できる指標を優先し、手作業が必要な指標は本当に効く場合だけ入れます。指標は「足りなければ後で足す」方向で運用するほうが、最初から盛り込んで破綻するより安全です。
元データが入力されず、スコアが実態とずれる
ヘルススコアは元となる顧客情報や活動データが揃っていることが前提です。CSが把握している顧客の状況や接触の記録がSFA（営業支援システム）やCRM（顧客関係管理）に入っていないと、スコアの元データが欠け、実態とずれた点数が出ます。特にエンゲージメント軸は活動記録に依存するので、記録が入力されていないと空白のまま計算され、健全に見えてしまう危険があります。
たとえばMazrica SalesのようなSFA/CRMに案件・活動の記録が日々蓄積されていれば、接触頻度や関与人数といった指標の元データとして使えます。逆に、どんなに良いスコアモデルを設計しても、元データの入力が習慣化していなければスコアは機能しません。設計と並行して「誰が・いつ・何を記録するか」の入力ルールを固めておくことが、スコアを実態に合わせる前提条件です。
スコアはあるがアクションにつながらない
スコアを可視化しただけで満足してしまい、下がった顧客に何もしないまま解約される、というパターンがあります。ダッシュボードを眺めることが目的化すると、スコアは飾りになります。
これは設計段階で防げます。スコアを設計するときに「どの段階になったら誰が何を検討するか」の当たりをつけておきます。危険域に入った顧客に対して活用支援の面談を打診する、注意域が続く顧客をマネージャーがレビューする、といった大枠を決めておけば、スコアの低下が次の動きに直結します。検知の自動化やアラート運用、具体的なリテンション施策の設計は本記事の範囲を超えるので、リスク検知とアラート設計を参照してください。
閾値・重みを頻繁に変えすぎて比較できなくなる
スコアが期待どおりに動かないと、閾値や重みをその都度いじりたくなります。しかし期中に頻繁に変えると、先月と今月のスコアが同じ基準で比べられなくなり、推移が読めなくなります。改善しているのかどうかも分からなくなります。
回避策は、見直しを定期サイクルに固定し、期中は動かさないことです。四半期に一度など決めたタイミングでまとめて補正し、それ以外は基準を固定します。基準が安定していて初めて、スコアの推移が意味を持ちます。
設計後の検証と見直しサイクル
ヘルススコアは作って終わりではありません。「実際の解約とスコアが一致していたか」を定期的に検証し、ずれていた指標や重みを補正し続けて初めて精度が上がります。多くの記事は設計手順までで終わりますが、検証こそがスコアを使えるものにする工程です。
見直しは四半期などの定期サイクルに固定し、期中は動かしません。ここでは何を検証するか、どの頻度で回すか、セグメントごとに分けるべきかを示します。
スコアと実際の更新／解約の当たり外れを検証する
検証の核心は、スコアの予測が当たったか外れたかを見ることです。特に注目するのは2種類の外れ値です。高スコアだったのに解約した顧客と、低スコアだったのに継続した顧客です。
高スコアで解約した顧客は、そのスコアが捉えられていない解約要因があったことを示します。たとえば利用も満足度も高かったのに、顧客側の予算削減や担当者交代で解約したなら、それを近似できる指標（キーマンの異動など）の重みを上げる余地があります。
低スコアで継続した顧客は、逆にスコアが過剰に危険と判定していることを示し、その指標が自社の解約とは相関していない可能性を示唆します。この当たり外れの分析から、指標の入れ替えや重みの補正につなげます。数字を眺めるだけの検証ではなく、外れた顧客を数社ずつ具体的に掘り下げるのが有効です。
見直しの頻度とタイミングを固定する
検証と補正は、頻度とタイミングを決めて固定します。四半期に一度が扱いやすい目安です。契約更新のサイクルが1年なら、四半期ごとの検証で年4回、スコアと実際の更新結果を照合できます。
頻度を固定する理由は、前述のとおり期中に基準を動かすと推移が比較できなくなるからです。検証で「補正が必要」と分かっても、その場で変えずに次の見直しタイミングでまとめて反映します。見直しのたびに「何を変えたか」を記録しておくと、後からスコアの推移を解釈するときに役立ちます。
セグメントごとにスコア設計を分ける判断
顧客の規模やプランによって、健全の基準が大きく違う場合があります。エンタープライズ顧客と小規模顧客では、期待される利用頻度も関与人数も違い、同じ閾値で測ると片方が常に危険域、もう片方が常に健全域になりがちです。この場合はスコア設計そのものをセグメントごとに分ける判断をします。
ただし、最初から細かく分けると運用が煩雑になります。まずは全体で1つのスコアで始め、検証の過程で「特定のセグメントだけ当たり外れが大きい」と分かったら分割を検討する順番が現実的です。設計時にはセグメントの違いを織り込む観点だけ持っておけば十分で、具体的にどう対応を出し分けるかはセグメント別の対応設計で扱います。
まとめ｜自社の段階に合わせた設計の進め方
ヘルススコアの設計は、自社にどれだけ解約データが貯まっているかで進め方が変わります。CSを立ち上げたばかりでデータが少ない組織なら、3軸で4〜6指標を仮説で選び、単純加重モデルと仮の閾値で小さく始めて、四半期ごとに実態と照らして補正するのが現実的です。
一方、解約データが十分にある組織なら、過去に解約した顧客のスコアから閾値を逆算し、解約との相関を根拠に重みを補正するところまで踏み込めます。どちらの場合も、最初から完璧を目指さず、運用しながら精度を上げる前提で始めるのが共通の原則です。
次の一歩として現実的なのは、KPIツリーを全部書き出すような大がかりな作業ではなく、まず自社で最近解約した顧客を数社振り返ることです。その顧客が更新前にどんな変化を見せていたか、ログインが減っていたのか、返信が途絶えていたのか、キーマンが異動していたのかを書き出すと、自社の解約に効く指標の当たりが見えてきます。それがそのまま、最初の指標候補になります。
ヘルススコアと解約防止の体系的な全体像はヘルススコアによるリスク管理と解約防止の全体像を参照してください。設計したスコアをどう検知・アクションにつなげるかはリスク検知とアラート設計、下がった顧客への打ち手はリテンション施策の設計で解説しています。
よくある質問
Q ヘルススコアの指標は何個くらいが適切ですか？
最初は3軸あわせて4〜6指標程度が目安です。指標が多いほど精度が上がるわけではなく、むしろ更新の負荷が増えて運用が止まるリスクが高まります。少数の効く指標から始め、運用しながら「足りない」と分かった時点で足すほうが、最初から盛り込んで破綻するより安全です。手作業なしで継続的に取得できる指標を優先してください。
Q ヘルススコアの重み付けはどう決めればよいですか？
立ち上げ期は仮説ベースの重みで始めて構いません。健全な顧客の理想状態や、過去の解約顧客の振り返りから「この軸が解約に効きそうだ」という当たりをつけ、その軸を厚く配分します。統計的な最適化はデータが十分に貯まってからで十分です。重みは期中に頻繁に変えず、四半期などの定期見直しのタイミングでまとめて補正します。
Q NPSや満足度アンケートは回収率が低くてもヘルススコアに入れてよいですか？
入れられますが、回収率の偏りを理解したうえで扱う必要があります。アンケートに答えるのは特に満足している顧客か強い不満を抱えた顧客に寄りやすく、無回答の顧客の状態は見えません。回答がない顧客をどう扱うか（中間点にする、別の指標で補うなど）を決めておくことと、問い合わせ・クレーム履歴のように欠損の少ない指標で満足度軸を補完することをおすすめします。
Q 契約したばかりでデータが少ない顧客のヘルススコアはどう扱えばよいですか？
契約直後は利用ログや満足度のデータがまだ薄いので、通常のスコアでは実態を映しにくくなります。オンボーディング期間中は「主要機能を使い始めたか」「初期設定が完了したか」といった立ち上げの進捗を見る指標で別枠で管理し、通常のヘルススコアには一定期間が経ってデータが揃ってから移すのが現実的です。少ないデータで無理に危険・健全を判定しないことが大切です。
Q ヘルススコアと解約は本当に相関しますか？外れることはありませんか？
外れることはあります。だからこそ設計後の検証が欠かせません。高スコアなのに解約した顧客や、低スコアなのに継続した顧客は必ず出てきます。この外れ値を数社ずつ具体的に掘り下げると、スコアが捉えられていなかった解約要因や、過剰に危険と判定していた指標が見えてきます。それを次の見直しで指標の入れ替えや重みの補正に反映することで、相関の精度が徐々に上がります。
Q ヘルススコアはツールなしでExcel／スプレッドシートでも作れますか？
小規模で顧客数が少ないうちは、Excelやスプレッドシートでも作れます。指標を手元で集計し、重み付けした加重合計を計算する程度であれば十分対応できます。ただし顧客数が増え、利用ログや活動記録のデータ量・更新頻度が上がると、手作業での集計に限界が来ます。データの取得元がSFA/CRMや利用ログなど複数にまたがる場合は、それらを集約して自動で更新できる仕組みに移すことを検討する段階が来ます。