HubSpotで顧客の状態を共通指標に変えます。スコアそのものより、指標と対応ルールを一体で設計することが核心です。
「解約の連絡が来てから対応しているため、打ち手を考える時間が足りない」
「顧客の利用状況が担当者ごとに分かれ、支援の優先順位を決めにくい」
「カスタマーサクセスの判断が属人的で、引き継ぐと基準が変わってしまう」——こうした課題は、顧客の状態を共通言語にすることで整理しやすくなります。
ヘルススコアとは、顧客の利用状況、エンゲージメント、ビジネス成果、契約や関係性の情報を数値化し、顧客の健全性を可視化する仕組みです。低下した顧客を早めに把握し、担当者が次の行動を選べる状態をつくることが目的です。
この分野の体系的な情報はHubSpot営業・CS活用ガイドでまとめています。
本記事は「PLG × PLSハイブリッド戦略|プロダクトレッドと営業レッドを両立する設計」シリーズの一部です。
本記事はHubSpotゴールドパートナーのStartLinkの「HubSpot完全ガイド」関連記事です。
この記事でわかること
カスタマーサクセスの仕組み化と解約防止を進めたいCS担当者やマネージャーに向けて、設計から運用改善までを順番に整理します。
- ヘルススコアの役割 — 顧客の状態を担当者の感覚だけで判断せず、チームで共有できる基準に変える考え方がわかります。
- 指標の選び方 — プロダクト利用、エンゲージメント、ビジネス成果、契約や関係性から、運用できる指標を選ぶ方法がわかります。
- 算出ロジックの作り方 — 指標の向き、重み、欠損時の扱い、ステータスの分け方を整理できます。
- HubSpotでの実装方法 — カスタムプロパティ、計算プロパティ、ワークフロー、ダッシュボードの役割分担がわかります。
- スコアを行動につなげる方法 — 状態に応じた担当者、期限、次の行動を決め、引き継げる運用にする方法がわかります。
ヘルススコアとは顧客の状態を共通言語にする仕組み
ヘルススコアは、解約を断定する数値ではなく、顧客との関わり方を決めるための判断材料です。
利用状況だけを見るのではなく、顧客が成果を認識しているか、担当者との関係が続いているかまで含めて捉えます。ここを曖昧にすると、点数が表示されても次の行動を決められません。
健全性を複数の信号から捉える
顧客の状態は、ひとつの情報だけでは判断しにくいものです。
- ログインが続いていても ── 成果を認識していない場合がある
- 問い合わせが少なくても ── 利用が定着しているとは限らない
そのため、プロダクト利用、エンゲージメント、ビジネス成果、契約や関係性を組み合わせます。
スコアを見るときは、合計点とあわせて内訳も確認できる形をおすすめします。同じ合計点でも、利用が落ちている顧客と意思決定者との接点が薄い顧客では、選ぶべき対応が異なるためです。
解約予兆を対応の入口として扱う
低いスコアは、解約を決めつけるラベルではありません。CS担当者が利用状況や課題を確認し、支援の要否を判断する入口です。スコアが下がった理由まで見えるようにすると、次のような行動を選びやすくなります。
また、スコアが高い顧客にも役割があります。価値を認識しているかを確認したうえで、利用範囲の拡大や事例インタビューなど、関係を深める会話につなげられます。
CRM全体の流れに位置づける
ヘルススコアは、カスタマーサクセスだけの独立した表ではなく、CRM全体の流れに置くことがポイントになってきます。コンタクトを起点に取引、顧客化、請求へ進む情報と、導入後のチケットや活動履歴を関連付けることで、受注前の期待と受注後の利用状況を同じ顧客情報の中で確認できます。
StartLinkでは、CRMを単なるデータベースではなく、部門間で判断をつなぐ仕組みとして設計することをおすすめします。ヘルススコアも単体機能として作るのではなく、営業からCSへの引き継ぎ、サポート対応、契約更新までの流れの中で役割を決めます。
ヘルススコアが必要になる理由
顧客数や担当者が増えるほど、頭の中や個別のスプレッドシートだけで状態を追う運用には限界が出ます。更新のタイミングや記入方法が担当者ごとに異なると、同じ顧客を見ても判断がそろいません。ヘルススコアは、一元管理、自動化、可視化を通じて支援の優先順位をそろえる土台になります。
スプレッドシートの分散を減らす
スプレッドシートで顧客台帳、利用状況、面談履歴を別々に管理すると、転記や照合が増えます。最新の情報がどれか分からない状態では、解約予兆よりも先にデータ確認へ時間を使うことになります。
CRMに顧客情報と活動履歴を集め、同じレコードから内訳を確認できるようにすると、担当者はデータ探しではなく対応判断に集中できます。すべてを一度に移すのではなく、介入判断に使う項目からまとめていく進め方が現実的です。
優先順位をチームでそろえる
担当者がそれぞれの経験で支援先を決めると、次のようなケースがあります。
- 対応の偏り ── 忙しい顧客だけに対応が偏る
- 見落とし ── 連絡の少ない顧客を見落とす
共通のスコア帯と対応ルールを置くと、誰が見ても次に確認する顧客を選びやすくなります。
ここで重要なのは、担当者を評価するための点数にしないことです。顧客への支援を早めるための共通基準と位置づけ、内訳や背景を確認してから行動を決めます。
引き継げる運用をつくる
ヘルススコアの運用は、個人の観察力だけに頼らない仕組みづくりでもあります。次の内容を記録しておけば、担当変更や新人の参加があっても同じ順序で顧客状態を確認できます。
仕組み化の要点になるのは、スコアが変化した後の動きまで決めることです。通知だけで終わらせず、次の流れまでそろえます。
- 担当者が理由を確認する
- タスクを進める
- 結果を記録する
ヘルススコアを構成する指標の設計
指標は、取得できるデータを並べるのではなく、顧客が価値を得ている状態から逆算します。企業様によって最適な指標は異なりますが、ヘルススコアは、プロダクト利用、エンゲージメント、ビジネス成果、契約や関係性のカテゴリで整理します。最初は、担当者が意味を説明でき、対応に結び付く項目に絞ります。
プロダクト利用指標
プロダクト利用指標では、ログイン頻度、主要機能の利用状況、利用ユーザーの広がりなどを確認します。利用実態を捉えやすい一方で、ログイン回数が多いだけで成果が出ているとは判断できません。
| 指標候補 |
確認する内容 |
対応の分かれ目 |
| ログイン状況 |
利用が継続しているか |
低下が続く場合は、利用を妨げる課題をヒアリングします |
| 主要機能の利用 |
顧客が価値を得る機能を使えているか |
未利用なら、機能説明ではなく業務への取り入れ方を確認します |
| 利用ユーザーの広がり |
契約した利用範囲に定着しているか |
一部の担当者に偏る場合は、利用部門への展開方法を整理します |
エンゲージメント指標
エンゲージメント指標では、CSミーティングへの参加、メールへの反応、サポート問い合わせ、ウェビナーやイベントへの参加を扱います。接点が多い状態をそのまま健全とみなさず、問い合わせが課題解決につながっているかまで確認します。
問い合わせが増えた場合は、関心の高さと障害の発生を分けて考えます。チケットの内容や解決状況と組み合わせることで、単純な件数では見えない背景を確認できます。
ビジネス成果指標
ビジネス成果指標では、導入時に設定した目標の達成度、顧客の効果認識、利用部門の拡大傾向を確認します。利用量が安定していても、顧客が成果を説明できない状態では、契約更新時に価値を再検討される可能性があります。
成果を確認するときは、CS側だけで判断せず、定期的なヒアリングで顧客の認識を記録します。定量データを取れない場合は、効果を認識しているか、未評価か、課題があるかを選べる項目にすると運用しやすくなります。
契約と関係性の指標
契約と関係性の指標では、契約更新までの期間、満足度、意思決定者との接点、請求遅延の有無を確認します。利用担当者の反応が良くても、更新を決める関係者と価値認識が共有されていなければ、別の対応が求められます。
| 観点 |
確認項目 |
次の判断 |
| 契約 |
更新時期と現在の合意状況 |
更新が近く合意が曖昧なら、価値と未解決課題を整理します |
| 関係 |
意思決定者との接点 |
接点が薄いなら、担当者と相談して関係者を確認します |
| 満足 |
アンケートと面談の記録 |
評価が低いなら、理由を分類して改善担当を決めます |
| 請求 |
支払い状況 |
遅延があるなら、営業や管理部門と共有して事実関係を確認します |
スコアの算出ロジックとステータスの決め方
算出ロジックでは、各指標を点数へ変換し、重要度に応じて重みを付けます。最初から精密な予測モデルを目指すのではなく、CS担当者が説明できる簡易版から始め、蓄積したデータと解約結果を照らして調整します。計算式と運用ルールを別々に作らないことがポイントです。
指標の向きと評価条件をそろえる
ログインや主要機能の利用は増えるほど健全と見なしやすい一方、問い合わせ件数は多ければ良いとも、少なければ良いとも限りません。まず、各指標が増えたときに加点するのか、減点するのか、別の情報を確認するのかを決めます。
| 指標の型 |
評価方法 |
例 |
| 増加を前向きに見る |
条件を満たしたら加点 |
主要機能の利用、ミーティング参加 |
| 発生をリスクとして見る |
該当したら減点 |
支払い遅延、未解決課題 |
| 単独で判断しない |
関連情報へ確認をつなぐ |
問い合わせ頻度、メール返信速度 |
重みは事業上の重要度から決める
重み付けでは、解約との関係を説明できる指標を優先します。プロダクト利用を重視する考え方がありますが、導入効果が利用回数に表れにくいサービスでは、成果認識や関係性の比重を高める考え方もあります。次の表は、重み付けを検討する際の主なカテゴリと視点を示します。
| カテゴリ |
内容 |
重視度の考え方 |
| プロダクト利用 |
ログインや機能利用などの実利用状況 |
事業やサービスの性質による |
| エンゲージメント |
ミーティングや問い合わせなどの接点 |
事業やサービスの性質による |
| ビジネス成果 |
目標達成度や効果認識 |
事業やサービスの性質による |
| 契約・関係 |
更新時期や意思決定者との接点 |
事業やサービスの性質による |
重みを決める会議では、営業、CS、サポートがそれぞれ重要だと思う指標を並べるだけでなく、スコアが下がったときに誰が何をできるかまで確認します。行動につながらない指標は、取得できても初期版から外す判断ができます。
ステータスは対応の違いで区切る
スコア帯は、色を増やすためではなく、対応を切り替える境界として設計します。健全、注意、警告、危険と分ける場合も、各状態で担当者、期限、確認項目、記録先が変わるようにします。
| ステータス |
判断の考え方 |
主な対応 |
| 健全 |
利用、成果、関係性が安定しています |
価値認識を確認し、利用範囲の拡大機会を探ります |
| 注意 |
一部の指標に低下や未確認があります |
低下理由を確認し、利用促進やフォローを行います |
| 警告 |
複数の観点で課題が見えています |
CSが課題を整理し、改善プランを合意します |
| 危険 |
更新や利用継続に関わる課題があります |
責任者を決め、優先して事実確認と対応を進めます |
ただし、最初に決めた境界を固定すると、実際の解約傾向とずれることがあります。解約した顧客と継続した顧客のスコア推移を比べ、同じ状態に偏って分類されるなら条件や重みを見直します。
HubSpotでヘルススコアを実装する方法
HubSpotでは、指標の保存、計算、通知、可視化をそれぞれ分けて設計します。カスタムプロパティ、計算プロパティ、ワークフロー、ダッシュボードを使い、機能を増やす前に、どのデータをどのレコードへ集めるかを決めます。実装前に運用の流れを整理しておくと、各機能の役割を分けやすくなります。(出典:Create a health score in the customer success workspace)
HubSpotのCustomer Successワークスペースにある専用ヘルススコア機能を使う場合は、Service Hub ProfessionalまたはEnterpriseと必要なService Seat・権限を確認します。公式手順では、作成できるヘルススコアは最大50件、1つのスコアへ適用する会社またはコンタクトのセグメントは最大5件です。この上限を目標値にせず、まず対象顧客を絞り、同じ判定基準で運用できる単位から始めます。独自の計算プロパティで作る場合とは、設定場所と利用条件を分けて設計します。(出典:Create a health score in the customer success workspace)
プロパティと計算を分けて設計する
各指標は数値型などのカスタムプロパティへ保存し、合計スコアは計算プロパティで算出します。計算で表現できる内容までワークフローへ寄せると、処理が増えて定義を追いにくくなるため、計算とアクションを分ける設計をおすすめします。
計算プロパティを使うことで、元データの更新に応じてスコアを更新できます。プロパティ名には指標の意味が分かる名称を付け、定義、更新元、欠損時の扱いを管理資料に残します。
受注前後の顧客情報を関連付ける
プロダクトのログインや機能利用状況は、APIまたはiPaaSを使ってCRMへ連携します。更新頻度は、定期バッチとリアルタイム連携のどちらが介入判断に必要かで選びます。利用低下へ早く対応したい場合は更新間隔を短くし、契約更新時の確認が中心なら運用負荷とのバランスを取ります。
利用データだけを独立した表に置くのではなく、顧客レコード、取引、チケット、活動履歴と関連付けます。受注前に合意した目的と、顧客化後の利用状況や課題を同じ流れで追える構成にすると、営業からCSへの引き継ぎにも使えます。
以下の画面は、取引名、クローズ日、取引ステージ、関連付けられた会社、金額を同じ一覧で確認できるHubSpotの取引一覧です。

