HubSpotでカスタマーサクセスを管理するための基盤設計と運用の仕組み化。オンボーディング・ヘルススコア・解約防止を一気通貫で設計する方法を解説します。
デモ環境のダッシュボード例。複数レポートを並べてKPIを一覧できます。
取引パイプラインのボードビューの模式図。ステージ設計がそのまま画面に反映されます。
「顧客のオンボーディング状況が担当者ごとにバラバラ」「解約の兆候に気づくのが遅い」「カスタマーサクセスの活動がデータとして可視化できていない」——CS(カスタマーサクセス)部門でこうした課題を抱えている企業は多いのではないでしょうか。
HubSpotを活用したカスタマーサクセスとは、Service HubやCRMのデータを使って、顧客のオンボーディング管理、ヘルススコアによる状態把握、解約リスクの早期検知、アップセル機会の特定を体系的に行うアプローチです。 マーケティング・営業から引き継いだ顧客データがCRMに蓄積されているHubSpotだからこそ、一気通貫のカスタマーサクセス管理が実現します。
この記事では、HubSpotを使ったカスタマーサクセスの実践方法を解説します。
本記事はHubSpotゴールドパートナーのStartLinkの「HubSpot完全ガイド」関連記事です。 この分野の体系的な情報は業界別HubSpot活用ガイドでまとめています。
この記事でわかること
HubSpotでカスタマーサクセスの仕組みを作りたいCS責任者・担当者の方に向けて、基盤設計から運用までの全体像を整理しています。
- HubSpotでカスタマーサクセスを管理するための基盤設計 — カスタムプロパティとCSパイプラインの作り方を解説します。
- オンボーディングプロセスの構築方法 — ワークフローで各ステップを自動化する設計を紹介します。
- ヘルススコアの設計とHubSpotでの実装 — 顧客の「健全性」を定量評価するスコアの設計例と実装の3段階を整理します。
- 解約防止のためのアラート・ワークフロー設計 — 解約シグナルの定義と通知設計を説明します。
- CS部門のKPIダッシュボード — 追うべき指標とレポートの種類を実務目線で解説します。
HubSpotの導入・活用を検討しているCS部門の方に向けて書いています。最後まで読むと、自社でCS管理の仕組みを設計し、最初の一歩を踏み出せるようになります。
カスタマーサクセスにHubSpotを活用するメリット
カスタマーサクセス専用のツールは数多くありますが、あえてHubSpotでCS管理を行う意味はどこにあるのでしょうか。大きな理由は、マーケティングから営業、カスタマーサクセスまでの顧客データが同一プラットフォーム上で連携する点です。コンタクト・会社・取引・チケットというオブジェクトがリレーションデータベースとして紐づいているため、「受注して終わり」ではなく、その後の顧客フォローまでを一つのフローとして設計できます。
マーケティング・営業からCSまでの一気通貫
HubSpotの強みは、マーケティング→営業→カスタマーサクセスまで同一プラットフォーム上でデータが連携する点です。各部門で蓄積されるデータとCSでの活用方法を整理すると、次のようになります。
| フェーズ |
データ |
活用方法 |
| マーケティング |
リード獲得経路、閲覧コンテンツ、関心領域 |
顧客の興味・課題を把握した上でオンボーディング |
| 営業 |
商談内容、導入目的、期待する成果 |
顧客の導入目的に合わせたサクセスプラン設計 |
| CS |
利用状況、問い合わせ履歴、満足度 |
ヘルススコア算出、解約リスク検知 |
他のCSツールと違い、営業が把握した「導入目的」や「期待する成果」がCRMに残っているため、CSチームは引き継ぎの際にゼロからヒアリングし直す必要がありません。受注(取引のClosed Won)を起点に、オンボーディングから定着支援、更新までを一つの流れとして扱えるのがHubSpotならではの利点です。
以下の図は、HubSpotのデータモデル設計図で、会社・コンタクト・取引などのオブジェクトがどのように関連付けられるかを示したものです。会社・コンタクト・取引・チケットを関連付けて管理するため、1社の顧客に関する情報を横断して確認できます。

