SaaSのCRMデータ設計｜アカウント・契約・ライセンスの3層をどう持つか

SaaSのCRMデータ設計とは、契約する法人（会社）、製品側で実体を持つテナント（アカウント）、実際に付与されるライセンスの3つを、別々のレコードとして持ち分ける作業です。 契約は取引、ライセンスは商品項目、使う人はコンタクトで持ち、管理者・利用者・決裁者といった立場は関連付けラベルで表します。 この形にしておくと、契約更新の交渉に必要な数字と、日々の利用状況の変化を、同じデータから両方追えます。

「契約している会社」と「実際に製品を使っている単位」が一致しない——SaaSでCRMを設計すると、ここで必ず引っかかります。

親会社と契約しているのに使っているのは子会社の事業部、1つの法人に本番用と検証用の2つのテナントがある、退職した管理者のアカウントが残ったまま——こうした状況は、SaaSを提供している側なら日常的に起きています。ところが一般的なCRMの設計は、会社が1つ、担当者が数名、取引が1件という前提で書かれています。

つまりSaaSのCRM設計は、項目を並べる作業ではありません。契約の単位と、製品の単位と、人の単位がそれぞれ別であることを、データの形で認めてしまう作業です。ここを揃えようとすると、どこかで必ず破綻します。

この記事では、HubSpotを例に、SaaS事業のデータ構造をCRM上でどう設計するかを整理します。SaaSを提供していてCRMを組み直す立場の方、カスタマーサクセスの体制を作ろうとしている方に向けた内容です。次の4点がわかります。

• 3層をどのオブジェクトで持つか ── 会社・取引・商品項目の役割分担です
• 利用ユーザーとコンタクトの繋ぎ方 ── 管理者と決裁者を分けて持つ設計です
• 製品の利用状況をどこまで入れるか ── 生ログを入れてはいけない理由と代替です
• プロダクトのデータベースとの境界 ── どちらを正とするかの決め方です

読み終える頃には、自社のプロダクト構造をCRM上でどう写し取るかのたたき台が作れる状態になります。ぜひ最後までご確認ください。

SaaSのCRMが「会社1件」で収まらない理由

まず、なぜ一般的な設計がそのまま当てはまらないのかを整理します。原因は営業体制ではなく、SaaSというビジネスモデルの構造にあります。

契約の単位と利用の単位がずれる

SaaSの設計を難しくしているのは、次の3つの単位が一致しないことです。

このずれを無視して会社レコード1件にまとめると、「契約金額は見えるが、誰がどれだけ使っているか分からない」という状態になります。更新の3か月前に慌てて利用状況を調べ始めることになるのは、たいていこれが原因です。

状態が時間とともに変わり続ける

もう1つの特徴は、契約後も状態が変わり続けることです。ライセンス数が増える、プランが上がる、管理者が交代する、一部の部署だけ解約する——買って終わりの商材と違い、受注後のほうが情報の変化量が多いのがSaaSです。

CRMを「受注までを管理する道具」として設計すると、受注後の変化を受け止める場所がなくなります。ここが最初の分かれ目です。

無償ユーザーを同じ場所に置けるか

フリープランやトライアルを持っている場合、有償顧客と同じ設計で持てるかという論点が出てきます。結論としては同じオブジェクトで持ち、状態の違いはプロパティーで表すのが扱いやすい形です。無償と有償でオブジェクトを分けると、有償化したときにレコードを作り直すことになり、それまでの履歴が切れます。

なお、プロダクト主導の獲得（PLG）と営業主導の獲得を組織としてどう両立させるかという戦略面の論点はPLG × PLSハイブリッド戦略で、PLGそのものの考え方はPLG（プロダクトレッドグロース）とはで扱っています。本記事はデータの持ち方に絞ります。

アカウント・契約・ライセンスの3層をどう持つか

ここからが設計の本体です。

これは特定の企業の実装ではなく、SaaS事業でよく出てくる構造を一般化した設計例です。

契約法人は会社オブジェクト

請求書の宛先になる法人は、会社オブジェクトで持ちます。ここは迷う余地がありません。

テナントは会社の子レコードから始める

製品側のテナント（ワークスペース、環境、サブアカウントなど呼び方はさまざまです）をどう持つかが最初の判断です。選択肢は2つあります。

• 会社オブジェクトの子レコードとして持つ：テナントが事業部や子会社と一対一で対応する場合はこちらが自然です。会社同士の関連付けで親子を表現します
• カスタムオブジェクトで持つ：テナントが法人と対応しない（1人が複数ワークスペースを作れる等）場合はこちらが必要になります

ただしHubSpotでは、カスタムオブジェクトの作成はMarketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRM・Revenue Hubのいずれかの Enterprise が要件です（カスタムオブジェクトを作成する）。まずは会社の親子関係で始め、足りなくなってから移すほうが失敗が小さくなります。判断の軸はカスタムオブジェクトを作るべきかの判断基準で整理しています。

契約は取引、更新のたびに新しく作る