取引と会社の関連付けを確認できるため、受注前の情報を顧客化後の支援へ引き継ぐ設計を考える際に使えます。ヘルススコアの対象レコードにも、営業からCSへ渡したい情報を関連付けます。
ワークフローとダッシュボードへつなぐ
ワークフローは、スコアが条件に達したときの通知やタスク作成に使います。通知条件は、受け取った担当者が行動を決められる状態に絞り、理由となった指標も同時に確認できるようにします。
ダッシュボードでは、スコアの分布、変化、対応中の顧客を見られる形にします。集計を見るだけで終わらず、対象顧客のレコードへ移り、活動履歴と次のタスクを確認できる流れを作ります。
専用ヘルススコア機能と計算プロパティの使い分け
HubSpotでは、Customer Successワークスペースの専用機能と、計算プロパティで作る方法を選べます。次の表で、自社に合う方を判断してください。
| 判断軸 |
専用ヘルススコア機能 |
計算プロパティ+ワークフロー |
| 使える前提 |
Service Hub ProfessionalまたはEnterprise、Service Seat、専用の権限が必要 |
対象Hubのプロフェッショナル以上で作成でき、作成数にプランごとの上限がある |
| 指標の組み立て |
イベント(会議・通話など)やプロパティの条件にポイントを加算・減算する |
数値などのプロパティを自分で式に組み立てる |
| 状態の区分 |
しきい値・色・ラベルを画面で設定し、Health statusが自動で付く |
式の結果を条件にして、自分でステータスを設計する |
| 向いている場面 |
CS担当者が画面で調整しながら始めたい |
外部のプロダクト利用データなど、独自の指標を合算したい |
専用機能の作成手順は、公式ナレッジで次のように案内されています(出典:Create a health score in the customer success workspace。メニュー名は画面の言語により表記が異なります)。
- 「More」から「Service」>「Customer Success」を開き、右上の設定(歯車)から「Health scores」タブで「Create a health score」を選ぶ
- 事前定義のグループを使うか、「Start from scratch」でゼロから作る(事前定義には1:1 Engagement、Support Tickets、CSM Sentiment、NPSなどがある)
- グループごとにイベントまたはプロパティの条件を決め、ポイントを加算または減算で設定する。グループには最大ポイントを置き、過剰な加点を防ぐ
- 必要に応じて、時間の経過でスコアを減らす「Decay scores」を有効にする
- 「Settings」タブのしきい値で、状態の区切り・色・ラベルを決める
- 適用する会社またはコンタクトのセグメントを選ぶ(最大5つ)
- 「Test a record」で数件のレコードを確認し、「Preview distribution」で分布を見てから、「Review and turn on」で公開する
公開すると、「Health score」と「Health status」のプロパティが自動で作成され、更新されます。ヘルススコアは最大50件まで作成でき、複数のスコアを作るにはService Hub Enterpriseが必要です。
設計例:4つの指標グループとポイント
最初は4グループ程度に絞るのが運用しやすい進め方です。次はポイント設計の例で、点数は自社の過去データで検証して調整してください。
| グループ |
シグナルの例 |
ポイントの考え方 |
| プロダクト利用 |
直近30日のログイン回数、主要機能の利用有無(プロパティ) |
利用が基準以上なら加算、利用なしなら減算 |
| エンゲージメント |
直近の会議・通話の回数(イベント)、サポートチケットの未解決数 |
接点があれば加算、未解決が続けば減算し、Decayで古い接点の影響を下げる |
| ビジネス成果 |
導入目的の達成状況(CSMによる確認結果のプロパティ) |
達成を確認できていれば加算 |
| 契約と関係性 |
契約更新日までの残り日数、意思決定者との接点の有無 |
更新が近く接点がなければ減算 |
計算プロパティで作る場合は、設定(歯車)の「プロパティ」から「プロパティを作成」を開き、フィールドタイプで「計算」を選びます(出典:Create calculation properties)。カスタム式では、数値のプロパティに値がないと式の結果が空になります。値がない場合は、「if」と「is_known」の関数で0を返すように作ってください。
公開前の検証手順
- 過去に解約した顧客と継続している顧客を各5〜10社選ぶ
- 解約の3か月前時点のデータで、各社のスコアと内訳を計算する
- 解約顧客だけが低く出る指標を残し、継続顧客でも低い指標は重みを下げる
- 注意・警告の区切りで、担当者が週に対応できる件数に収まるかを分布で確認する
- 公開後は、週次のパイプラインレビューの場で、スコアが下がった顧客の理由と次の行動を確認する
週次の確認とダッシュボードの作り方はHubSpot定着の運用設計|週次パイプラインレビューとデータ品質ダッシュボード、データモデルの点検はHubSpotデータモデルの健全性チェックで解説しています。
ヘルススコアに基づくアクションを設計する
スコアを可視化するだけでは、カスタマーサクセスの成果にはつながりません。状態ごとに、誰が、何を確認し、どの行動を選び、どこへ記録するかを決めます。この対応設計まで含めてヘルススコアを仕組み化することが重要です。
健全な顧客は価値認識を確認する
健全な顧客には、アップセルやクロスセルを急ぐ前に、どの価値を認識しているかを確認します。成果が言語化できていれば、利用部門の拡大、事例インタビュー、紹介の相談へ進む判断ができます。
一方で、利用量だけが高く成果認識が弱い場合は、価値の振り返りを優先します。高いスコアをそのまま営業機会とみなさないことで、顧客との認識差を減らせます。
注意状態では低下理由を特定する
注意状態では、どの指標が変化したかを確認し、利用状況のヒアリング、未活用機能のトレーニング、更新に向けた価値の再確認から対応を選びます。担当者は、連絡した事実だけでなく、課題、合意した行動、次回確認の予定をCRMへ残します。
通知を広げすぎると、対応すべき顧客が埋もれやすくなります。担当者が行動を決められなかった通知は条件から外すか、内訳を追加し、通知からタスク完了まで追える形へ修正します。
警告や危険状態では責任者を明確にする
警告や危険状態では、CS担当者が課題を深掘りし、改善プランを顧客と共有します。契約更新や重要な関係者に影響する場合は、責任者を決めて関係部門と連携します。
| 確認順 |
確認する内容 |
次の行動 |
| 最初 |
低下した指標と更新元 |
データ誤りなら修正し、事実なら背景確認へ進みます |
| 次 |
顧客が認識する課題と影響 |
課題が明確なら改善プランと担当者を決めます |
| 最後 |
合意した行動と次回確認 |
CRMへ記録し、タスクと期限を設定します |
スコアが低いという理由だけで一律のメールを送るのではなく、内訳と顧客の状況を人が確認してから対応を選びます。自動化は漏れを防ぐ役割に置き、顧客への提案や優先順位の判断は担当者が行います。
StartLinkのヘルススコア導入の進め方
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わっています。ヘルススコアの導入は、準委任で伴走しながら、スモールスタートで次の工程を進めます。
| 工程 |
内容 |
成果物の例 |
| 現状の整理・要件定義 |
顧客の「健全な状態」を言葉で定義し、確認できるデータの所在を整理する |
指標候補一覧、データの所在表 |
| 設計・構築 |
指標グループ、ポイント、しきい値、通知とタスクを設計・設定する |
スコア設計書、ワークフロー設計書 |
| データ移行 |
利用データやスプレッドシートの情報をHubSpotのプロパティへ整える |
プロパティ一覧、件数照合 |
| テスト・検証 |
過去の解約顧客と継続顧客でスコアの差を検証する |
検証結果、重みの調整案 |
| 定着・運用改善 |
AI(Breezeなど)による顧客状況の要約も含め、対応結果を指標へ戻す |
月次の見直し記録 |
全体の進め方はHubSpot導入・構築支援のページで確認できます。
ヘルススコアを運用しながら改善する
ヘルススコアは、初期設定を終えたら完成するものではありません。解約や更新の結果、担当者が行った対応、顧客の反応をCRMへ戻し、指標と条件を見直します。項目を増やすより、使われない項目を外して判断しやすい状態を保つことをおすすめします。
過去の結果とスコア推移を比べる
解約した顧客と継続した顧客について、どの指標が先に変化したかを確認します。低いスコアの顧客が継続し、高いスコアの顧客が解約している場合は、重み、条件、データ更新の遅れを分けて調べます。
見直しでは、予測が外れた顧客だけでなく、担当者が介入した結果も記録します。介入後に状態が変わった場合は、スコアの評価だけでなく、どの対応が選ばれたかも次の運用改善に使えます。
項目を増やしすぎない
取得できるデータをすべてスコアへ入れると、点数の理由を説明しにくくなります。各指標について、次の点を確認し、どれにも当てはまらない項目は外します。
- 顧客状態を表すか
- 更新元が明確か
- 変化したときに行動できるか
スコアを担当者が理解できなければ、通知を受けても動けません。項目を最小限に保つことは、運用負荷を下げるだけでなく、引き継ぎや新人教育にもつながります。
ヘルススコアの限界を理解する
ヘルススコアには、次の限界があります。
- CRMに入っていない情報 ── 顧客の発言や組織変更などは評価できない
- 入力や連携が止まった場合 ── 計算が正しくても現在の状態を表さなくなる
ただし、欠損を低評価として処理するか、評価対象外にするかで意味は変わります。次の分岐まで決めます。
- 未入力が顧客のリスクを示す ── 低評価へ含める
- 連携遅延の可能性がある ── 対象外として担当者にデータ確認タスクを出す
よくある質問
ヘルススコアを設計するときに迷いやすい論点を整理します。どの回答も、点数だけで判断せず、内訳と次の行動を結び付けることが前提です。
Q1. どの規模からヘルススコアを始めるべきですか?
担当者の頭の中だけでは顧客状態を追いにくくなったときが検討のタイミングです。顧客数だけで決めず、担当者数、データの分散、引き継ぎ頻度、対応漏れの有無を見て判断します。最初は対象顧客を絞り、同じ基準で優先順位を決められるかを確認します。
Q2. ヘルススコアの精度はどう検証しますか?
過去の解約顧客と継続顧客について、スコアと内訳の推移を比較します。解約顧客だけが早く低下する指標があるか、継続顧客も同じように低下していないかを見ます。差が見えなければ、その指標の重みを下げるか、別の指標へ置き換えます。
Q3. プロダクト利用データがなくても設計できますか?
設計できます。エンゲージメント、ビジネス成果、契約や関係性の情報から始め、顧客の状態を共有する基準を作ります。利用データを連携できるようになったら、既存の判断がどう変わるかを確認してから追加します。
Q4. スコアが下がったら自動で顧客へ連絡してよいですか?
まずは社内通知とタスク作成にとどめ、担当者が内訳と活動履歴を確認してから連絡内容を決める運用をおすすめします。データの更新遅れや一時的な変化でもスコアは動くためです。確認後の対応をCRMへ記録し、同じ条件で判断できるようにします。
まとめ
ヘルススコアは、顧客の状態を点数にすること自体ではなく、解約予兆を見つけて適切な支援へつなぐ仕組みです。指標、計算、通知、対応、振り返りを一気通貫で設計すると、担当者が変わっても同じ基準で運用しやすくなります。
設計の要点
- 利用状況だけでなく、エンゲージメント、ビジネス成果、契約や関係性を組み合わせます。
- 合計点と内訳を並べ、低下理由から対応を選べるようにします。
- HubSpotでは、プロパティと計算、ワークフロー、ダッシュボードの役割を分けます。
- 自動化は通知とタスク作成に使い、顧客への対応は担当者が内訳を確認して決めます。
- 解約や更新の結果を戻し、使われない指標を外しながら改善します。
まず取り組むこと
まずは、現在の顧客管理で担当者が共通して確認している指標から始めてください。次の順序で小さく試し、判断と行動がそろってから対象を広げます。
- 顧客が価値を得ている状態を言葉で定義し、確認できる指標を選びます。
- 各指標の更新元、評価条件、欠損時の扱いを決め、HubSpotのプロパティへ整理します。
- 状態ごとの担当者と行動を決め、通知からタスク完了までを試します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい
ヘルススコアを営業とカスタマーサクセスの全体設計へつなげる際は、次の記事も参考になります。解約防止、製造業での活用、営業プロセス改善の観点から確認できます。