はじめに：どちらの数字が正しいのか
Salesforceでは今月の受注が「2.1億円」。HubSpotでは「1.8億円」。営業会議は、どちらを信じるかという確認から始まる——こんな状況が、実際の現場で起きています。
マーケティングがHubSpot、営業がSalesforce、集計はExcel、レポートはLooker Studioという構成になっている場合、この問題は特に起きやすくなります。
最初に確認しておきたいことがあります。この問題の原因は、SalesforceにもHubSpotにもありません。問題は、「どの数字を、何の定義で、どのシステムを正として扱うか」が設計されていないことにあります。
なぜSalesforceとHubSpotで数字がズレるのか
多くの企業では、SalesforceとHubSpotが別々の目的で導入されています。HubSpotはマーケティング・リード管理、Salesforceは営業・商談管理——この構成は自然です。しかし、問題はその後に起きます。
HubSpotは「マーケティング視点」でデータを構成します。フォーム送信、広告流入、MQL、メール開封、スコアリングといった情報が、リード単位で蓄積されます。一方Salesforceは「営業視点」の構造です。商談、案件金額、受注予測、パイプライン、営業活動が中心になります。
この2つのシステムが並走するとき、問題はツールの性能ではなく、定義と役割が設計されていないことから生まれます。
よくある「数字ズレ」の実例
数字がズレる原因は1つではありません。現場でよく見られるパターンは、次の4つです。
01
商談作成タイミングが違う
マーケティング側では「問い合わせが来た時点」を商談化とみなし、営業側では「初回商談が終わったら」を商談化とする。このズレが生じると、商談数・商談化率・SQL数がシステムごとに異なる値になります。どちらかが間違っているのではなく、タイミングの定義が揃っていないことが原因です。
02
同じ顧客が複数のシステムに存在する
HubSpotはメールアドレス基準で顧客を管理し、Salesforceは会社名基準で管理する。この違いから、同じ会社が複数登録され、名寄せされないままアカウントが重複する状態になります。これがARR・顧客数・LTVのズレとして表れます。
03
ステージ定義が違う
HubSpotでは「MQL」、Salesforceでは「SQL」という言葉を使っていても、何をMQLとするか、いつSQLへ移行するかの条件が曖昧なままになっているケースがあります。この状態では、営業は「リードの質が低い」と感じ、マーケティングは「営業が追っていない」と感じます。これはツール問題ではなく、定義設計の問題です。
04
更新タイミングが違う
HubSpotはリアルタイム更新、Salesforceは夜間バッチ同期——この組み合わせでは、ダッシュボード・KPI・売上予測が数時間から1日ズレます。現場ではこのズレの仕組みが共有されないまま、「数字がおかしい」という不信感だけが積み重なっていきます。
本当に必要なのは「Revenue Data Flow」の設計
SalesforceとHubSpotを両方使う企業に必要なのは、新しいツールではありません。必要なのは、Revenue Data Flow（収益データの流れ）の設計です。
Revenue Data Flowとは、どのデータがどこで発生し、どのシステムへ流れ、誰が更新し、何を正として扱うかを定義する考え方です。たとえば次のように整理します。
| データ | 正システム（Single Source of Truth） |
|---|---|
| リード情報 | HubSpot |
| 商談情報 | Salesforce |
| 契約・受注情報 | Salesforce |
| メール配信履歴 | HubSpot |
| 売上予測 | Salesforce |
| マーケ施策分析 | HubSpot + BI |
重要なのは、すべてを一つのツールに寄せることではありません。どのツールを、何の役割で使うかを明確にすることです。
「連携」だけでは解決しない
SalesforceとHubSpotを連携すれば解決する——そう考える企業は少なくありません。しかし実際には、項目定義・同期条件・ステージ定義・更新ルール・KPI定義が整理されていなければ、連携してもカオスが高速化するだけです。
連携の前に設計が必要です。システムをつなぐことは手段であり、「何を正とするか」「誰がどの定義で更新するか」を決めることが目的です。設計のない連携は、問題を隠すのではなく、増幅させます。
Revenue Architectureという考え方
ここで必要になるのが、Revenue Architecture（レベニューアーキテクチャ）です。Revenue Architectureとは、営業・マーケティング・カスタマーサクセス・CRM・KPI・データを、売上につながる一つの流れとして設計する考え方です。
SalesforceとHubSpotの問題も、実際にはツール問題ではありません。誰が、どの定義で、どのタイミングで、何を更新し、どのKPIを見るか——という「収益構造」の問題です。
海外のRevOps事例でSalesforce・HubSpot・BI・CDPを高度に連携している企業が多くありますが、日本企業では同じ構成を入れてもうまく定着しないケースが少なくありません。営業文化・Excel運用・稟議構造・会議運営が異なるためです。重要なのは、海外ツールを入れることではなく、自社で機能する構造へ翻訳することです。
Revenue Architectureを整えると、何が変わるのか
01
数字ズレが減る
営業・マーケティング・CS・経営が同じ定義・同じデータソースを見るようになります。「どちらが正しいか」という確認が不要になり、会議の時間を改善議論に使えるようになります。
02
CRMが信頼される
「CRMの数字は信用できない」という声がなくなります。これは、ツールが変わるのではなく、数字を作る構造が変わるために起きることです。
03
施策と売上がつながる
どの施策が商談・受注・ARR・継続収益へつながったかを、一気通貫で見られるようになります。マーケティングの投資対効果が明確になり、予算配分の判断精度が上がります。
04
売上が予測できるようになる
パイプラインの精度が上がり、来月・来四半期の売上見込みを経営判断に使えるようになります。これは、CRMの使い方ではなく、設計の精度に依存する変化です。
Consilegyの考え方
Consilegyでは、Salesforce導入・HubSpot導入を単独のツール導入として捉えていません。重要なのは、データ構造・KPI定義・Revenue Data Flow・営業プロセス・マーケティング連携・RevOps運用を、一つの収益構造として設計することです。
Salesforce・HubSpot・Kintone・BI・Slackなどを横断しながら、Revenue Architectureとして再設計します。目的は、ツールを増やすことではなく、売上が見える構造を作ることです。
| 支援領域 | 内容 |
|---|---|
| Architecture | Revenue Data Flow設計・CRM / SFA構造再設計 |
| Process | 商談ステージ・KPI・ハンドオフ条件の定義 |
| Operations | 会議体設計・RevOps体制構築・定着支援 |
| Technology | HubSpot / Salesforce等の実装・改善 |
まとめ：数字ズレは、構造問題
SalesforceとHubSpotで数字がズレる原因は、ツール性能ではありません。多くの場合、KPI定義・データ構造・同期ルール・Revenue Data Flow・Revenue Architectureが設計されていないことが原因です。
「連携ツールを追加する」前に、「どのデータを、誰が、どの定義で扱うのか」を整理する必要があります。数字ズレをなくすには、まず構造から見直す必要があります。
Consilegyは、CRM導入ではなく、Revenue Architectureの観点から、営業・マーケティング・データ構造を横断して再設計します。SalesforceとHubSpotのどちらを使うかではなく、両者をどう機能させるかを、収益構造から設計します。