%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png?width=130&height=39&name=%E6%9C%80%E7%B5%82Start%20Link%20(500%20x%20150%20px)%20(%E8%83%8C%E6%99%AF%E3%81%82%E3%82%8A).png "StartLink"){kind=logo}
この記事の結論
CRMのデータを経営判断につなげる方法。数字を並べるだけでなく、次の行動まで決まる仕組みを整えます。
CRMのデータを経営判断につなげる方法。数字を並べるだけでなく、次の行動まで決まる仕組みを整えます。
「売上データはあるのに、次に何を変えるべきか決まらない」「営業とマーケティングで集計の基準が違う」「会議のたびにExcelを集め直している」——こうした状態では、データが蓄積されても意思決定にはつながりにくくなります。
データドリブン経営とは、CRMなどに蓄積した定量データを判断材料として、事業の方針や次の行動を決める経営手法です。CRMを顧客との接点や商談の共通基盤にすると、部門ごとに分かれた情報を関連付けて確認できます。ただし、数値を一画面に集めるだけでは判断できません。集計の定義を揃え、変化の理由を調べ、誰が何をするかまで決める必要があります。
本記事は「セールスDX推進ガイド｜CRMで営業プロセスをデジタル変革する5つのステップ」シリーズの一部です。
本記事はStartLinkの「HubSpot完全ガイド」関連記事です。
この記事でわかること
経営指標を確認する場面で、CRMをどう使えば判断と現場の行動がつながるのかを知りたい方に向けて、設計から運用までを説明します。指標を選ぶ前の問いの立て方、比較できるデータかを見極める方法、比較できないときに戻るべき作業も取り上げます。
- データドリブン経営の考え方 — 数値の変化を見つけ、記録の状態と事業上の背景を確かめてから行動を決める流れを整理します。
- CRMを共通の情報基盤にする方法 — 顧客、取引、対応履歴の関連付けと、別システムの数字との照合方法を解説します。
- 経営指標とパイプラインの設計 — 指標の分母・分子、ステージの移行条件、受注見通しを自社の営業プロセスに沿って定義します。
- HubSpotでのダッシュボード作成と運用 — レポートの選定、共有、会議での確認から次の行動の記録までを順に説明します。
- 導入時の限界と段階的な進め方 — 入力が揃わないときの扱い方と、分析対象を広げる条件を取り上げます。
最初に経営会議で答えたい問いを一つ決めて読み進めると、自社で必要な項目とレポートを選びやすくなります。例えば「受注見通しが変わった理由を知りたい」なら、金額の合計だけでなく、対象となる取引、ステージ、クローズ予定の更新履歴まで確認できるかを考えます。
データを意思決定と次の行動につなげる
データドリブン経営は、数字を集めて眺める取り組みではありません。データを共通の事実として捉え、背景を読み取り、次の行動を決め、その結果をまた確認する流れです。
人の経験も判断に使いますが、経験から出た見立てと記録で確認できた事実を分けて話すと、後から判断を振り返れます。
顧客獲得の変化を議論するなら、次の順で進めます。
- 定義を揃える ── まず「獲得」の定義と集計期間を揃えます
- 記録を確かめる ── 次に、チャネル別の記録漏れや重複がないかを確かめます
- 施策の比較へ進む ── その上で、商談化や受注まで同じ対象を追えるなら施策の比較へ進みます。追えない場合は、施策の優劣を決める前に記録方法を整えます
- 獲得数が増えても商談化が変わらない場合 ── 獲得した顧客の内訳を確認します
- 獲得数が変わらず商談化だけが変わった場合 ── 引き渡しや対応の記録を確認します
次の表は、各データカテゴリで確認できる内容を整理したものです。指標を採用する際は、名称だけでなく、記録元と更新する担当者も決めます。
| データカテゴリ | 具体的な内容 |
|---|---|
| マーケティングデータ | リード獲得チャネル、コンテンツのエンゲージメント、キャンペーンのROI |
| 営業データ | パイプラインの金額・ステージ、商談の進捗、受注/失注の理由 |
| カスタマーサクセスデータ | チケットの発生状況、CSAT/NPS、チャーン率 |
| 活動データ | メール、電話、ミーティングなど各担当者の活動履歴 |
| 収益データ | MRR/ARR、LTV、顧客別の収益推移 |
カテゴリをまたいで比較するときは、同じ顧客や取引をたどれるか確認します。つながらない情報は部門ごとの状況把握には使えても、獲得から収益までを一続きの成果として評価する材料にはできません。
Excelでの集計が判断を遅らせる理由
- 取りまとめ作業 ── 営業がExcelで取引状況を管理し、マーケティングが別のスプレッドシートでリードを集計していると、会議前に情報を取りまとめる作業が発生します
- 照合作業 ── 担当者名やステージ名の表記が異なれば、照合作業も必要です
- 基準の不在 ── 集計に時間をかけても、数字の定義が揃っていなければ、どの数字を基準に話すかが決まりません
まず、次の順で整理します。
- 記録元を書き出す ── 会議で使う指標について、どのファイルやシステムが記録元かを書き出します
- 更新する場所を決める ── 同じ取引が複数箇所にあるなら、更新する場所を決め、他の場所ではどう参照するかを整理します
- CRMに登録する ── CRMに顧客や取引を登録し、共通の項目と更新ルールを決めると、集計元を揃えやすくなります
手入力をすべてなくすという話ではなく、何をどこに記録するのかを決め、転記や確認に費やしていた作業を減らすことが出発点です。
| 状態 | 起きやすいこと | 見直すこと |
|---|---|---|
| 部門ごとに別ファイルで管理 | 同じ顧客の情報が複数箇所に分かれる | 顧客と取引の主な記録先を決める |
| 会議前に手作業で集計 | 集計条件や更新時点が揃わない | 指標の定義と対象期間を共通化する |
| 担当者の記憶で進捗を判断 | 担当変更時に経緯を追いにくい | 接点と商談の履歴をレコードに記録する |
表の「見直すこと」を決めたら、実際の取引をたどり、別の担当者でも同じ集計結果にたどり着けるか確認します。
- 結果が異なるなら ── レポートを増やす前に項目の意味か更新手順を修正します
- 照合できるようになった指標 ── 会議で使い、対象を広げる際には同じ確認を繰り返します
判断の流れを組織で共有する
ダッシュボード上で数値が動いても、誰が何を確認するかが決まっていなければ、対応は担当者任せになりがちです。指標ごとに、確認する役割、変化があったときに調べる要因、次に取る行動を結び付けます。
例えば、商談化が減った場合は、次の順で確かめます。
- 比較の前提を確かめる ── 最初に同じ期間・同じ対象で比較しているかを確かめます
- 段階を順に確認する ── 次に、リードの獲得数、営業への引き渡し状況、取引ステージの停滞を順番に確認します
- 獲得数に変化があり、後続の転換には大きな違いが見られない場合 ── 獲得経路の内訳を調べます
- 引き渡し後に止まっている場合 ── 担当者への割り当てや初回対応の記録を確認します
原因を一つに決めつけず、調べた結果に応じて対応する場所を選びます。
会議では、次の四つを残します。
- 見えた変化
- まだ分からないこと
- 確認する担当
- 次回に確認する記録
判断の根拠と実行状況を同じ取引やレポートから追える状態になったら、施策の比較へ進めます。
次回の会議では、決めた行動が実行されたかを先に確かめ、その後に指標の変化を見ます。
個人の記憶に頼らず、仕組みで引き継ぐ
取引を次のステージへ進める際に必要な情報を定義し、入力欄や更新ルールに反映すると、担当者が変わっても確認すべき情報を追いやすくなります。
項目を増やしすぎると入力が負担になるため、営業プロセスと経営レポートの両方で使う項目を優先します。
- 担当変更後の人が取引から読み取れない場合 ── 「顧客は何を確認済みか」「次に誰が何をするか」を読み取れないなら、その情報を残す方法を先に整えます
- 入力されていても使われていない項目 ── 誰も引き継ぎや判断に使っていないなら、必須にする理由を見直します
入力者を責めるのではなく、何をいつ記録すれば次の人が動けるかを設計することがポイントです。
CRMを経営の共通情報基盤として設計する
CRMは顧客との接点や商談情報を整理する基盤です。HubSpotでは次のレコードを関連付け、部門をまたぐ活動履歴を確認できます。
- コンタクト
- 会社
- 取引
- チケット
ただし、CRMを導入しただけで全社の情報が自動的に一つになるわけではありません。何をCRMで管理し、どの情報は別システムに残すかを決めます。
設計の順序は、経営上の問いを決め、答えるのに必要なレコードを特定し、関連付けと更新担当を確認することです。問いに必要のない情報まで集めると、入力と照合の負担が増えます。
顧客接点をコンタクトから取引までつなぐ
- コンタクト ── 個人とのやり取りを記録します
- 会社 ── 企業単位の情報を記録します
- 取引 ── 商談の進捗や金額を記録します
- チケット ── 使う場合は、顧客からの問い合わせや対応状況も関連付けられます
レコードを関連付けると、個別の接点だけでなく、顧客との関係や商談の流れをまとめて追えるようになります。
関連付けを確認するときは、受注した取引から会社、関係するコンタクト、記録された接点へとたどります。
- 途中でつながりが切れる場合 ── その指標を経路別の成果判断に使う前に、どの時点で関連付けるかを決めます
- 関連付けが済んだ後 ── 複数のコンタクトや取引を持つ会社をどう数えるかを決めてから集計します
次の表は、顧客との関係を確認する際に使われる指標の意味を整理したものです。算出や比較に使う場合は、それぞれ対象と期間を別途定義します。
| 指標 | 定義 |
|---|---|
| チャーン率（解約率） | 一定期間内に解約した顧客の割合 |
| NPS（Net Promoter Score） | 顧客の推奨度 |
| LTV（顧客生涯価値） | 顧客が生涯にわたってもたらす収益の総額 |
| LTV/CAC比率 | 顧客生涯価値を獲得コストと比較し、投資効率を判断する指標 |
| CSAT（顧客満足度） | 個別のインタラクションに対する満足度 |
| MRR（月間経常収益） | 毎月の継続収益。HubSpotの取引では継続課金の品目から算出される。出典 |
| ARR（年間経常収益） | 年間の継続収益。HubSpotの取引では継続課金の品目と契約期間から算出される。出典 |
| 新規売上 | 新規顧客から得た売上。出典 |
| 既存売上（拡大） | 既存顧客のアップセルやクロスセルによる追加収益。出典 |
| 加重パイプライン | 各取引の金額に受注確度を掛けた値の合計。出典 |
| パイプライン速度 | 商談数×受注率×平均取引金額÷平均取引サイクルで表す、期間当たりの売上見込み。出典 |
| ステージ別転換率 | 取引がパイプラインの各ステージへ進む割合。出典 |
| 平均取引サイクル | 取引がクローズするまでに要した平均日数。出典 |
| MQL数 | マーケティング部門が営業部門に引き渡せると認定したリードの数。出典 |
| MQL→SQL転換率 | MQLのうち、営業部門が見込み顧客と認定したSQLに転換した割合。出典 |
| チャネル別ROI | マーケティングチャネルごとの投資に対する収益性を比較する指標。出典 |
| 拡大MRR | 既存契約の変更により増えた月間経常収益。出典 |
| リード獲得数 | 新規に獲得した、購買見込みのあるリードの数。出典 |
これらを同時に追う必要はありません。
- 受注見通しを確認する会議 ── 最初に取引の金額と進捗を照合します
- 継続状況を議論する会議 ── 契約や解約をどの記録で確認するかを決めます
指標の定義は、採用した問いに合わせて具体化します。
次の表を使い、顧客のどの段階で判断が止まっているかを確認します。同じ獲得段階でも、接点履歴まで確認する問いには、コンタクトの登録だけでは足りません。
| 顧客の流れ | CRMで扱う情報の例 | 判断につながる問い |
|---|---|---|
| 見込み顧客の獲得 | コンタクト、獲得経路、コンテンツへの反応の記録、接点履歴 | どの経路から接点が生まれているか |
| 商談化と提案 | 会社、取引、ステージ、金額、活動 | どこで商談が停滞しているか |
| 受注と顧客化 | 取引の結果、受注理由、顧客との関連 | どの条件の商談が受注につながったか |
| 顧客対応と継続 | チケット、対応履歴、追加取引 | 継続や追加提案に向けて何を確認するか |
| 請求と収益の確認 | 会計システムの情報との照合 | 取引の売上情報と会計上の実績に差があるか |
問いに答えるための記録が途中で欠けるなら、欠けた段階を特定します。例えば受注理由が未入力なら、獲得経路別の受注理由を比較する前に、受注時に記録する担当と方法を決めます。
CRMに任せる領域と別システムの領域
CRMは顧客・商談・活動の記録に適しています。
一方、次のような情報は、それぞれを管理するシステムが情報の正本になる場合があります。
- 財務諸表や入出金
- 人事情報
- プロダクトの利用ログ
CRMで管理しない情報を無理に複製すると、更新タイミングの違いから数値が食い違うことがあります。
連携を検討するときは、各システムで管理する項目、更新元、更新頻度、照合する担当を整理します。
- 問いが答えられるか確かめる ── まず、経営会議で必要な問いがCRM内の情報だけで答えられるか確かめます
- 不足する項目を特定する ── 答えられない場合は、不足する項目とその正本を特定します
- 連携方法と照合ルールを設計する ── 顧客や取引の判断に必要な範囲が決まってから、連携方法と照合ルールを設計します
照合できない差が残る場合は、その指標を会議でどう扱うかを決め、差を説明できるまで用途を限定します。
「唯一の正しい数字」ではなく、定義を揃える
Single Source of Truthという考え方は、参照先を一つにするだけでなく、数値の定義と更新ルールを共有することが重要です。例えば「受注金額」に何を含めるか、対象期間をどの日時で区切るかが異なると、同じレポートを見ても解釈がずれます。
指標ごとに、対象レコード、対象期間、計算方法、除外条件を記録します。
CRMにある数字と会計上の数字が異なる場合は、まず取引単位で対象と計上時点を照らし合わせます。
- 定義や更新時点で説明できる差 ── 両方の用途を明記します
- 説明できない差が残る場合 ── 経営判断に使う前に記録元を確認します
経営KPIとパイプラインの定義を揃える
- 項目を決める ── 経営層が見る指標は、現場が更新するデータと結び付け、顧客獲得から商談、受注、顧客対応までの各段階で確認する項目を決めます
- 期間と担当をそろえる ── 各指標の集計期間と更新担当をそろえ、どの段階で変化が起きたかを確認できるようにします
判断基準を設定する前に、比較対象の取引について対象期間、取引の範囲、記録方法が揃っているか確認します。
- 条件が揃っている場合 ── 自社の実績と営業プロセスを基に基準値を検討します
- 記録が欠けている場合 ── 比較結果を判断に使わず、対象と入力方法を揃えることを優先します
- 条件を揃えられない取引 ── 同じ基準で評価する対象から外します
基準値を決める際は、まず何を変えたいのかを明確にします。
- 商談の進捗を管理したい場合 ── ステージごとの移行状況を見ます
- 売上の見通しを検討したい場合 ── クローズ予定と受注・失注の結果を照合します
過去と現在で対象となる取引やステージの意味が違う場合は、全体を一つの基準で比べず、比較可能な取引に絞るか、定義を揃えた後の記録から見直します。
採用した基準は固定せず、取引の構成や営業プロセスが変わったときに再確認します。
経営指標を顧客の流れに沿って整理する
指標は、結果を示す指標と、その結果に至る過程を示す指標に分けて考えると、次の確認事項が見つけやすくなります。
例えば受注金額だけでなく、次も合わせて確認します。
- リードの獲得
- 商談への転換
- 取引ステージの進捗
転換率を比較する場合は、次の順で進めます。
- 分母となる対象を決める ── 期間中に新しく入った取引を見るのか、期間中にステージを通過した取引を見るのかで、問いが変わります
- 取引の扱いを統一する ── 除外する取引、ステージを戻した取引、未更新の取引の扱いを統一します
- 同じ定義で集計する ── 同じ定義で集計できてから、期間や担当者間の違いを読み取ります
差が見えた場合は、件数の内訳と個別の取引を確認し、少数の取引や記録時点の違いだけで説明できないかを確かめます。
次の表では、経験を中心に判断する場合と、データを共通の判断材料にする場合の考え方を整理しています。
表中の「即時判断」「再現性」「拡張可能」は、記録と定義が揃い、確認する人と判断手順が決まっている場合に目指せる状態を示します。データが揃っていても、判断にかかる時間が短くなるとは限らず、因果関係を証明できるわけでもありません。判断する際は、記録と現場の背景を確認します。
| 項目 | 従来型（経験・勘ベース） | データドリブン経営 |
|---|---|---|
| 意思決定の根拠 | 経営者・管理者の経験や直感 | CRM等に蓄積されたデータ |
| 判断のスピード | 会議での合意形成に時間がかかる | リアルタイムデータで即時判断 |
| 再現性 | 属人的（判断者が変わると結果が変わる） | プロセス化・標準化が可能 |
| 振り返り | 結果の因果関係が曖昧 | 結果と施策を照らし合わせ、要因を検討 |
| スケーラビリティ | 組織拡大に伴い限界が来る | 仕組みで拡張可能 |
次の表では、領域ごとに指標の例と確認する問いを対応させています。会議で答えたい問いを決めてから、必要な指標を選びます。
比較する際は、対象期間、集計対象、計算方法を確認してください。これらの条件がそろわない場合、指標の差だけで状況を判断することはできません。
| 領域 | 指標の例 | 指標から確認すること |
|---|---|---|
| 売上・収益 | 受注金額、月別売上、既存顧客からの追加取引 | 売上の構成や推移に変化があるか |
| パイプライン | 進行中の取引金額、ステージ別件数、クローズ予定 | 将来の売上候補がどの段階にあるか |
| マーケティング | リード獲得数、MQL数、MQLからSQLへの転換 | 獲得した接点が営業の対象につながっているか |
| 営業活動 | 商談の進捗、ステージ間の転換、受注と失注の理由 | どの段階で停滞や離脱が起きているか |
| 顧客対応 | チケットの発生状況、対応履歴、顧客別の取引推移 | 顧客の課題が継続や追加提案に影響しているか |
| 新規売上 | 新規顧客からの売上 | コンタクトのライフサイクルが「顧客」になった取引の金額 |
| 粗利率 | 売上に対する粗利の割合 | カスタムプロパティで原価を入力し、計算フィールドで算出 |
| パイプライン速度 | 商談の進行にかかる日数 | 短いほど良い |
| LTV（顧客生涯価値） | 顧客が生涯にもたらす収益 | 収益の見通しを顧客との関係期間に沿って把握する |
| LTV/CAC比率 | LTVをCACで割った比率 | 顧客生涯価値と顧客獲得コストの比率を確認する |
- 月別集計の扱い ── 取引のクローズ金額を月別に集計した値を、会計上の月別売上や継続収益と同じものとして扱う前には、対象と計上方法を照合します
- パイプライン速度の見方 ── 表中のパイプライン速度や「短いほど良い」という見方だけで商談を評価せず、受注・失注の結果や顧客側の検討過程と合わせて確認します
進行日数が長くなった取引でも、顧客の判断待ちなのか、社内の対応が止まっているのかで次の行動は異なります。
パイプラインの4要素を設計する
パイプラインは、取引の進捗を並べるだけの表ではありません。商談状況を同じ基準で解釈し、受注見通しと次の行動を考えるための枠組みです。
営業プロセスを理解するマネージャーや担当者と、実際の受注・失注状況を確認しながら設計します。
| 要素 | 設計する内容 | 判断に使う場面 |
|---|---|---|
| 取引ステージ | 受注までの進行段階 | 商談がどこまで進んでいるかを見る |
| 受注確度 | ステージに応じた見込みの考え方 | 取引金額だけでなく確度も踏まえて見通す |
| ステージ定義 | 各段階へ進んだと判断する条件 | 担当者ごとの解釈の差を抑える |
| 必須入力プロパティ | ステージ移行時に記録する情報 | 次の担当者やレポートに必要な情報を残す |
ステージは、社内の営業プロセスに即して設定します。
- 実際の行動や確認事項に対応させる ── 例えば提案を提示しただけなのか、顧客側で導入判断に進んでいるのかを区別します
- ステージ名だけで判断できない場合 ── 定義文と移行条件も合わせて共有します
定義を試す際は、担当者が異なる取引を取り上げ、同じ記録を見て同じステージと判断できるか確認します。
- 判断が分かれたら ── 顧客側で確認された事実や次の合意事項を移行条件に加えます
- 条件が揃った取引 ── 次へ進めます
- 揃っていない取引 ── 必要な確認を次の行動として残します
ステージを変えた後は、変更前後の取引をそのまま同じ集計に混ぜず、比較に使える範囲を確認します。
受注確度と必須情報をレポートにつなげる
- 確度の定義 ── 受注確度を使う場合は、ステージごとの確度を定義し、過去の成約実績と照らして見直します
- 見通しの確認 ── 案件ごとの金額に確度を掛けて合計した加重パイプラインを取引総額と並べ、見通しの差を確認します
- 差が目立つ場合 ── 金額の大きい案件からステージ判定の根拠と進捗を確認し、確度の設定を見直します
ただし、成約実績が少ないステージや案件ごとの差が大きい場合は、設定した確度だけを予測の根拠にせず、案件ごとの状況も確認します。
比較の際は、次の順で進めます。
- 取引を集める ── まず同じステージ定義で記録された取引を集めます
- 見込みと結果を照らし合わせる ── 受注と失注が記録された取引で、各ステージにいた時点の見込みと実際の結果を照らし合わせます
- 原因を順に調べる ── 見込みより受注が少ない傾向が続くなら、ステージ移行条件、クローズ予定の更新状況、取引金額の変更を順に調べます
金額の大きさや案件の種類によって結果が大きく異なるなら、ひとつの確度で全取引を説明しようとせず、取引の内訳と個別の進捗を併記します。
結果がまだ確定していない取引を失注と同じように数えると、見込みの評価が変わります。
- 結果の確定 ── 比較する取引の結果が確定しているか、確認中の取引をどう扱うかも揃えます
- 記録が不足して傾向を判断できない場合 ── 確度を細かく調整する前に、ステージに進んだ根拠と結果を残す運用を整えます
- 定義や営業プロセスを変えた後 ── 以前の実績をそのまま当てはめず、条件が揃っているか見直します
必須情報は、取引を進める上で必要な項目に絞ります。
- 提案段階 ── 金額やクローズ予定を確認します
- 受注・失注時 ── 結果の理由を記録できる設計にします
入力負担とレポート上の必要性を照らし合わせ、使われていない項目は見直します。レポートの値と個別の取引記録が一致してから、見通しの判断に使います。
加重パイプラインは、各取引の金額に受注確度を掛けた値を合計したものです。これは条件を置いて算出した見通しであり、受注が確定した金額ではありません。
会議では合計値とともに、見通しを左右する取引、確認が必要な事項、次に更新する担当を示します。
失注を次の改善につなげる
失注理由を自由記述だけで記録すると、後から傾向をまとめにくくなります。
次のような自社で分析したい分類を定義し、必要なら補足を記述できるようにします。
- 価格
- 競合
- 機能
- 時期
- 社内判断
分類が細かすぎると入力が揃わないため、実際の振り返りで使う粒度から始めます。
次の表は、営業の結果と顧客の継続状況を確認するレポートの例です。成約率や解約率は、分母に含める対象と期間を決めてから比較します。
| レポート | タイプ | 内容 |
|---|---|---|
| 成約率の推移 | 折れ線グラフ | 月別の成約率（受注数 ÷ 商談数） |
| 平均取引単価 | 数値 | 案件ごとの取引金額の傾向を把握する目安 |
| チャーン率 | 数値 | 当月の顧客解約率 |
失注理由は、営業だけで抱える情報ではありません。特定の理由が繰り返される場合は、まず記述内容と取引の経緯を確認し、同じ意味で分類されているかを確かめます。
- 説明内容に課題がある場合 ── マーケティング資料や提案方法を見直します
- 顧客の検討時期が理由の場合 ── 再連絡の条件と担当を決めます
- 再アプローチが適切な顧客 ── 失注後に検討状況を確認し、ナーチャリングへ戻す流れを設計します
変更後は、対象となった取引の記録をたどり、理由の分類と次の対応が実際に残っているかを確認します。
HubSpotで経営ダッシュボードを作成する
ダッシュボードは複数のレポートを同じ場所で確認するための画面です。
- 経営向けの構成 ── 事業全体の状態を確認してから、変化の要因を部門や取引単位で掘り下げられる構成にします
- 始め方 ── 最初に作り込まず、会議で判断に使う指標から小さく始めます
次の表は、経営会議で全体像を確認するレポートの例です。目標、実績、見通しはそれぞれ意味が異なるため、同じ期間と対象で表示していても混同せずに読みます。
| レポート | タイプ | 内容 |
|---|---|---|
| 月間売上（目標vs実績） | 数値 + 棒グラフ | 当月の売上目標と実績の比較 |
| パイプライン総額 | 数値 | 進行中の全取引の合計金額 |
| フォーキャスト | 数値 | AI予測または手動フォーキャストの着地予測 |
次の表は、全体の変化がどの段階で起きたかを調べるレポートの例です。ファネルでは、各段階の対象と通過条件を揃えてから転換を比較します。
| レポート | タイプ | 内容 |
|---|---|---|
| リード→MQL→SQL→受注ファネル | ファネルチャート | 各ステージの転換率を可視化 |
| パイプラインステージ別金額 | 横棒グラフ | 各ステージに滞留している金額の分布 |
| 新規商談の推移 | 折れ線グラフ | 週別・月別の新規商談数の推移 |
ダッシュボードに載せる指標を選ぶ
まず、会議で確認したい問いを定めます。売上の状況を把握したいのか、商談の進捗を確認したいのか、マーケティングから受注までの流れを見たいのかで、必要なレポートは変わります。
| 表示する層 | レポートの例 | 数値を見た後の確認 |
|---|---|---|
| 事業全体 | 売上目標と実績、進行中取引の金額 | 実績と見込みのどこに差があるか |
| ファネル | リードから商談、受注までの件数 | どの段階で転換が弱まっているか |
| 営業プロセス | ステージ別の取引件数や金額 | どの段階に取引が滞留しているか |
| 顧客対応 | チケットや顧客別の対応状況 | 商談や継続に関係する課題があるか |
指標の数を固定するより、「数値が変化したら誰が何を決めるか」を説明できるものに絞ります。
例えばパイプライン総額が変わったときに、次を区別して調べられるなら、会議の判断に使えます。
- 新規取引
- 金額変更
- ステージ移行
- クローズ予定の変更
内訳を追えないなら、表示を増やす前に取引の更新方法を確認します。状況を掘り下げるためのレポートは、部門別や担当者向けの画面に分けます。
レポートとダッシュボードを作成する
HubSpotの画面構成は契約内容や権限で異なる場合があります。基本的な流れは、ダッシュボードを用意し、使うレポートを追加し、対象期間や担当者などの条件を揃えることです。
- レポートと指標の定義を決める ── 対象にするオブジェクト、期間、集計方法、除外条件を決めます
- 数字の定義が曖昧なままなら、先に指標の説明を揃えます
- 代表的な取引を取り上げ、集計に含まれるかを確認します
- ダッシュボードを作成する ── HubSpotの「レポート」から「ダッシュボード」を開き、新しいダッシュボードを作成します
- 目的が分かる名前を付けます
- 閲覧・編集できる利用者を設定します
- レポートを用意して追加する ── 標準レポートで足りるか確認し、必要な場合はカスタムレポートを作成します
- ダッシュボードに追加した後、レポートの期間やパイプライン、担当者などのフィルターを揃えます
- 表示された集計値を元の取引記録と照合し、差があれば条件を確認します
- 配置を整えて共有する ── 経営判断に直結するレポートを先に確認できる位置に置き、関連する指標を近くに配置します
- 閲覧者が必要なデータを見られる権限を持つか確認し、会議の利用者と共有します
- 会議で問いに答えられたら使い続け、答えられなかった問いは次回の見直し対象にします
作成前に問いと対象を決め、作成後に元の取引と表示値を照合するところまでを一つの作業として進めます。
レポートの画面で実績を確認する
以下の画面は、月次実績とチーム目標比のレポート例です。この節では、表示された差を取引の変化までたどり、会議で確認する内容を決める順序を説明します。
レポートを見た後は、数値の変化だけで結論を出さず、対象期間やステージ定義、更新状況を確認します。
- 取引の増減や更新時点を調べる ── 前月との比較で差が見えたら、まず対象となる取引の増減や更新時点を調べます
- ファネルや取引ステージで確認する ── 記録上の差で説明できなければ、関連するファネルや取引ステージに移り、どの段階の変化が全体に関係しているかを確認します
- 仮説として残す ── 調べても理由が分からない場合は、仮説として残し、次に確認する取引や担当を決めます
公式仕様と自社の利用条件を照らし合わせる
HubSpotの標準ダッシュボード機能とカスタムレポートでは、利用条件が同じとは限りません。（出典：カスタムレポートを作成する）。
- 標準レポートで経営上の問いに答えられる場合 ── それを先に使います
- 標準レポートで不足する分析が明確になった場合 ── 複数のオブジェクトを組み合わせるなど、不足する分析が明確になった時点で、カスタムレポートの利用条件を確認します
- 必要なレコードが関連付いていない場合 ── レポートの種類を変える前にデータのつながりを整えます
必要な情報が揃い、利用条件も確認できたら、問いに合うレポートを選び直します。
部門をまたぐデータを改善サイクルに活用する
営業、マーケティング、顧客対応の情報をつなぐと、リード獲得から受注、その後の顧客対応までを見通しやすくなります。
- 前の段階の結果が次の段階にどうつながるか ── 個別の部門指標をまとめるだけでなく、これを追うことが重要です
- CRMの情報だけで不足する場合 ── 必要な項目と記録元を確認し、外部システムとの連携範囲を定めます
獲得から受注までを一気通貫で見る
リード獲得数だけでは、獲得後に営業対応や受注につながったかは分かりません。
コンタクト、会社、取引を関連付け、獲得経路や活動履歴と商談結果を結び付けると、どの接点が商談化や受注に関係しているかを検討できます。
- 取引までたどれるか確認する ── 獲得経路が記録されているコンタクトから取引までたどれるか確認します。関連付いていない取引があるなら、その取引を分析対象に含める方法を決めます
- 経路別の商談化を比較する ── 同じ期間・同じ顧客群で経路別の商談化を比較します。記録の揃い方が経路によって異なるなら、成果の差と断定せず、記録方法を揃えてから再確認します
接点が記録されていることと、特定の施策が受注の原因だと証明できることは同じではありません。
- 期間、対象顧客、接点の記録方法を揃える ── レポートの結果を施策の振り返りに使います
- 比較できる状態になったら ── 変化が見られた経路の取引を確認し、営業への引き渡しやその後の対応に違いがないかも調べます
失注・問い合わせ・顧客対応を部門で共有する
- 営業の失注理由 ── 提案内容やマーケティング資料を改善する手がかりになります
- 顧客からの問い合わせやチケット ── 営業が追加提案を考える際の背景情報になる場合があります
どの情報をどの部門が確認し、どの条件なら通知や引き継ぎを行うかを決めておくと、情報の受け渡しを人の記憶だけに頼らずに済みます。
HubSpotのワークフローを使う場合も、通知条件を業務の判断に沿って設計します。例えば次の順で進めます。
- 条件と通知先を定義する ── 特定のチケット分類が営業への共有対象なら、その条件と通知先を定義し、通知後に誰が対応するかまで決めます
- 届き方を確認する ── 通知を追加した後は、対象の記録が意図した担当に届き、対応結果が残るかを確認します
- 引き継ぎ条件を見直す ── 届いても対応が決まらないなら、通知を増やす前に引き継ぎ条件を見直します
データを見て原因を調べ、施策を検証する
経営会議では、数字を報告して終わらせず、観察、状況の整理、意思決定、実行、結果の確認をつなげます。
例えばパイプラインが縮小した場合は、同じ集計条件で変化を確認した後、次の順に見ます。
- リード獲得
- 商談化
- ステージ移行
どの段階で変化が見られたかによって、確認する担当と記録を変えます。
| 段階 | 確認すること | 次へ進む条件 |
|---|---|---|
| 観察 | どの指標がいつから変化したか | 対象期間と定義が揃っている |
| 状況整理 | 変化に関係する部門やステージはどこか | 複数の関連レポートで差を確認できた |
| 判断 | どの課題に対して何を変えるか | 担当と実施内容が決まっている |
| 実行 | 決めた施策が運用されたか | CRM上の記録や活動で実施状況を追える |
| 振り返り | 指標や現場の状況に変化があったか | 次の継続・修正・終了を判断できる |
施策を実行した後は、実施した対象と実施していない対象、または実施前後を比べる際の条件を記録します。
- 対象の構成や記録方法も変わっている場合 ── 指標の差だけを施策の効果とは扱いません
- 比較できる条件が揃わない場合 ── 個別の取引と現場の反応を確認し、継続するか、方法を変えるかを決めます
次の確認時に何が分かれば判断を変えるのかも、会議の記録に残します。
データ品質と導入範囲を段階的に整える
信頼できるダッシュボードは、使われるデータと指標の定義に支えられています。
- 最初から全社の情報を一度に集約しようとする場合 ── 必要項目や運用ルールが複雑になりがちです
- 対象を絞る場合 ── 入力状況や会議での使われ方を確認しながら広げます
入力項目と更新ルールを必要最小限にする
データ品質を保つには、全員に多くの項目を入力してもらうのではなく、判断や引き継ぎに使う情報を優先します。次の三点を決め、CRMのプロパティや運用ルールに反映します。
- ステージ移行に必要な項目
- 入力するタイミング
- 選択肢の意味
定期的に、次の4点を確認します。
- 未更新の取引
- 重複レコード
- 選択肢の揺れ
- レポートで使われていない項目
入力率を見る際は、対象に含めるレコードと必須項目を明確にします。値が空欄の取引については、次を分けて扱います。
- 入力忘れ
- その段階では確認できない情報
そうすると、数字の変化が入力ルールの変更によるものか、実際の事業変化によるものかを区別しやすくなります。
未入力が多い項目は、担当者への入力依頼だけで終えず、いつ情報を得られるか、その項目を必須にする必要があるかを見直します。
- 必要な項目が無理なく更新され、取引記録とレポートを照合できたら ── 分析に使う範囲を広げます
- 新しい指標を追加する際も ── その指標に必要な項目について同じ確認を行います
データに基づく判断が難しいケースを見極める
CRMだけでは、財務、人事、プロダクトなどの全情報を管理できないことがあります。
- 必要なデータがCRMの外にある場合 ── 部門横断の分析に必要なデータがCRMの外にあるなら、まずそのシステムを正本として維持し、CRMと連携する項目や照合方法を決めます
- 入力が定着していない段階 ── 予測レポートの数値が実態を反映しないおそれがあります
入力が定着していない段階への対応は、次の順で行います。
- 集計の前提を揃える ── 受注実績や取引件数の集計期間と対象を揃え、未入力や重複を確認します
- 個別の取引記録と照合する ── レポートの値を個別の取引記録と照合します
- 差異の原因を直す ── 差異の原因が入力時点や定義にあるなら、ルールを直してから再集計します
記録の抜けや定義の揺れが続く間は、予測値だけで投資や人員配置を決めず、個別案件の状況と併せて判断します。
小さく始めて、使われた分だけ拡張する
導入は、次の順で進めます。
- 経営会議で確認する指標を決める
- 取引の記録を整える ── ステージと金額、クローズ予定、受注・失注の理由を整え、基本的なレポートで数値を確認します
- 対象を広げる ── 会議で「どの取引が変化に関係したか」を追え、次の確認や行動を決められる状態になったら、マーケティングや顧客対応の指標、外部システムとの連携へと対象を広げます
追加した指標が判断に使われなければ、表示場所を増やす前に問いと定義を見直します。
自社の営業プロセス、顧客との接点、会計やサポートの管理方法に合わせて、設計と拡張の優先順位を決めます。企業様によって最適な形は異なります。
よくある質問
データドリブン経営とは、データだけで経営判断することですか？
いいえ。データは判断の前提を揃えるための材料であり、最終的な判断は経営者や担当者が行います。数値の定義と記録状況を確認し、背景や制約を踏まえて行動を決めます。判断時の見立てと実行結果を残しておくと、次の会議で継続・修正を検討できます。
HubSpotだけで経営に必要なデータをすべて管理できますか？
すべての情報をCRMで管理する必要はありません。顧客、会社、取引、活動、チケットなどをHubSpotで扱い、会計や人事、プロダクトの情報は各システムの管理方法に合わせて連携範囲を決めます。まず答えたい問いを定め、CRMの記録だけで足りなければ、必要な情報の正本と照合方法を確認します。
経営ダッシュボードには何を載せればよいですか？
経営会議で確認したい問いから逆算し、売上、パイプライン、顧客獲得から受注までの転換など、判断と行動につながる指標を選びます。数値が変わったときに対象の取引へたどり、誰が何を確認するか説明できるものを優先します。確認方法が決まっていない指標は、定義を整えるか部門別レポートで扱います。
CRMのデータが不完全な場合はどう進めますか？
まず主要な取引ステージ、金額、クローズ予定など、使うレポートに必要な項目を絞って定義します。対象レコードの未入力や更新状況を確認し、入力忘れと未確定の情報を分けます。個別の取引と集計値を照合できるようになってから、レポートの対象範囲を段階的に広げます。
標準レポートとカスタムレポートはどう使い分けますか？
標準レポートで必要な問いに答えられるなら、まず標準レポートを使います。必要な対象や関連付けを確認しても表現できない問いが残った場合に、契約プランと権限を確認した上でカスタムレポートを検討します。作成後は、表示値を元の記録と照合してから会議で使います。
まとめ
- 基本方針 ── CRMを顧客や取引の共通基盤として整え、数値の定義を揃え、判断と行動をつなげます
- HubSpotでできること ── コンタクトから取引、受注後の顧客対応まで関連する情報をたどり、ダッシュボードやレポートを使って変化を確認できます
まずは経営会議で確認する取引指標から始め、次の手順で運用を整えてください。
- 受注金額やパイプラインなど、経営上の問いに答える指標を選び、対象レコード、期間、除外条件を決めます。記録が揃っていなければ、比較より先に更新方法を整えます。
- 取引ステージ、移行条件、必須入力項目を営業プロセスに沿って整理します。担当者が異なっても同じ記録から同じ進捗を判断できるか確認します。
- HubSpotで基本レポートを作成し、個別の取引と集計値を照合します。会議では変化の要因を調べ、担当と次の行動を記録し、次回に継続・修正を判断します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
このテーマと関連する内容を、次の記事でも詳しく解説しています。営業とマーケティングの引き渡し条件、ファネルごとのKPI設計、営業プロセスの見直し方を、それぞれの課題に合わせて確認できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
