BtoB SaaS向け カスタマーサクセス管理システム（HubSpot）
解約の兆候を、更新直前ではなく“今”つかむ。利用状況・契約情報・ヘルススコアを一つに。
Overview
プロジェクト概要
BtoB SaaSのカスタマーサクセス（CS）チーム向けに、プロダクトの利用データとHubSpotの契約情報を日次でつなぎ、ヘルススコアで解約リスクを早期に可視化する仕組みを構築しました。閾値を下回った顧客のSlack通知、更新日を基準にしたフォロータスクの生成、AIによるフォローメールの下書きまでを、一つの業務フローとしてまとめています。
導入前は、利用データはサービス側のDBに、契約・更新日・担当CSの情報はHubSpotにあり、両者を同時に確認する手段がありませんでした。利用状況は月1回のCSV出力で確認していたため、利用の低下に気づくのが契約更新の直前になりがちでした。「利用が落ちている」と判断する基準も担当者ごとに異なっていました。当社は、要件整理からシステム設計、スコア設計、開発、テストまでを担当しました。
※ お客様名は記載していません。掲載している画面とデータは、説明用に再構成したイメージです。
- 分類
- IT／BtoB SaaS（カスタマーサクセス管理システム）
- 対象
- BtoB SaaSの契約顧客（会社単位）。日々使うのはCS担当
- 判定
- ログイン頻度・機能利用・席数利用率の重み付けスコア（ヘルススコア）
- 連携先
- HubSpot / Slack / LLM API
- 業種
- IT・BtoB SaaS
- ロール
- 要件整理 / システム設計 / スコア設計 / HubSpot設定 / 日次集計バッチ・Slack通知・AI下書き機能の開発 / テスト
- 技術
- HubSpot / Node.js / TypeScript / PostgreSQL / Slack API / LLM API
01 — 導入前の課題
気づいたときには、もう更新日が近い
利用データはプロダクトのDBに、契約情報はHubSpotにあり、別々に確認する必要がありました。利用状況は月1回のCSVで確認していたため、週単位の変化は見えません。「利用が落ちている」の判断基準も担当者ごとに違い、同じ状況でも対応する人としない人が出ていました。その結果、更新日が近づいてから、慌てて状況を確認する状態でした。
- 利用データと契約情報が別々のシステムにある
- 利用状況の確認は月1回のCSV
- 利用低下の判断基準が担当者ごとに違う
- 更新直前になってから状況を確認
02 — ヘルススコアと通知
見るべき顧客が、朝から分かる
毎朝、プロダクトDBから前日分のログイン・機能利用・有効ユーザー数を会社単位で集計し、ヘルススコア（0〜100）と区分（健全／注意／危険）を算出してHubSpotの会社に反映します。スコアは、ログイン頻度・主要機能の利用・席数利用率の3指標を正規化し、重みを掛けて合算したものです。担当CSは、HubSpotの保存済みビュー「要フォロー顧客」から一日を始めます。区分が「危険」に変わった会社や前週差が大きく下がった会社は、Slackの #cs-alert に、スコアと指標、契約更新日、HubSpotへのリンク付きで通知されます。
- 利用データを日次で集計し、履歴として保存
- 3指標の重み付けでヘルススコアと区分を算出
- HubSpotの一覧で「要フォロー顧客」を抽出
- 区分が悪化した会社だけをSlackへ通知
開発中の課題と解決
利用データとHubSpotの会社を、テナントIDで結び付ける
- 課題
- 利用データはサービス側のDBに、契約の情報はHubSpotにあり、両者をそのままではつなげられませんでした。
- 解決
- 顧客の単位をHubSpotの「会社」とし、プロダクト側のテナントIDを一意のカスタムプロパティとして持たせて、突合キーにしました。突合できない場合は反映をスキップし、未突合リストとしてSlackへ通知します。プロダクトDBには読み取り専用ユーザーで接続し、本番サービスへの書き込みは一切行いません。
03 — AIによるフォローメールの下書き
AIが書く。最後に決めるのは、人
担当CSが会社レコードの「フォロー下書き作成」ボタンを押すと、利用状況の要約と契約情報をもとに、LLM APIがフォローメールの下書きを作り、メモとして保存します。担当者は下書きを確認・修正してからHubSpotで送信し、CSフォロー状況を「対応中」に更新します。AIが作ったメールが、そのまま送られることはありません。
- 利用状況を要約し、フォローメールを下書き
- 下書きはメモとして保存
- 担当CSが確認・修正してから送信
- LLM APIが応答しないときは、タスクのみを起票
開発中の課題と解決
AIに渡す情報を絞り、送る前に必ず人が確かめる
- 課題
- 顧客の利用データをそのままAIに渡すと、個人の操作ログが外部へ出てしまうおそれがあります。AIの文面をそのまま送ることにも、品質面のリスクがあります。
- 解決
- LLM APIへは会社名と指標の要約のみを渡し、個人の操作ログそのものは送らない設計にしました。下書きはメモとして保存し、送信は必ず担当者が内容を確認してから行います。
04 — 更新日から逆算したフォロー
更新日から逆算して、次の一手を先に作る
契約更新パイプラインの取引に対してHubSpotのワークフローを設定し、契約更新日を基準にタスクを自動で起票します。初期設定では、更新日の90日前に全顧客の利用状況レビュー、60日前に「注意」「危険」の顧客への打ち合わせ設定、30日前に全顧客への更新見積の送付を起票します。区分が悪化した顧客の更新日が120日以内なら、期限3営業日の優先フォローを起票します。CSフォロー状況は「通常 → 要フォロー → 対応中 → 回復確認中 → 通常」と遷移し、回復後も一定期間（初期設定14日）推移を見守ります。
- 更新日の90日前・60日前・30日前にタスクを自動起票
- ヘルス区分によってタスクの内容を分岐
- 区分悪化時は優先フォローを起票
- CSフォロー状況の遷移と、回復後の見守り
開発中の課題と解決
スコアの基準を、運用しながら見直せるようにする
- 課題
- 最初に決めた重みや閾値が、実際の更新・解約の結果に合っているとは限りません。基準を変えると、過去のスコアと比べられなくなるおそれもあります。
- 解決
- 重みと閾値は設定ファイルで管理し、運用しながら調整できる設計にしました。変更はCSマネージャーが承認し、システム管理者が反映します。スコアの算出に使った重み設定のバージョン（score_version）を履歴に残すため、基準を見直した後も過去のスコアと比較できます。
Scope
担当範囲
当社は、要件整理、システム設計、スコア設計、開発、テストを担当しました。
| 工程 | 担当 |
|---|---|
| 要件整理 | CSチームへのヒアリングによる、現在のフォロー手順、更新管理の方法、「解約しそう」と感じる兆候の整理 |
| システム設計 | HubSpot、PostgreSQL、日次バッチの役割分担と構成。テナントIDとHubSpotの会社の紐づけ方法、集計指標、データ設計 |
| スコア設計 | 過去の利用データを使った指標と重みの候補づくりと、CSチームの肌感と照らし合わせた初期設定の決定 |
| 開発 | HubSpotのカスタムプロパティ・保存済みビュー・ワークフローの設定、日次集計バッチとSlack通知、AI下書き機能の開発 |
| テスト | 既存のCSV確認と並行した、スコアと通知の確認と、閾値や通知条件の調整 |
Architecture
使用技術・システム構成
- HubSpot
- CRM。CS担当が日々見る画面。スコアをカスタムプロパティとして保持し、ワークフローでタスクの起票とSlack通知を行う
- Node.js / TypeScript
- 日次集計バッチ。会社単位で利用指標を集計し、ヘルススコアを算出してHubSpotへ反映する
- PostgreSQL
- 利用データとスコアの履歴置き場。日次の利用指標とスコアを保存し、推移の比較や基準の見直しに使う
- Slack API
- 通知。解約リスクの通知を #cs-alert チャンネルへ送る
- LLM API
- 利用状況の要約から、フォローメールの下書きを作成する。担当者が確認してから送信する
主な技術の選定理由
HubSpotを「日々見る画面」に、PostgreSQLを「履歴置き場」に
CS担当はいつものHubSpotの画面で判断でき、推移の比較や基準の見直しに必要な履歴は、別の置き場で持てるようにするためです。
区分が悪化した会社だけを通知
毎日同じ会社が流れ続けると、通知が見られなくなるためです。トライアル中・導入直後の会社は通知の対象から外し、長期休暇などの時期はCSマネージャーが通知を一時停止できます。
一括更新APIと再試行キュー
HubSpot APIのレート制限に備えるためです。失敗した分は再試行キューで処理します。
Process
開発の進め方
- 1
1 要件整理：CSチームの現在のフォロー手順、更新管理の方法、「解約しそう」と感じる兆候をヒアリングして整理しました。
- 2
2 データ調査・突合設計：プロダクトDBのテーブル構造を確認し、テナントIDとHubSpotの会社の紐づけ方法と、集計指標を決めました。
- 3
3 スコア設計：過去の利用データを使って指標と重みの候補を作り、CSチームの肌感と照らし合わせて初期設定を決めました。
- 4
4 HubSpot設定・バッチ開発：カスタムプロパティ・保存済みビュー・ワークフローを設定し、日次集計バッチとSlack通知を開発しました。
- 5
5 AI下書き機能の開発：利用状況の要約から下書きを作るプロンプトを設計し、担当者の確認を前提とした操作フローに組み込みました。
- 6
6 テスト・並行運用：既存のCSV確認と並行してスコアと通知を確認し、閾値や通知条件を調整しました。
- 7
7 本番運用・振り返り：本番運用に切り替え、スコアと実際の更新結果を照らし合わせて重みを見直す運用を整えました。
Quality & Security
品質・セキュリティ・運用
権限の設計
CS担当は担当会社の閲覧・編集とメール送信、CSマネージャーは全会社の閲覧・編集と重み・閾値の変更承認、システム管理者はプロパティ・ワークフローと設定ファイルの管理を担います。連携バッチは、会社・取引の読み書きに限った非公開アプリのトークンで接続します。
例外時の運用
テナントIDが突合できない会社は反映をスキップして通知し、トライアル中・導入直後の会社は通知の対象から外します。LLM APIが応答しない場合は、下書きなしでタスクのみを起票します。
監視とログ
日次バッチの開始・終了・処理件数・失敗件数を記録し、失敗した場合や処理件数が前日から大きく減った場合は、管理者向けのSlackチャンネルへ通知します。
つなぐ先への配慮
プロダクトDBには読み取り専用ユーザーで接続し、本番サービスへの書き込みは一切行いません。
Results
成果
CSチームが「気づいてから動く」のではなく、「兆候が出た時点で動ける」業務の土台を整えました。スコアの重みと閾値を設定として切り出しているため、実際の更新・解約の結果を見ながら、基準を育てていくことができます。
- 利用状況と契約情報を、HubSpotの同じ画面で確認できるようになりました。
- 利用データを日次で集計・履歴保存し、月1回のCSV確認では見えなかった変化を追えるようになりました。
- 共通のヘルススコアと閾値により、担当者ごとの判断のばらつきをなくしました。
- 解約リスクの兆候を契約更新の前に把握し、更新日から逆算したフォローを計画的に行える状態にしました。
- フォローメールはAIが下書きを作り、担当者が確認・修正して送信する運用で、品質を担保しています。
FAQ
技術面のよくあるご質問
- Q. ヘルススコアは、どのように計算していますか？
- ログイン頻度・主要機能の利用・席数利用率の3指標を0〜100に正規化し、重みを掛けて合算します。あわせて、ヘルス区分（健全／注意／危険）を算出します。重みと閾値は設定ファイルで管理し、運用しながら調整できます。
- Q. 本番のサービスやHubSpotに、負担や影響はありませんか？
- プロダクトDBには読み取り専用ユーザーで接続し、本番サービスへの書き込みは一切行いません。HubSpotには一括更新APIで反映し、レート制限に備えて、失敗分は再試行キューで処理します。
- Q. AIが作ったメールが、そのまま送られることはありますか？
- ありません。下書きはメモとして保存し、送信は必ず担当者が内容を確認してから行う運用です。また、LLM APIへは会社名・指標の要約のみを渡し、個人の操作ログそのものは送りません。
- Q. 基準を見直すと、過去のスコアと比べられなくなりませんか？
- スコアの算出に使った重み設定のバージョン（score_version）を履歴に残しているため、基準を見直した後も、過去のスコアと比較できます。
Tech Stack