スプレッドシート管理からの脱却
HubSpotであれば、顧客との過去のやり取りや契約情報、チケット履歴がすべてCRMに集約されます。手作業での転記や二重管理をなくし、CS担当者が誰でも同じ情報を見られる状態を作れる点が、スプレッドシート管理に対する本質的なメリットです。
以下の画面は、HubSpotの会社一覧画面です。顧客のレコードが一覧で管理されており、CS担当者は対象の顧客をすぐに見つけて状況を確認できます。

ただし専用CSツールとの差はある
一方で、正直な限界もあります。HubSpotはCSに特化したツールではないため、プロダクトの利用状況を自動で取り込んでスコア化するような専門機能は持ち合わせていません。Gainsightのような専用ツールと比べると、ヘルススコアの自動計算やプロダクト利用分析では機能が限られる部分があると考えています。顧客数がまだ少ない段階や、マーケティング・営業と一体で運用したい段階であればHubSpotで対応できるケースが多い一方、大規模なCS組織で高度な分析を行いたい場合は専用ツールとの併用も視野に入ります。
CS基盤設計:プロパティとパイプライン
CS管理を始めるにあたって最初に行うのが、顧客データを格納する「箱」の設計です。ここでは、会社プロパティとCSパイプラインという2つの基盤を設計します。
CSに必要なカスタムプロパティ
コンタクトプロパティと会社プロパティに、CS管理用の項目を追加します。会社単位で契約状況や健全性を管理するため、主に会社プロパティに以下の項目を用意します。
| プロパティ名 |
タイプ |
用途 |
| 契約プラン |
ドロップダウン |
契約プランの管理 |
| 契約開始日 |
日付 |
契約期間の管理 |
| 契約更新日 |
日付 |
更新タイミングの管理 |
| MRR(月次経常収益) |
数値 |
収益管理 |
| ヘルススコア |
数値 |
顧客の健全性スコア |
| CSステージ |
ドロップダウン |
オンボーディング/アクティブ/リスク/チャーン |
| CS担当者 |
HubSpotユーザー |
担当CS担当者 |
| NPS回答 |
数値 |
直近のNPSスコア |
ここで重要なのは、項目を必要最小限に絞ることです。
CSパイプラインの構築
取引パイプラインとは別に、CSのオンボーディング・リニューアル管理用のパイプラインを設計します。営業のパイプラインが「受注まで」を管理するのに対し、CSのパイプラインは「受注後」の顧客の状態を管理するものです。
オンボーディング用のパイプライン設計例は次のとおりです。
| ステージ |
内容 |
目標期間 |
| キックオフ準備 |
初回ミーティングの設定、アカウント準備 |
契約後3日以内 |
| キックオフ完了 |
目標・KPI・スケジュールの合意 |
契約後1週間以内 |
| 初期設定完了 |
基本設定・データインポートの完了 |
契約後2週間以内 |
| トレーニング完了 |
ユーザートレーニングの実施 |
契約後3週間以内 |
| 初回成果確認 |
最初の成果レビュー |
契約後1ヶ月以内 |
| オンボーディング完了 |
自走可能な状態の確認 |
契約後2ヶ月以内 |
ステージの分け方や目標期間は、自社のオンボーディングプロセスに合わせて調整してください。設定主体が顧客側にある商材と、導入支援型の商材とでは、ステージの粒度も目標期間も異なります。まずは自社の標準的なオンボーディングの流れを書き出し、抜け漏れが起きやすいポイントをステージとして切り出すのが設計のコツです。
パイプライン設計で押さえる4つの要素
営業パイプラインと同様に、CSパイプラインも次の4要素で考えると設計しやすくなります。
- ステージ: 顧客の状態が変化するポイントで分けます
- ステージ定義: 「このステージとは何か」を社内で合意しておきます
- 必須入力プロパティ: ステージ移行時に必要な情報の入力を促します
- 担当者: 各ステージの責任者を明確にします
例えば「キックオフ完了」ステージに進む条件を「目標とKPIに合意した状態」と定義し、合意したKPIをプロパティに必須入力させるようにすれば、担当者の記憶や判断に頼らず、仕組みとしてオンボーディング品質を担保できます。個人の力量ではなく仕組みで回す設計が、担当者が増えたときや引き継ぎが起きたときに効いてきます。
ワークフローで自動化するオンボーディング管理
基盤ができたら、次はオンボーディングの進行そのものを自動化します。受注からキックオフ、トレーニング、初回レビューまでの流れを担当者任せにすると、対応の抜け漏れや遅延が起きやすくなります。ワークフローでタスクと通知を自動化し、「仕組みで回る」状態を作るのがポイントです。
オンボーディング開始ワークフロー
受注をトリガーに、CS側の対応を一括で立ち上げるワークフローの設計例です。
- トリガー: 取引ステージが「Closed Won(受注)」に変更
- アクション1: CSステージを「オンボーディング」に変更
- アクション2: CS担当者を自動アサイン(ラウンドロビンで順に割り当て)
- アクション3: ウェルカムメール送信(キックオフの案内)
- アクション4: タスク作成「キックオフMTG設定」(CS担当者宛、期限: 3日後)
- アクション5: Slack通知(#cs-team チャネル)
営業が受注ステージを更新した瞬間にCS側のプロセスが動き出すので、「受注したのにCSに連絡が来ていない」という引き継ぎ漏れを防げます。ここも、営業からCSへの一気通貫の流れの中に位置づく自動化です。
進捗管理と遅延アラート
各ステージの完了条件を満たしたら自動的に次のステージへ進め、目標期間を超過した場合にアラートを出すワークフローを組み合わせます。例えば「初期設定完了」が契約後2週間を過ぎても更新されない顧客に対し、CS担当者とマネージャーに通知を出す設計です。
こうした遅延検知を入れておくと、マネージャーが一覧を目視確認しなくても、詰まっている顧客が自動で浮き上がってきます。
チェックリスト型のタスク自動作成
HubSpotのタスク機能を活用して、オンボーディングのチェックリストを自動作成する方法もあります。受注時のワークフローで次のようなタスクを一括作成します。
- キックオフMTGの実施
- 目標・KPIの合意
- アカウント初期設定の完了
- データインポートの完了
- ユーザートレーニング(管理者向け)
- ユーザートレーニング(一般ユーザー向け)
- 初回成果レビューの実施
- オンボーディング完了確認
タスクとして可視化されるため、担当者は「次にやるべきこと」を一覧で確認でき、新人のCS担当者でも標準的なオンボーディングをこなせるようになります。属人化しがちなオンボーディングを、仕組みで標準化する考え方です。
ヘルススコアの設計とHubSpotでの実装
オンボーディングが完了した顧客を「アクティブ」な状態で維持し続けるには、顧客の状態を定量的に把握する仕組みが必要です。そこで使われるのがヘルススコアです。
ヘルススコアとは
ヘルススコアは、顧客の「健全性」を定量的に評価するスコアです。スコアが高い顧客は継続・拡大が見込め、低い顧客は解約リスクがあると判断します。
スコア設計例(100点満点)
指標と配分の設計例は次のとおりです。
| カテゴリ |
指標 |
スコア配分 |
算出方法 |
| 利用状況 |
ログイン頻度 |
20点 |
週3回以上: 20点、週1回: 10点、月1回以下: 0点 |
| 利用深度 |
利用機能数 |
15点 |
5機能以上: 15点、3-4機能: 10点、1-2機能: 5点 |
| エンゲージメント |
CSとの定例MTG出席 |
15点 |
毎回出席: 15点、時々: 10点、不参加: 0点 |
| サポート |
チケット解決満足度 |
15点 |
満足: 15点、普通: 10点、不満: 0点 |
| NPS |
NPSスコア |
15点 |
推奨者(9-10): 15点、中立(7-8): 10点、批判者(0-6): 0点 |
| 契約 |
契約更新までの期間 |
10点 |
6ヶ月以上: 10点、3-6ヶ月: 5点、3ヶ月未満: 0点 |
| 成果達成 |
導入目的の達成度 |
10点 |
達成: 10点、進行中: 5点、未着手: 0点 |
どの指標をどの配分で見るかは、自社の商材や顧客との関わり方によって最適な形が異なります。例えば、利用状況データを取得しにくい商材であれば、エンゲージメントやNPSの比重を高める設計が考えられます。最初から完璧な配分を目指すより、主要な指標から始めて運用しながら調整していく進め方が現実的です。
HubSpotでの実装は3段階で考える
HubSpotには専用のヘルススコア機能はありません。そのため、カスタムプロパティとワークフローを組み合わせて実装します。自動化の度合いによって3つの方法があります。
| 方法 |
内容 |
向いている段階 |
| 手動更新 |
CSマネージャーが月次で各顧客のスコアを更新します |
顧客数が少ない初期段階 |
| ワークフローによる半自動化 |
利用状況やNPSなど一部指標はワークフローで自動計算し、定性的な指標は手動で補完します |
顧客数が増えてきた段階 |
| API連携による自動化 |
外部の利用状況データをHubSpot APIで自動連携してスコアを計算します |
精度を高めたい段階。開発リソースが必要です |
手動更新はシンプルに始められる反面、顧客数が増えると更新の負荷が高まります。API連携は最も精度が高い一方、開発リソースが必要になるため、最初は手動または半自動で運用を回し、運用が固まってから自動化の範囲を広げる段階的な広げ方をおすすめします。
スコア帯別のアクション設計
スコアは算出するだけでは意味がなく、帯ごとに打ち手を決めておくことが重要です。
| スコア帯 |
ステータス |
アクション |
| 80-100 |
健全(Green) |
アップセル・クロスセルの提案、事例インタビュー依頼 |
| 60-79 |
注意(Yellow) |
定例MTGの頻度増加、追加トレーニングの提案 |
| 40-59 |
リスク(Orange) |
CS担当者が個別フォロー、マネージャーエスカレーション |
| 0-39 |
危険(Red) |
緊急対応、上長を含めたリカバリープラン策定 |
スコアとアクションをセットで定義しておくと、「スコアが低いのは分かるが、誰がどう動くか」が曖昧になりません。
解約を防ぐアラート・ワークフロー設計
ヘルススコアは「定期健診」のような仕組みですが、スコアの更新を待たずに即座に検知したい変化もあります。そこで、解約につながる前兆を「解約シグナル」として定義し、ワークフローで自動検知する設計を加えます。
解約シグナルの定義
次のような行動パターンを解約シグナルとして定義し、優先度を付けて検知します。
| シグナル |
検知方法 |
アラート優先度 |
| ログイン頻度の低下 |
過去30日のログインが前月比50%以下 |
高 |
| サポートチケットの増加 |
月間チケット数が前月比2倍以上 |
中 |
| NPS低下 |
NPSが前回から3ポイント以上低下 |
高 |
| 定例MTG不参加 |
2回連続で定例MTGを欠席 |
中 |
| 決裁者の退職 |
主要コンタクトが退職・異動 |
高 |
| 契約更新3ヶ月前 |
更新日まで90日以内 |
情報 |
どの変化をシグナルとみなすかも企業によって異なります。
ヘルススコア低下アラート
スコアの低下をトリガーに担当者へ通知するワークフローの例です。
- トリガー: ヘルススコアが60未満に低下
- アクション1: CS担当者にメール・Slack通知
- アクション2: タスク作成「ヘルススコア低下顧客のフォロー」
- 条件分岐: スコアが40未満の場合はCSマネージャーにもエスカレーション通知
通知だけで終わらせず、タスク作成までセットにしておくのがポイントです。通知は流れてしまいますが、タスクとして残れば対応の抜け漏れを防げます。
契約更新リマインダー
更新日を起点にしたリマインダーの例です。
- トリガー: 契約更新日まで90日
- アクション1: CS担当者にタスク作成「更新準備の開始」
- 遅延: 30日後
- アクション2: 更新提案メールの送信(テンプレート)
- 遅延: 30日後
- 条件分岐: 更新完了の場合はワークフロー終了、未完了の場合はマネージャーへエスカレーション
「更新日が近づいてから慌てて連絡する」という事態を避け、余裕を持って更新準備に入れる設計です。
解約理由を記録して部門間で共有する
解約を「失敗」で終わらせず、組織の学習材料に変える考え方です。
CS部門のKPIダッシュボード
オンボーディングやヘルススコア、アラートの仕組みが動き始めたら、それらが成果につながっているかを可視化します。ダッシュボードでCS部門のKPIを一覧化し、週次・月次のレビューで使える状態にしておきます。
追うべきKPIとレポート
| KPI |
測定内容 |
レポート種類 |
| チャーン率 |
月間・四半期の解約率 |
数値KPI |
| NRR(Net Revenue Retention) |
収益維持率(アップセル含む) |
数値KPI |
| オンボーディング完了率 |
期限内にオンボーディング完了した顧客の割合 |
棒グラフ |
| オンボーディング所要日数 |
平均オンボーディング期間 |
数値KPI |
| ヘルススコア分布 |
Green/Yellow/Orange/Redの分布 |
ドーナツチャート |
| NPS推移 |
NPS平均スコアの月次推移 |
折れ線グラフ |
| チケット解決時間 |
サポートチケットの平均解決時間 |
数値KPI |
| CS担当者別の顧客数 |
担当者あたりの担当顧客数 |
テーブル |
ダッシュボード運用のポイント
ダッシュボードは作って終わりではなく、レビューの場で「見て、次の打ち手を決める」ために使います。例えば、ヘルススコア分布のRed比率が増えた月は個別顧客のフォロー状況を掘り下げる、というように、KPIとアクションを結びつけて運用するのがコツです。数値の変化に対して「誰が・いつまでに・何をするか」まで落とせると、ダッシュボードが経営判断の基盤として機能します。
スモールスタートで進める導入ステップ
ここまでの仕組みを一度に全部作る必要はありません。CS管理の仕組み化は、小さく始めて段階的に広げる進め方がうまくいきやすいです。すべてを一気に自動化しようとすると、設計に時間がかかりすぎて運用が始まらない、という事態になりがちです。
段階的な広げ方
| 段階 |
作るもの |
ねらい |
| 第1段階 |
CSステージのプロパティ追加とオンボーディングパイプライン |
顧客の状態を一覧で見える化する |
| 第2段階 |
オンボーディング開始ワークフローとタスク自動作成 |
引き継ぎ漏れと対応遅延を防ぐ |
| 第3段階 |
ヘルススコア(まず手動または半自動) |
顧客状態を定量評価する |
| 第4段階 |
解約アラートとKPIダッシュボード |
早期検知と継続改善のサイクルを回す |
まずは「顧客の状態が一覧で見える」状態を作り、運用しながら自動化の範囲を広げていく順番が、現場の負荷を上げすぎずに定着させやすい進め方です。どの段階まで進めるかは、顧客数やCS担当者の人数によって企業ごとに最適な形が異なります。
HubSpotでのCS管理が向かないケース
率直に言えば、次のようなケースではHubSpot単体でのCS管理が合わない可能性があります。
- プロダクトの詳細な利用ログをリアルタイムでスコア化したい場合は、API連携など別途開発が必要になります
- 大規模なCS組織で高度な分析やプレイブック管理を行いたい場合は、専用CSツールのほうが適する場合があります
その範囲であれば、営業・マーケティングと同じ基盤でCS管理を始められるHubSpotは十分な選択肢になります。
よくある質問
HubSpotを使ったカスタマーサクセスについて、導入検討の段階でよく寄せられる質問をまとめました。
Q1. HubSpotのどのプランでCS管理ができますか?
基本的なプロパティ管理とパイプラインはCRMの無料プランで利用できます。ワークフローによる自動化にはService Hub Professional以上、カスタムレポートにはProfessional以上が必要です。本格的なCS運用にはService Hub Professionalを推奨します。
Q2. 専用のCSツール(Gainsight等)と比べてどうですか?
HubSpotはCSに特化したツールではないため、ヘルススコアの自動計算やプロダクト利用分析といった専門機能はGainsight等に劣ります。ただし、マーケティング→営業→CSを一気通貫で管理しやすい点や、既にHubSpotを利用していれば追加のツール導入なしでCS管理を始められる点はメリットと考えています。顧客数が少ない段階ではHubSpotで対応できるケースが多いです。
Q3. ヘルススコアは最初から設計すべきですか?
最初はシンプルなスコア(3〜5指標で50点満点程度)から始めて、運用しながら指標を追加・調整していくアプローチが現実的です。完璧なスコア設計を目指すより、まずは始めてデータを蓄積することが重要です。
Q4. CS担当者1人あたり何社を担当するのが適切ですか?
ハイタッチ(大口顧客)とテックタッチ(小口顧客)では、1人あたりが担当できる社数の目安が大きく異なります。HubSpotの自動化機能を活用すると、テックタッチ顧客の管理を効率化し、ハイタッチ顧客に集中できる体制を作れます。
Q5. NPS調査はどのくらいの頻度で実施すべきですか?
四半期に1回のリレーショナルNPS(全体的な満足度)と、主要タッチポイント後のトランザクショナルNPS(オンボーディング完了後、サポート対応後等)を組み合わせるのが効果的です。HubSpotのアンケート機能で自動配信できます。
まとめ
HubSpotを活用したカスタマーサクセスは、CRMデータの一気通貫活用、オンボーディングの自動化、ヘルススコアによる状態可視化、解約シグナルの早期検知を実現します。本記事の要点を整理すると次のとおりです。
- CS基盤設計: カスタムプロパティとCSパイプラインを構築します
- オンボーディング自動化: ワークフローとタスクで進捗管理を仕組み化します
- ヘルススコア: 利用状況・エンゲージメント・NPSを定量評価し、帯別のアクションを決めます
- 解約防止: アラートワークフローで解約シグナルを早期検知します
- KPIダッシュボード: チャーン率・NRR・NPSなどを可視化して改善サイクルを回します
まずは、CSステージのプロパティ追加とオンボーディングパイプラインの構築から始めることをおすすめします。「顧客の状態が一覧で見える」基盤ができてから、ヘルススコアや解約アラートを段階的に追加していく進め方が現実的です。
自分で進める場合の最初の3ステップは次のとおりです。
- 自社のオンボーディングの流れを書き出し、抜け漏れが起きやすいポイントを洗い出す
- 会社プロパティにCSステージ・契約更新日・CS担当者を追加し、オンボーディング用パイプラインを作る
- 受注(Closed Won)をトリガーに、CS担当者へタスクを自動作成するワークフローを1本動かしてみる
CRMを活用した業務効率化やAIとの連携に関するご相談は、CRM特化型コンサルティングのHubSpotゴールドパートナーのStartLinkまでお気軽にお問い合わせください。
あわせて読みたい