契約は取引オブジェクトで持ちます。更新のたびに新しい取引を作り、前年の取引はそのまま残してください。 同じ取引を使い回すと、去年の契約条件が上書きされて消えます。SaaSは条件変更が頻繁に起きるため、履歴が残らない設計は後で必ず困ります。

ライセンスは商品項目で持つ

プラン名・シート数・単価・契約期間は、取引にぶら下がる商品項目で持ちます。この形にすると、次の3つが自動的に扱えるようになります。

• 契約金額の内訳：どのプランで何シートかが明細で残ります
• 増減の記録：期中のシート追加を行の追加として残せます
• 更新時の比較：前年の取引の明細と並べれば、増減がそのまま見えます

MRRの推移やチャーン分析といった指標の作り方はSaaS企業のMRR管理・チャーン分析で扱っています。本記事はその手前のデータ構造に絞ります。

利用ユーザーとコンタクトをどう繋ぐか

SaaSでは、1つの契約に対して複数の関係者が存在します。ここを1種類のコンタクトとして扱うと、送るべき相手を間違えます。

役割は関連付けラベルで表す

コンタクトに「役割」というプロパティーを持たせるのは、一見わかりやすい設計です。ただしこれは破綻します。同じ人が、ある契約では決裁者で、別の契約では利用者にすぎない、という状況が起きるためです。

正しくは、契約（取引）とコンタクトの関連付けそのものに名前を付けます。HubSpotの関連付けラベルは、Marketing Hub・Sales Hub・Service Hub・Data Hub・Content Hub・Smart CRMの Professional 以上で利用でき、1つのオブジェクトペアにつき最大50個のラベルを作成できます。コンタクト対コンタクトのように同じオブジェクト同士の関連付けにも使えます（関連付けラベルを作成して使用する）。

ラベルには、両側を同じ言葉で表す単一のラベルと、「マネージャー」と「従業員」のように両側で異なる言葉を使うラベルのペアの2種類があります。

最低限持ちたい4つの役割

この4つを分けておくと、送るメールの中身が変わります。 障害連絡を決裁者に送っても対応できませんし、料金改定の案内を利用者に送っても判断できません。

退職と異動に耐える設計

SaaSで最も情報が失われるのが、担当者の交代です。コンタクトを削除せず、役割のラベルだけを外す運用にしてください。過去のやり取りが残ったまま、現在の担当者が誰かも分かる状態になります。「退職」というプロパティーを立てて上書きすると、過去の会話の主が誰だったか分からなくなります。

製品の利用状況をどこまでCRMに入れるか

SaaSのCRM設計で最も判断が難しいのがここです。

生ログは入れない

まず原則です。イベントの生ログをCRMに流し込んではいけません。 1ユーザーが1日に数十回発生させるイベントを全件受けると、レコードが膨れ上がり、しかも誰も見ません。

CRMに必要なのは、ログそのものではなく、ログから導かれた状態です。

入れるべき集計指標

最初に持つべきは、次の4つに絞ることをおすすめします。

• 直近30日のアクティブユーザー数：契約シート数と比べることで消化率が出ます
• 最終ログイン日：全社的な停止をいち早く検知できます
• 主要機能の利用有無：定着したかどうかの唯一の判定材料です
• シート消化率：アップセルの余地と、逆に減席リスクの両方が見えます

この4つがあれば、更新の3か月前に危険な契約を抽出できます。 これ以上の指標は、この4つを使い始めてから足すので十分です。

カスタム行動イベントを使う場合の要件

Webサイト上や製品内の行動をHubSpot側でイベントとして受ける方法もあります。HubSpotのカスタム行動イベントは Marketing Hub Enterprise で利用でき、手動でトラッキングされるイベント（APIを使用）、要素クリックイベント、URL訪問イベントの3つの作成方法があります。各イベント完了には最大50個のプロパティーのデータを含めることができ、プロパティーラベルと内部名は50文字、URLとリファラーは最大1024文字、その他は最大256文字に制限されています。プロパティーの内部名はアルファベットで始まる必要があり、使用できるのは小文字のa〜z、数字の0〜9、アンダースコアのみです（カスタム行動イベントを作成する）。

Enterpriseが要件であるという点は、設計前に必ず確認してください。 Professionalで運用している場合は、プロダクト側で集計した値をプロパティーとして書き込む方式が現実的な代替になります。

スコアリングで優先順位を付ける

集計指標を持てたら、それを使って優先順位を付けられます。HubSpotのスコアリングは Marketing Hub と Sales Hub の Professional・Enterprise で利用でき、エンゲージメントスコアと複合スコアを作成できます。追跡できるイベントには、フォーム送信、ページ訪問、メール開封、ワークフロー登録完了、メール内リンククリック、配信登録ステータス更新、CTAクリック、マーケティングイベント参加・登録完了、配信不能メール、メディア再生、メール配信が含まれます（インパクトの大きいイベントに基づいてリードをスコアリングする）。

ただし正直に書くと、製品内の行動はこの一覧に含まれません。製品利用の深さを反映させたい場合は、プロダクト側で算出した値をプロパティーとして持ち、それをスコアの条件に使う形になります。

プロダクトのデータベースとの境界

最後に、どちらを正とするかを決めます。

判断の目安は、「認証と課金の正確性が問われるものはプロダクト側、判断と経緯はCRM側」です。

両方に持つ項目は、必ず片方向の同期にしてください。双方向にすると、値が食い違ったときに原因を追えなくなります。SaaS事業でのHubSpot活用の全体像はSaaS企業のHubSpot活用法にまとめています。

よくある質問

SaaSのCRMデータ設計について、ご相談の場でよくいただく質問をまとめました。

Q1. テナントを会社オブジェクトで持つと、会社レコードが増えすぎませんか。

増えますが、それ自体は問題になりません。問題になるのは、どれが契約主体でどれがテナントか区別できない状態です。会社同士の関連付けに「契約法人」「テナント」のラベルのペアを設定し、あわせて会社のプロパティーに「レコード種別」を持たせておけば、一覧で分けて表示できます。区別できていれば数は障害になりません。

Q2. フリープランのユーザーもコンタクトとして持つべきですか。

持つべきですが、マーケティングの配信対象に自動で入れないでください。フリープラン登録と、メール配信への同意は別のものです。同意の状態はプロパティーで明確に持ち、配信対象のリストは同意を条件に作ります。人数が多いプロダクトでは、ここを分けておかないと配信停止と苦情が急増します。

Q3. 契約とライセンスを両方カスタムオブジェクトにするのは間違いですか。

間違いではありませんが、多くの場合は不要です。契約は状態が進むもの（提案→交渉→締結→更新）なので取引が向いており、ライセンスは金額の明細なので商品項目で表せます。カスタムオブジェクトが必要になるのは、契約とは独立して存在し、状態が変わらない台帳（例：発行済みのAPIキーや機器のシリアル）です。標準オブジェクトで表せるものを、わざわざEnterprise要件のカスタムオブジェクトにする理由はありません。

Q4. 利用状況の連携は、どのくらいの頻度で更新すべきですか。

1日1回で十分です。 リアルタイム更新にすると、連携の負荷と障害対応の手間が増えるわりに、CRM側で使える場面がほとんどありません。カスタマーサクセスの判断は日次の粒度で足ります。例外は、トライアル期間中のフォローのように時間単位で反応したいケースで、この場合だけ対象を絞ってリアルタイムに寄せます。

Q5. すでに会社レコードとテナントが混ざっています。どこから直せばよいですか。

一度に直そうとせず、契約金額の大きい順に上位20社から手を付けてください。全件を整理してから運用を始めようとすると、着手できないまま終わります。整理の手順は、①契約主体を1つに決める ②残りをテナントとして関連付ける ③関係者に役割ラベルを付ける、の3ステップです。上位20社が終わった時点で、更新交渉に必要な情報の大半は揃います。

関連記事

• SaaS企業のHubSpot活用法 ── SaaS事業でのHubSpot活用の全体像です
• SaaS企業のMRR管理・チャーン分析 ── 指標の作り方と解約防止の設計です
• ECカートとCRMの連携設計 ── 外部システムとの境界の引き方です
• HubSpotでサブスクリプション売上を管理する方法 ── 更新管理と解約防止の実装です
• カスタムオブジェクトを作るべきかの判断基準 ── 標準オブジェクトで足りるかの判断軸です
• PLG × PLSハイブリッド戦略 ── 製品主導と営業主導を両立する戦略設計です

まとめ

SaaSのCRMデータ設計は、契約・製品・人の単位がずれていることを認めたうえで、それぞれを繋ぐ作業です。要点を整理します。

• 契約法人は会社、テナントは会社の子レコードから始める。足りなくなってからカスタムオブジェクトを検討します
• 契約は取引、ライセンスは商品項目。更新のたびに新しい取引を作ります
• 決裁者・契約担当・管理者・主要利用者を関連付けラベルで分ける。送る内容が変わります
• 担当交代はラベルを外す。コンタクトは消さない。過去のやり取りを失わないためです
• 生ログは入れず、集計指標を4つだけ持つ。アクティブユーザー数・最終ログイン日・主要機能の利用有無・シート消化率です
• 認証と課金はプロダクト側、判断と経緯はCRM側。両方に持つ項目は一方向同期にします

最初の一歩としておすすめしたいのは、「契約金額上位10社について、決裁者・管理者・主要利用者の氏名を書き出す」ことです。書き出せない社があるなら、そこが更新時に最も危ない契約です。

そのうえで、役割ラベルを4つ作り、上位10社から付け始める。ここから始めるのが現実的です。

自社のプロダクト構造に合わせたCRM設計を具体的に検討したい場合は、StartLinkの無料相談でご相談ください。現在の契約形態と製品側のデータ構造をうかがったうえで、設計の方向性をご提案します。