%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ダッシュボードは、数値を並べる前に「誰が、何を決める画面か」を定めます。KPIの変化を次の行動につなぐ設計を、部門別の例と構築手順から解説します。
CRMダッシュボードは、数値を並べる前に「誰が、何を決める画面か」を定めます。KPIの変化を次の行動につなぐ設計を、部門別の例と構築手順から解説します。
「レポートは作ったけれど、数字を見ても何をすればよいかわからない」
「部門ごとにExcelで集計していて、会議のたびに数字が合わない」
「経営会議で、売上や商談の数え方から確認することになる」——
CRMダッシュボードとは、CRMに蓄積した顧客・営業活動のデータを、利用者の判断に合わせて整理して表示する画面です。使える画面にするには、KPIの定義と比較基準をそろえ、変化が見えたときに誰が何を確認するかまで決める必要があります。
たとえば売上が目標を下回った場合、画面上で差を見つけるだけでは対応を決められません。対象期間と計上条件を確認し、部門や担当者、取引ステージの内訳を見ます。差が特定の取引に集中していれば担当者と進行状況を確認し、広い範囲に及ぶなら集計条件や計画との関係を調べます。この順序を画面からたどれるようにすることが設計の出発点です。
ExcelやスプレッドシートからCRMへ集計方法を移す場合も、画面を作るだけでは数値はそろいません。現在の集計条件とCRMの入力状況を照合し、差が出る理由を確かめてから会議で使う指標を切り替えます。
本記事は「RevOps（レベニューオペレーションズ）入門｜営業・マーケ・CSを統合して収益を最大化する方法」シリーズの一部です。
この記事でわかること
経営会議の数字をそろえたい方、営業の案件管理を改善したい方、マーケティングやCSの成果を次の対応につなげたい方に向けて、画面の役割を決めてから運用を見直すまでの流れを整理します。読み進める際は、自社で判断が止まっている場面を一つ思い浮かべてください。その場面に必要な指標、内訳、対象レコードを選ぶ手掛かりになります。
- 活用されない原因 — 表示内容、指標定義、データ更新のどこに問題があるかを切り分ける方法がわかります。
- 部門別のKPI例 — 経営、営業、マーケ、CSそれぞれで、数値から何を判断するかを確認できます。
- 設計と構築の手順 — KPI定義、元データの確認、レイアウト、利用者との見直しを進める順序がわかります。
- 数値を行動につなげる方法 — 差分を見つけた後に確認する内訳と、対応を決める条件を整理できます。
読み終えるころには、自社で最初に作るダッシュボードを一つ選び、HubSpotの画面でKPIの定義から公開までを進められます。
先に、画面を作る順番を自社の状況から選べる判断表を示します。
| 今の状況 | 最初に作る画面 | 先に決めること |
|---|---|---|
| 会議のたびに数字が合わない | 経営向けの月次ダッシュボード | KPIの計算式、対象レコード、締めのタイミング |
| 案件が止まっていても気づけない | 営業マネージャー向けの週次ダッシュボード | 停滞の条件（ステージ滞在日数、最終活動日） |
| 担当者が次の一手を決められない | 営業担当者向けの日次ダッシュボード | 今日対応する取引の抽出条件 |
| マーケの成果が営業に伝わらない | 流入元別の商談・受注レポート | 流入元の入力ルール、商談化の定義 |
経営向けの画面では、誰が、いつ、どの範囲の数値を見て判断するかを先に決めます。次の表は、その利用場面の例です。閲覧頻度は表のとおりに固定せず、自社の会議で判断する時点に合わせます。
| 項目 | 内容 |
|---|---|
| 対象者 | CEO、COO、CRO、経営企画 |
| 閲覧頻度 | 週次の経営会議、月次の経営レビュー |
| 意思決定内容 | 戦略の方向性、リソース（人員・予算）の配分、四半期計画の修正 |
| KPIの特徴 | 集約されたマクロ指標。詳細よりもトレンドと達成度を重視 |
マーケティング向けの画面では、獲得数だけで施策を評価せず、費用、引き継ぎ、その後の進行を同じ対象範囲で確認します。次の観点から、追えるデータと追えないデータを分けます。接点や取引との関連を確認できない場合は、成果の解釈を急ぎません。
| ポイント | 内容 |
|---|---|
| 施策別の効果測定 | 「何にいくら使って、いくら獲得したか」が施策単位で見える設計 |
| ファネル全体の可視化 | リード獲得だけでなく、商談化・受注までのファネル全体を追跡 |
| アトリビューション | マルチタッチのアトリビューション（最初の接点、最後の接点、加重配分）を考慮 |
| 営業へのフィードバック | MQLの引き渡し後のフォロー率・転換率を可視化し、営業との連携を改善 |
CRMダッシュボードが活用されない原因
使われていない画面を直すときは、まず利用者に「どの場面で、何を判断しようとして、どこで止まったか」を確認します。必要な情報が見つからないなら表示内容、数字を信用できないなら定義や元データ、見ても行動が決まらないなら会議での使い方を点検します。原因を分けてから修正対象を決めます。
利用者の発言だけで原因を決めず、直近の会議資料と画面を並べて確認します。会議資料にある数値が画面にもあるのに使われないなら、表示場所や更新時点を調べます。両者の値が違うなら、表示項目を増やす前に集計条件を照合します。数値が一致しても議論が進まないなら、差の内訳と対応対象へ進めるかを試します。修正後は同じ会議の議題を使い、画面だけで判断と担当者の決定まで進めるか確かめます。
次の指標は、名称だけでは計算範囲や判断方法が決まりません。売上なら計上時点、パイプラインなら含めるステージ、費用を使う指標なら集計対象を決めてから表示します。表中の表示形式や数値目安は採用を前提とせず、自社で確認できる定義と比較基準を優先します。
| KPI | 定義 | 表示形式 |
|---|---|---|
| 売上推移 | 売上の増減傾向を確認できる月次推移 | 折れ線グラフ+目標ライン |
| パイプライン推移 | 過去からのパイプライン総額の変化傾向 | 積み上げ棒グラフ（ステージ別） |
| CAC（顧客獲得コスト） | 営業・マーケ費用 ÷ 新規顧客獲得数 | 折れ線グラフ（月次推移） |
| LTV / CAC比率 | 顧客生涯価値 ÷ 顧客獲得コスト | 数値+推移グラフ（目安3.0以上） |
| 加重パイプライン予測額 | 対象期間の商談金額にステージ確度を掛けた値の合計 出典 | 数値 |
| Win Rate | 受注件数 ÷ クローズ済み商談件数 × 100 出典 | パーセンテージ |
| NPS（Net Promoter Score） | 推奨者の割合から批判者の割合を引いた顧客推奨度 出典 | 数値＋時系列 |
| NRR（Net Revenue Retention） | 既存顧客の継続収益に拡張・縮小・解約を反映した維持率 出典 | パーセンテージ |
| ヘルススコア平均 | スコアを設定した顧客の平均値 出典 | 数値＋推移（推移表示はService Hub Enterprise） |
| ヘルススコア分布 | 顧客の健康状態をAt-risk・Neutral・Healthy別に集計する出典 | 状態別の割合 |
| 既存顧客の追加売上 | 拡張・アップセル商談による売上出典 | 売上金額 |
比較する期間、対象顧客、費用の含め方を確認します。
利用が止まる兆候を見つけたら、実際に止まった判断を確認します。たとえば会議でExcelが使われているなら、その資料のどの数値が必要だったかを特定し、CRMで同じ条件の数値を出せるか照合します。条件をそろえても必要な判断ができないときに、表示項目や画面の役割を見直します。
| 兆候 | 原因 | 対策 |
|---|---|---|
| アクセス頻度が低下 | KPIが業務と直結していない | ペルソナへのヒアリングを行い、KPIを見直す |
| 会議でExcelが使われる | ダッシュボードにない指標が必要 | 必要な指標をダッシュボードに追加する |
| 数字の信頼性を疑問視 | データ品質の問題 | データクレンジングを実施し、KPIの定義を再周知 |
| 「見方がわからない」 | トレーニング不足 | 部門ごとの使い方研修を実施 |
表の原因は確認を始めるための仮説です。会議でExcelが使われる場合でも、指標の不足なのか、CRMとの計上条件の違いなのかを確かめてから対策を選びます。指標が不足していれば追加する前に用途を定義し、条件が違えば同じ範囲で再集計します。利用者が数値の意味を説明できるのに次の行動を選べない場合は、研修内容だけでなく内訳や対象レコードへの導線を確認します。
情報を詰め込み、利用者が定まっていない
経営層が見る全社の推移と、営業担当者がフォローする案件では、必要な情報の粒度が異なります。同じ画面にすべてのKPIを並べると、利用者は判断に使う指標を探さなければなりません。
情報過多はグラフの数だけで決まりません。次の表のような症状が出たら、利用者に実際の画面を開いてもらい、目的の数値と対応対象へ進めるかを確認します。「20以上」という数は出典のある判定基準として扱わず、必要な情報を見つけられるかで判断します。
| 問題 | 具体的な症状 |
|---|---|
| 情報過多 | 20以上のグラフ・数値が並び、何を見ればいいかわからない |
| 表示速度の低下 | データ量が多すぎてダッシュボードの読み込みに時間がかかる |
| 目的の不明確化 | 「このダッシュボードは誰のためのものか」が定義されていない |
マーケティングでは、チャネル別の獲得状況と施策別の反応がそれぞれ別の判断に使われます。次の指標から、施策を比べる目的に必要なものを選び、詳細を確認する場所も決めます。施策別ROIを使う場合は、費用と商談ベースの売上をどの施策に対応させるかを先に確認します。
| KPI | 定義 | 表示形式 |
|---|---|---|
| チャネル別リード獲得数 | オーガニック、広告、SNS、ウェビナー等のチャネル別内訳 | 横棒グラフまたは円グラフ |
| 施策別CVR | 各施策（LP、フォーム、CTA）のコンバージョン率 | テーブル（CVR順ソート） |
| コンテンツ別パフォーマンス | ブログ記事・ホワイトペーパー別のリード獲得数 | 一覧表示形式 |
| 施策別ROI | 各施策の投資金額と獲得売上（商談ベース） | テーブル+棒グラフ |
まず画面の利用者と判断場面を書き出します。異なる利用者が別の判断をしているなら画面を分け、同じ判断に使う指標なら一画面にまとめます。表示項目を残すか迷ったら、その指標を見て変わる行動を説明できるかで判断します。説明できない項目は、用途を確認してから配置を見直します。
最初に見る集約値と、差が出たときに開く内訳を分けると、必要な詳細を残しながら判断の順序を示せます。
たとえばチャネル間の差を見て施策配分を決めるなら、まず獲得対象の定義をそろえ、次にチャネル別の内訳を比較し、最後に対象施策を開きます。接点の記録が不足していれば配分の判断を保留し、記録方法を確認します。画面の読み込みが遅い場合も、どの表示に時間がかかるかを確かめてから構成を見直します。見直した後は、利用者が同じ議題で必要な指標を見つけ、対象施策まで進めるか試します。
部門ごとにKPIの定義が異なる
「リード」「商談」「売上」の範囲や計上時点が部門ごとに違うと、同じ名称でも値が一致しません。差が出たときは、まず対象レコード、計測期間、集計条件、更新時点を並べて比較します。
次のような不一致があれば、表示された値のどちらかを直ちに誤りと決めず、用途と計上条件を確認します。
| よくある定義の不一致 | 影響 |
|---|---|
| 「リード」の定義がマーケと営業で異なる | リード数の報告値が部門間で一致しない |
| 「商談」のカウント基準が営業担当者ごとに異なる | 商談数・Win Rateのレポートが正確でない |
| 「売上」の計上タイミングが営業と経理で異なる | 経営ダッシュボードの売上と会計の売上が一致しない |
定義が違う指標を同じ値に合わせる前に、それぞれ何の判断に使う数値かを確認します。同じ判断に使うなら定義をそろえ、目的が違うなら名称と説明を分けます。変更後は、関係者が同じ対象レコードを同じ条件で数えられるか確かめてから会議で使います。
たとえば営業の「受注」と経理の「売上」が異なる時点を示すなら、両者を同じ名称で比較しません。まず各数値の計上条件を記録し、会議で必要なのが案件の進行判断か、会計上の実績確認かを決めます。その用途が定まってから、対応する指標を画面に置きます。両方が必要な会議なら、数値を別々に表示し、どの取引がどの時点で各指標に含まれるかを確認できるようにします。
構築後の更新担当と見直し機会がない
事業の状況や営業プロセスが変わると、以前の指標やフィルターが実務に合わなくなることがあります。数値の入力・更新を確認する担当と、指標の定義を見直す担当を決めます。
会議で必要な判断ができなくなった、集計差が続く、対象業務が変わったといった場合を見直しのきっかけにします。利用者から「見ていない」と言われた指標は、表示位置だけでなく、判断目的が残っているかを確かめます。目的が残っているなら不足する内訳や更新状況を確認し、目的が変わったなら画面の役割から見直します。変更後の会議では、同じ判断を画面から再現できたかを確認します。
ダッシュボード設計の基本原則
設計の出発点は、画面を見る人が決める仕事です。「状況を把握する」「変化の理由を調べる」「対応対象を選ぶ」という順序に沿って、必要な指標と詳細への導線を決めます。企業様によって最適な形は異なります。指標の数や配置を固定せず、実際の判断場面で使えるかを確かめながら調整します。
利用者ごとに判断する時点と必要な粒度を並べると、同じデータをどの画面に置くか決めやすくなります。閲覧頻度は運用例として捉え、自社の会議や活動の時点に合わせます。利用者が複数いる場合は、誰が差を発見し、誰が個別レコードを確認し、誰が対応を決めるかも書き分けます。
| ペルソナ | 閲覧頻度 | 意思決定の内容 | KPIの粒度 |
|---|---|---|---|
| 経営層（CEO/CRO） | 週次〜月次 | 戦略的判断、リソース配分 | 集約・マクロ |
| 営業マネージャー | 日次〜週次 | チーム運営、パイプライン管理 | チーム・個人 |
| 営業担当者 | 日次 | 自身の活動計画、優先順位付け | 個人・ミクロ |
| マーケ責任者 | 週次〜月次 | 施策の最適化、予算配分 | チャネル・施策 |
| CS責任者 | 週次〜月次 | 解約リスク管理、顧客対応 | 顧客・セグメント |
一つの画面に一つの判断目的を置く
ダッシュボードごとに利用者、確認する場面、決めることを定義します。経営会議用なら事業の進捗やリソース配分、営業担当者用なら案件の優先順位や次のフォローが中心です。
判断の流れを画面に反映する際は、現状を示す指標、差の理由を調べる内訳、対応対象を確認するリストを結び付けます。上部に数値を置いたら、利用者がどの順に詳細を開くかも確かめます。
| 設計要素 | 内容 |
|---|---|
| 見る（Awareness） | 現在の状況を一目で把握できるサマリー指標を上部に配置 |
| 考える（Analysis） | 要因分析に必要なブレイクダウン（推移、内訳、比較）を中部に配置 |
| 動く（Action） | 具体的なアクションにつながるリスト・アラートを下部に配置 |
マーケティング向けには、施策の結果を見て何を継続・見直すかを決める場面を設定します。結果の判断に商談以降の情報が必要なら、その関連付けを確認してから画面に載せます。
| 項目 | 内容 |
|---|---|
| 対象者 | CMO、マーケ部長、マーケ担当者 |
| 閲覧頻度 | 週次の施策レビュー、月次の成果報告 |
| 意思決定内容 | 施策の継続/停止、予算の再配分、チャネル戦略の最適化 |
画面に必要な指標が決まっても、元データが判断に使えるとは限りません。次の項目を、対象レコードを実際に開いて確認します。分析に使えるデータ量かどうかは件数だけで決めず、比較したい期間や対象が記録されているかを調べます。
| 確認項目 | チェック内容 |
|---|---|
| データの完全性 | 必須項目（金額、ステージ、担当者等）の入力率は十分か |
| データの正確性 | 商談ステージの定義が遵守されているか。古い商談が放置されていないか |
| データの一貫性 | 命名規則が統一されているか。表記揺れがないか |
| データ量 | 有意な分析に使えるだけのデータがあるか（一定期間にわたるデータを推奨） |
「十分な入力率」や「一定期間」は、すべての画面に共通する数値基準ではありません。予定日が欠けた取引を含めて着地を予測する場合と、担当者が決まった取引だけを確認する場合では、欠損が判断に及ぼす影響が違います。比較したい対象を先に決め、欠けた情報によって結論が変わり得るなら、入力を確認してから次へ進みます。欠損がある範囲を除いて暫定的に見る場合も、何を除いた結果かを画面の利用者と共有します。
利用者別に画面を分ける際は、集約値から担当者や顧客の詳細へ進む関係を残します。経営層が見つけた変化を、営業マネージャーが確認する対象までたどれるかが確認点です。
| 利用者 | 主な確認場面 | 判断内容 | 指標の粒度 |
|---|---|---|---|
| 経営層 | 経営レビュー | 売上やパイプラインの状況、計画の調整 | 全社・期間別 |
| 営業マネージャー | チーム定例 | 案件の停滞、支援が必要な担当者 | チーム・担当者別 |
| 営業担当者 | 日々の活動計画 | 優先する案件と次の行動 | 個人・案件別 |
| マーケ責任者 | 施策レビュー | チャネルや施策の継続・見直し | チャネル・施策別 |
| CS責任者 | 顧客レビュー | 更新や解約リスクへの対応 | 顧客・セグメント別 |
同じ指標を複数の画面に置く場合も、経営層には全体の変化、担当者には対応する案件というように、判断に必要な粒度を変えます。数値が食い違うなら、画面ごとの対象範囲やフィルターを照合します。
見る、考える、動くの順に配置する
画面の上部では現状を示し、中段では推移や内訳を確認し、下部では個別の案件や顧客など行動対象を表示します。差が見えたら内訳を確認し、対応が必要なレコードへ進めるかを利用者と確かめます。
| 画面の位置 | 役割 | 表示例 |
|---|---|---|
| 上部 | 現状をつかむ | 売上、目標進捗、商談件数 |
| 中段 | 要因を確かめる | 期間推移、ステージ別内訳、チャネル別実績 |
| 下部 | 行動を決める | 停滞案件、フォロー対象、更新予定顧客 |
たとえば目標との差が見えたとき、まず対象期間と集計条件を確認し、次に担当者やステージのどこで差が生じているかを見ます。個別の対応が必要なら案件を開き、入力の不足なら記録を確認し、集計条件の問題ならレポートの定義を見直します。この分岐をたどれない場合に、内訳やリンクを追加します。
画面を試す際は、利用者に差が見えたところで操作を止めず、「どの取引を開き、誰に何を確認するか」まで実演してもらいます。数値の意味で迷うなら定義、対象を見つけられないなら導線、対象は見つかるのに対応が決まらないなら記録内容を見直します。修正後は、同じ判断場面でもう一度試します。
比較基準と入力ルールを合わせる
単独の数値だけでは変化を判断しにくいため、目的に応じて目標、前期間、部門別などの比較基準を選びます。比較する数値は、対象範囲と期間をそろえます。担当者間で比べる場合も、担当する案件の範囲が違えば、その違いを確認してから解釈します。
算出に必要なCRM項目が未入力なら、結果を評価する前に欠損の範囲を確認します。欠けているレコードが特定の担当者、ステージ、期間に偏っていないかを調べ、その偏りが比較結果を変えるなら判断を保留します。必要な項目と入力する場面を決め、次のレビューで同じ条件のデータを比較できる状態にします。
- 業界水準 ── 業界平均Win Rateなどを比較基準にする場合は、対象範囲や計測期間、指標の定義をそろえ、自社の数値と条件を確認してから解釈します。条件を照合できない場合は、自社の定義がそろった期間推移や目標との比較を先に使います
- 前年同月比 ── 推移を比較する際は、各年の同じ月を対象にし、集計条件と入力ルールをそろえます。途中でステージ定義や計上方法が変わっていれば、変わった前後を同じ条件として解釈せず、変更の影響を確認します
KPIは目標、過去の実績、チーム平均、業界水準と比べることで、数値の意味を判断しやすくなります。どの基準を使うか迷う場合は、その比較から決めたい行動を先に書きます。条件をそろえられる基準から使い、そろえられない比較には対象の違いを明示します。
| 比較基準 | 用途 | 例 |
|---|---|---|
| 前期比 | トレンドの把握 | 前の期間と現在の数値を比較 出典 |
| 平均値 | 相対評価 | 担当者の架電件数とチーム平均を比較 出典 |
| ベンチマーク | 業界水準との比較 | 自社の成約率と業界平均を比較 出典 |
経営と営業のダッシュボードを設計する
経営と営業は同じ取引データを使っても、判断の粒度が異なります。経営は全体の進捗と変化、営業マネージャーはチーム内の滞留や支援対象、担当者は次に動く案件を確認します。それぞれの画面で判断がつながるよう、取引ステージや入力項目の意味を共有します。
経営向けは全体の進捗と変化を捉える
経営向けには、売上、パイプライン、受注状況など、事業の進捗を示す指標を置きます。計画との差が見えたら、期間、部門、ステージなどの内訳を確認し、どこを詳しく調べるか決められる構成にします。
経営会議では、数値の定義を確認する時間と、対応を決める時間を分けます。会議前に定義と更新時点を確認できるようにし、差が出た際には詳細へ進める画面にします。表示間隔やレイアウトは、実際の判断場面で確かめます。次の表の表示間隔は、期間ごとの進捗を判断する場面の例です。直近の案件変化を扱う会議なら、必要な更新時点を別に決めます。
| ポイント | 内容 |
|---|---|
| 数値の信頼性 | 経営会議で使う数値は、定義を明文化し、全部門で合意を得ておく |
| 表示間隔 | 月次・四半期の集約値が中心。日次データは不要 |
| ドリルダウン | サマリーから詳細（部門別、営業担当別）に掘り下げられる設計にする |
| レイアウト | グラフは1画面で全体を俯瞰できる数と大きさに収める。ただし、文字や数値が読みにくい場合は画面を分ける。 |
表の表示間隔は、経営会議で期間ごとの進捗を判断する場合の例です。日次データの要否も一律には決まりません。会議で直近の案件変化まで確認するなら、判断に必要な更新時点と詳細への導線を別途確かめます。
次の画面は、デモポータルの営業ダッシュボードです。集約値を見つけた後に、パイプラインの内訳や対象取引へ進めるかを確認する例として見てください。
経営向けに載せる指標は、変化を発見するためのものと、その理由を確かめるためのものを分けます。費用を使う指標は、分子と分母の対象期間や集計範囲がそろう場合に比較します。
| 指標例 | 判断に使う内容 | 表示の考え方 |
|---|---|---|
| 売上 | 期間目標に対する進み具合 | 実績と目標を並べる |
| パイプライン総額 | 今後の受注見込みの規模 | ステージや担当部門で内訳を確認する |
| 受注率 | 商談から受注への転換状況 | 対象期間と商談の定義をそろえる |
| 営業サイクル | 商談開始から受注までの傾向 | 期間ごとの推移を確認する |
| 停滞・期限超過案件 | 着地見込みへの影響 | 個別の取引と担当者へ移れるようにする |
| CAC（顧客獲得コスト） | 営業・マーケ費用 ÷ 新規顧客獲得数 | 月次推移を折れ線グラフで表示する |
| LTV / CAC比率 | 顧客生涯価値 ÷ 顧客獲得コスト | 数値と推移グラフで表示する |
売上や商談の定義が営業と経理で異なる場合、レポートの値だけで合意を作ることはできません。CRMで見る受注実績と会計上の売上がどの時点で対応するかを整理し、異なる指標は名称や説明を分けて表示します。差が出たときに確認する元データも決めておきます。対応関係が説明できなければ、その差を根拠に計画を変更する前に、関係部門で対象取引を確認します。
営業マネージャー向けはパイプラインの状態を見る
営業マネージャーは、チームの実績に加え、どのステージに案件があり、何が進行を妨げているかを確認します。件数や金額が変化したら、ステージ別の内訳から個別の取引へ進み、担当者と次の対応を決めます。
画面を使う際は、最初に全体の差を確認し、次にステージと担当者の内訳を見ます。最後に、対応が必要な取引の記録を開きます。次の表は、その順序に沿って置く指標の例です。期間を表す行は、自社の会議や案件確認の時点に読み替えて選びます。
| セクション | KPI | 表示形式 |
|---|---|---|
| サマリー | チーム売上（目標比）、商談件数（新規/進行中/受注/失注）、今月のWin Rate | 進捗バー、数値4つ、前月比のパーセンテージ |
| パイプライン | ステージ別商談分布 | ファネルグラフまたは横棒グラフ |
| 個人成績 | 担当者別の売上・商談数・活動量 | テーブル（ランキング形式） |
| アクション | 今週クローズ予定の商談 | テーブル+予想金額 |
ステージ別の集計を使う前に、各ステージへ進む条件と、記録すべき項目を決めます。条件が担当者によって違うままでは、同じステージの案件を比較しにくくなります。
| 設計要素 | 決める内容 | レポートへの反映 |
|---|---|---|
| 取引ステージ | 受注率や営業プロセスが変わる節目 | ステージ別の件数と金額 |
| 受注確度 | ステージごとの見込みの扱い | 加重したパイプラインの確認 |
| ステージ定義 | 次の段階へ進む条件 | 滞留や差し戻しの把握 |
| 必須入力プロパティ | 各段階で記録する情報 | 金額や予定日などの入力状況 |
| 個人成績 | 担当者別の売上・商談数・活動量 | テーブル（ランキング形式） |
予定日が過ぎた取引でも、顧客との確認が進んでいる場合と、次の活動が決まっていない場合では対応が異なります。画面で対象を見つけた後は取引の記録を確認し、予定日の更新、担当者への支援、見込みの見直しのどれが必要かを決めます。記録が不足しているなら、まず担当者に状況を確認します。担当者が次の活動を説明できれば記録と予定日を更新し、進行上の障害があれば支援内容を決めます。
次の画面をご覧ください。
次の画面をご覧ください。
営業担当者向けは次の一手を分かりやすくする
個人向けには、自分の案件、予定日が近い取引、次の活動が決まっていない案件などを確認できるようにします。活動件数だけで優先順位を決めず、取引のステージ、顧客とのやり取り、次に確認すべき事項を合わせて見ます。
営業担当者が使う画面と、マネージャーがチームを確認する画面は、利用場面を分けて考えます。次の表は、マネージャーが個人別の状況を確認する場面です。表中の頻度より、実際に支援や案件の優先順位を決める時点を優先します。
| 項目 | 内容 |
|---|---|
| 対象者 | 営業マネージャー、営業部長 |
| 閲覧頻度 | 日次（朝会）、週次（チーム定例） |
| 意思決定内容 | チームのパフォーマンス管理、リソース再配分、案件フォロー指示 |
担当者自身の画面では、実績、進行中の案件、活動の記録を、次に何をするか決めるために使います。各指標は、必要な対象取引までたどれる形にします。
| セクション | KPI | 表示形式 |
|---|---|---|
| 自分の成績 | 個人売上（目標比）、個人の商談件数と金額、個人のWin Rate | 進捗バー、数値、チーム平均比のパーセンテージ |
| 商談進捗 | 自分の商談一覧（ステージ別） | カンバンビューまたはテーブル |
| 活動量 | 今週の活動件数（架電、メール、商談） | 数値+目標比 |
HubSpotの取引パイプラインはボード表示でステージごとの案件を確認できます。レポートで傾向を見つけたら、取引レコードで個々の顧客とのやり取りを確かめます。記録と実態が違う場合は、先に予定日やステージを更新します。記録がそろってから、フォローする案件と担当する活動を決めます。
個人の画面に置く指標は、次の点を確認します。
- 個人売上の実績と目標 ── 並べるときは、目標の対象期間と売上の集計期間をそろえます。差があれば、担当する取引の金額と予定日を確認します
- 商談件数と金額 ── ステージ別の一覧と結び付けます。件数が増えていても、次の活動が決まっていない案件があれば、優先して状況を確認します
- 個人のWin Rate ── チーム平均と比べる場合は、数える商談の条件や担当案件の違いを確かめます。差だけで評価を決めず、どのステージで進行が止まっているかを確認します。比較条件が異なる場合は順位づけを保留し、担当案件の範囲をそろえられるか検討します
- 活動件数 ── 実施した仕事を振り返るために使います。目標との差があっても、件数だけで次の活動を決めず、顧客とのやり取りと案件の進行状況を確認します。推移に変化があれば、記録の不足か実際の活動の変化かを分けます
外出先でスマートフォンから閲覧する場合は、最初に必要な案件と次の活動が確認できるかを利用者と試します。詳細を見られない、操作しにくいといった箇所があれば、表示順や情報の見せ方を見直します。
マーケティングとCSのKPIを設計する
マーケティングでは獲得後の引き継ぎや商談への進行を、CSでは顧客対応や更新に向けた状況を確認します。部門ごとの画面を作る前に、どのレコードを結び付け、どの段階で担当が変わるかを決めます。つながりが確認できないデータは、成果の解釈を保留して関連付けや定義を点検します。
マーケティングの指標を比較する際は、獲得した対象の定義と、施策やチャネルへの割り当て方をそろえます。転換率なら分子と分母に含める対象を確認し、費用を使う指標なら同じ範囲の費用と獲得数を対応させます。
| KPI | 定義 | 表示形式 | 比較基準 |
|---|---|---|---|
| リード獲得数（当月） | 新規リードの総数 | 数値+目標進捗バー | 目標値、前月比 |
| MQL数 | Marketing Qualified Leadの数 | 数値 | 目標値、前月比 |
| MQL→SQL転換率 | SQLに転換されたMQLの割合 | パーセンテージ | 判断の推移を直近の傾向と過去の平均に照らして確認 |
| リード獲得単価（CPL） | マーケ費用 ÷ リード獲得数 | 金額 | 前月比、チャネル別 |
CS向けには、顧客の状態を示す情報と、対応を始めるきっかけを区別します。ヘルススコアを使う場合も、値だけで対応を決めず、問い合わせ履歴や利用状況など、その値の背景を確認します。利用状況やNPSを使うかどうかも、自社で取得している情報と判断目的に合わせます。
| ポイント | 内容 |
|---|---|
| 予防的アクション | 「解約してから分析」ではなく「解約リスクを事前に検知」する設計 |
| ヘルススコアの設計 | プロダクト利用頻度、サポート問い合わせ数、NPSなどを複合的に評価 |
| 契約更新の先行管理 | 更新時期を見据えて、余裕を持った準備を促す更新予定リストを先行表示 |
| CS活動のROI | CS施策（QBR、トレーニング等）と解約率・NRRの相関を可視化 |
表中のスコアや相関は、それだけで解約や施策の効果を示すものではありません。対応対象を選ぶ前に、対象顧客の履歴と契約状況を確認します。施策を評価する場合は、比較する顧客の範囲と期間をそろえ、確認できない要因があれば結論を保留します。
会議で使う画面は、そこで決めることと結び付けます。次の利用場面を参考に、自社では誰が差を調べ、誰が対応を引き受けるかを決めます。表中の会議頻度は例として扱い、判断に必要なデータがそろう時点で確認します。
| 会議 | 使用ダッシュボード | 使い方 |
|---|---|---|
| 経営会議（月次） | 経営ダッシュボード | 売上進捗・パイプラインの報告をダッシュボードで行う |
| 営業マネージャー定例（週次） | 営業マネージャー向け | チームの成績・パイプラインレビューに使用 |
| 営業朝会（日次） | 営業担当者向け | 各自の当日の活動計画を確認 |
| マーケ定例（週次） | マーケティングダッシュボード | 施策の進捗・リード獲得状況をレビュー |
| CS定例（週次） | CSダッシュボード | At Risk顧客のフォロー状況を確認 |
マーケティングはリードから受注まで追う
リード数だけでは、営業への引き継ぎ後に何が起きたかは分かりません。施策別の獲得状況を見た後、MQLの判定、営業への引き継ぎ、商談への進行を順に確認します。
次の表では、指標ごとに見る対象と、その後に確かめる判断を示します。費用対効果の判断は、獲得した対象と商談・受注の関連が追えることを確認してから行います。
| 指標例 | 確認すること | 次の判断 |
|---|---|---|
| リード獲得数 | チャネルや施策ごとの獲得状況 | 施策の配分を見直す |
| MQL数 | 営業連携対象のリード数 | 判定条件を見直す |
| MQLからSQLへの転換 | 営業への引き継ぎ後の進行状況 | 引き継ぎ条件やフォローを確認する |
| 施策別コンバージョン | フォームやコンテンツの反応 | 継続・改善する施策を選ぶ |
| 商談・受注への貢献 | 獲得後の進展 | 営業と施策評価を共有する |
| CPL | 獲得にかかった費用をリード獲得数で割って算出する | 前月比とチャネル別に比較する |
| KPI | 各施策の投資額と商談ベースの獲得売上を比較する | テーブル＋棒グラフ |
| リード→MQL→SQL→商談→受注の件数と転換率 | 各段階の対象件数と、前段階から次段階への転換率 | ファネルグラフ |
| 今月の施策カレンダー | 予定されている施策の一覧 | カレンダービュー |
| マーケ貢献売上 | マーケ起点の商談から生じた受注金額 | 数値+推移グラフ |
獲得は増えても引き継ぎ後の進行が見えない場合は、施策の評価を急がず、MQLの判定条件、営業が受け取る条件、レコードの関連付けを順に確認します。引き継がれた対象を営業側で特定できなければ、まず関連付けと記録方法を整えます。対象は追えるのに進行が止まっていれば、営業との確認でフォロー状況と判定条件を調べます。そのうえで同じ条件の施策を比較し、継続や改善を決めます。
施策別の比較では、同じ取引に複数の接点がある場合の扱いも確認します。接点の割り当て方が決まっていなければ、表の「マーケ貢献売上」を施策ごとに足して全体の売上として扱いません。まず比較の目的を決め、接点と取引の対応を説明できる範囲で判断します。接点を追えない施策は、その範囲を明示して獲得や引き継ぎの状況から確認します。
CSは顧客の状態と対応対象をつかむ
CS向けには、問い合わせやチケットの状況、顧客の契約更新、解約理由など、顧客対応に関わる情報を整理します。対応履歴を顧客レコードと関連付け、状況を確認した人が次の担当や対応予定までたどれるようにします。
次の指標を同時に見る場合も、過去の結果を振り返る指標と、これから対応する顧客を選ぶリストを分けます。スコアや件数に変化があれば、対象顧客の履歴を開いて理由を確かめます。
| 指標例 | 見る内容 | 行動につなげる方法 |
|---|---|---|
| 問い合わせ・チケット状況 | 未対応や対応中の件数 | 優先対応の担当を決める |
| 更新予定 | 更新時期が近い顧客 | 事前確認の予定を組む |
| 解約理由 | 顧客が利用を終了した背景 | 商品や支援方法の改善点を共有する |
| オンボーディング状況 | 導入時の進行と未完了事項 | 支援が必要な顧客を特定する |
| 解約率の推移 | 月次・四半期の解約率を期間ごとに確認する | 前月比と目標値を比較し、変化を確認する |
| ヘルススコア平均 | 全顧客のヘルススコアの平均値 | 数値と推移を表示し、前月比で比較する |
| 解約理由の件数 | 解約した顧客を理由別に集計した件数 | 円グラフまたはパレート図 |
| オンボーディング完了率 | 新規顧客のオンボーディング完了割合 | パーセンテージ+推移 |
| 既存顧客からの追加売上 | 既存顧客へのアップセル・クロスセルによる売上 | 数値と目標進捗バー |
| 状態の悪い顧客の対応リスト | ヘルススコアが低い顧客の一覧 | テーブル（顧客名、スコア、契約更新日、最終接触日） |
| NPS（Net Promoter Score） | 顧客推奨度 | 数値+ゲージ、前回調査比・業界平均と比較 |
| NRR | 既存顧客の純収益維持率 | 数値 |
| ヘルススコア分布 | 全顧客のヘルススコアをGood／Neutral／At Riskの状態別に分布表示 | 積み上げ棒グラフまたはドーナツグラフ |
未対応の顧客が見つかったら、履歴と対応期限を確認して担当を決めます。更新予定だけが分かり、顧客の状態を判断できない場合は、確認すべき履歴や未完了事項を決めて記録を補います。その情報がそろってから、対応内容と予定を確定します。
平均スコアだけでは、対応が必要な顧客を選べません。平均が変わった場合は分布を見て、変化した顧客の記録へ進みます。顧客ごとの状況がスコアと食い違うなら、対応の判断を記録に基づいて行い、スコアの算出に使う項目を見直します。スコアから対象を選ぶ運用に戻すのは、実際の顧客状況とのずれを確認した後です。
部門間の指標を一つの流れでつなぐ
マーケティングが獲得したコンタクトは、条件に応じて営業へ引き継がれ、取引となり、受注後は顧客対応や請求に関連します。部門別ダッシュボードを分けても、定義やレコードの関連が分断されていれば、段階をまたいだ進行は確認できません。
CSのリストも、表示した時点で終わりにしません。対象顧客を開き、更新予定、最後の接触、未完了の支援を確認できる形にします。表中の「今月/来月」は、自社が更新対応を判断する期間に合わせて設定します。
| KPI | 定義 | 表示形式 |
|---|---|---|
| At Riskの顧客リスト | ヘルススコアが低い顧客の一覧 | テーブル（顧客名、スコア、契約更新日、最終接触日） |
| 契約更新予定リスト | 今月/来月に契約更新を迎える顧客 | テーブル+更新までの日数 |
| 未完了オンボーディング | オンボーディングが遅延している顧客 | テーブル+経過日数 |
まず各段階の担当部門、ステージの変更条件、必要な項目を決めます。次に、前の段階から渡された対象が次の段階で確認できるかをたどります。失注した取引は理由を記録し、再度アプローチするかを担当部門で判断します。流れを追えない箇所が見つかったら、その接点の定義や入力方法を見直し、同じ対象を再びたどれるか確認します。
CRMダッシュボードを構築し運用する手順
現在のExcel集計や会議資料から、実際に使っている判断を洗い出します。その判断に必要なKPIを定義し、元データを確認してから画面を作ります。利用者が業務で使った結果をもとに、表示内容と運用方法を見直します。
次の画面は、クローズ日別に商談を並べたテーブルです。
構築時には、集約した数値から行動対象へ進めるリストも用意します。次の例では、対象の選び方を定義し、一覧から取引や担当者の詳細を確認できるようにします。「大型」「リスク」の条件は自社の判断目的に合わせて決めます。
| KPI | 定義 | 表示形式 |
|---|---|---|
| 大型商談リスト | 金額規模が大きい商談の一覧 | テーブル（商談名、金額、ステージ、担当者、予定日） |
| リスク商談 | 停滞中または予定日超過の商談 | テーブル+アラート表示 |
| 部門別の目標達成率 | 営業・マーケ・CSそれぞれの目標進捗 | 横棒グラフ |
個人向けの画面を作るときは、担当者がいつ開き、どの案件について次の活動を決めるかを確認します。閲覧の時点とデータ更新の時点が合っているかが判断材料です。
| 項目 | 内容 |
|---|---|
| 対象者 | 営業担当者（個人） |
| 閲覧頻度 | 日次（毎朝の自己確認） |
| 意思決定内容 | 今日の活動計画、優先すべき商談の判断 |
表示する情報は、担当者が次に行う活動までたどれるかで選びます。次の表にある更新時点や端末の条件は、利用場面を確認するための観点です。反映速度を一律の必須条件とせず、担当者が判断する時点で記録が実態を表しているかを確かめます。
| ポイント | 内容 |
|---|---|
| アクション志向 | 「見るだけ」ではなく「次のアクション」が明確なダッシュボードにする |
| リアルタイム性 | 営業担当者向けはリアルタイム（または当日反映）のデータが必須 |
| シンプルさ | 営業担当者が確認する指標を選び、各グラフで何を判断するかを明記する。ただし、業務上必要な指標は省かない |
| モバイル対応 | 外出の多い営業はスマートフォンでの閲覧を前提に設計 |
表の「必須」は、すべての営業担当者に共通する技術要件ではありません。案件を判断する時点で記録が更新されていなければ、画面への反映だけを速くしても判断材料はそろいません。まず、いつ誰が記録し、担当者がいつ画面を見るかを確かめます。判断前に記録を更新できない場合は、影響する案件を明示し、入力の場面や画面を使う時点を見直します。スマートフォンでの閲覧も、実際の働き方に照らして必要性を決めます。
CS向けには、顧客レビューで対応対象を選ぶ画面と、解約理由などを振り返る画面の用途を確認します。必要な判断が異なる場合は、同じ画面に詰め込まず表示を分けます。
| 項目 | 内容 |
|---|---|
| 対象者 | CS責任者、CSマネージャー、CS担当者 |
| 閲覧頻度 | 週次のチーム定例、月次の解約分析 |
| 意思決定内容 | 解約リスクへの対応、アップセル機会の特定、CS施策の最適化 |
KPIは名称や計算式だけでなく、どのレコードを含め、いつのデータを使い、誰が更新を確かめるかまで定義します。次の項目が決まっていない指標は、表示前に関係者と用途をそろえます。更新頻度は選択肢から機械的に決めず、判断する時点に必要な情報がそろうかで選びます。
| 定義すべき項目 | 具体的な内容 |
|---|---|
| KPIの名称と計算式 | 「Win Rate = 受注件数 ÷ 商談件数 × 100」のように明文化 |
| 分子と分母の範囲 | 「商談件数」には何を含むか（テスト案件は除外か、等） |
| 計測期間 | 月次、四半期、通年のどれか |
| データソース | CRMのどのオブジェクト・プロパティから取得するか |
| 目標値 | 各KPIの目標値とその根拠 |
| 更新頻度 | リアルタイム、日次、週次のいずれか |
公開後も、画面が見られているかだけでなく、そこで必要な判断ができたかを確認します。レビューの時期は運用例を参考にしつつ、業務や定義の変更、集計差が見つかったときにも見直します。
| 運用項目 | 内容 |
|---|---|
| レビュー頻度 | 四半期ごとにダッシュボードの有効性をレビュー |
| KPIの見直し | 事業フェーズの変化に応じてKPIを追加/削除/修正 |
| データ品質の維持 | 月次のデータ監査と連動し、ダッシュボードの元データを確認 |
| アクセス権限 | ペルソナごとに閲覧権限を設定し、必要な人が必要なダッシュボードを見られるようにする |
| トレーニング | 新メンバーへのダッシュボード利用方法の教育を定型化 |
表のレビュー頻度や監査頻度は運用例です。判断できない場面、集計差、対象業務の変更が見つかったときは、予定したレビュー時期を待たずに影響範囲を確認します。
HubSpotでダッシュボードを作る手順
KPIの定義がそろったら、次の順でHubSpotに画面を作ります。メニュー名は公式ナレッジ（ダッシュボードのカスタマイズ）で確認したものです。
- 「レポート」から「ダッシュボード（Dashboards）」を開き、左上のダッシュボード名から新しいダッシュボードを作ります。名前は「経営_月次」「営業マネージャー_週次」のように、利用者と周期が分かる形にします。
- 右上の「コンテンツを追加（Add content）」から「レポート（Report）」を選び、右側のパネルでレポートにカーソルを合わせて「+追加（Add）」をクリックします。標準の営業分析レポートで足りない指標は、カスタムレポートビルダーで先に作ります。
- 追加したレポートをドラッグして配置します。現状の数字を上部、要因を調べるレポートを中段、取引一覧など対象を確認できるレポートを下部に置きます。
- 日付範囲、担当者やチーム、パイプラインのフィルターを、ダッシュボード全体またはレポートごとに設定します。会議の対象期間と同じ条件にそろえます。
- 右上の「割り当て（Assigned）」でアクセスを設定します。「所有者のみ（Private to owner）」「全員（Everyone）」のほか、特定のユーザーやチームに限定する設定は Enterprise のみです。
- 「アクション（Actions）」の「既定に設定（Set as default）」で、会議で最初に開く画面を既定にします。「共有（Share）」の「このダッシュボードをメール送信（Email this dashboard）」で、チームに送れます。
「Break down by（内訳）」の値が100を超えるレポートは読み込めず、エラーが出ます。ダッシュボードに追加できるレポート数も契約するサブスクリプションで上限があるため、一つの画面に載せる数は判断目的ごとに絞ります。
ダッシュボードで解決できないこともあります。必要なデータがCRMに入っていない場合、レポートの設定をいくら整えても数字は出ません。カスタムレポートを使えない契約（Starter など）の場合は、標準の営業分析レポートの範囲で判断目的を絞り、足りない軸は入力項目の見直しや契約の見直しとして別に検討します。また、アクセス設定を「全員」にすると全ユーザーが閲覧できるため、個人別の数字を含む画面は、閲覧範囲を決めてから公開します。
営業マネージャー向けの画面は、次のように標準レポート（営業分析スイートの標準レポート）から組み立てると、早く立ち上げられます。
| ダッシュボード | 最初に置く標準レポート（英語名） | 決めること |
|---|---|---|
| 経営_月次 | Weighted pipeline forecast、Quota attainment、Deal revenue by source | 目標との差、営業資源の配分 |
| 営業マネージャー_週次 | Deal funnel、Deal loss reasons、Time spent in deal stage | 改善する工程と重点案件 |
| 営業担当者_日次 | Deals created、Completed activities、Tasks completed | 今日対応する取引と活動 |
| マーケ・営業の連携_月次 | Lead funnel、Deal revenue by source | 流入元ごとの商談化と受注 |
標準レポートは Sales Hub の Starter、Professional、Enterprise で使えます。標準で足りない軸は、カスタムレポートビルダー（公式ナレッジ）で作ります。カスタムレポートは Professional 以上が対象で、権限も必要です。
判断目的とKPI定義を合意する
最初に、利用者、閲覧する会議や業務、画面を見て決めたいことを書き出します。続いて各KPIの計算方法と対象範囲を定義します。
| 決める項目 | 例 |
|---|---|
| KPI名 | 受注件数、MQL数、商談金額 |
| 計算方法 | 受注件数を数える条件、金額の集計方法 |
| 対象範囲 | 含めるステージや除外するレコード |
| 計測期間 | 月次、四半期、通年など |
| データ元 | CRMオブジェクトとプロパティ |
| 比較基準 | 目標、前期間、部門別など |
| 更新と確認の担当 | 数値の更新者と定義の見直し担当 |
同じ名称の指標について関係者の計算方法が違う場合は、レポート作成に進む前に用途を確認します。用途が同じなら定義を合意し、用途が違うなら名称を分けます。関係者が同じ対象レコードと期間で計算でき、比較基準まで説明できるようになったら、表示方法の検討へ進みます。
合意した定義は、数値が食い違ったときに照合できる形で残します。指標名だけでなく、対象外とするレコードや更新時点も確認できれば、次の会議で差が出た際に、定義の違いと入力の不足を分けて調べられます。
データの入力状況を確認する
KPIを算出する項目が埋まっているか、重複や表記揺れがないか、取引のステージや予定日が実態に合っているかを調べます。既存の集計と値が違う場合は、対象範囲、更新時点、元データを順に照合します。
必要なデータが不足している場合は、まず欠けているレコードを特定します。次に、その欠損がどの判断に影響するかを分けます。たとえば予定日がない取引は着地見込みの確認に、担当者がない取引は対応対象の決定に影響します。影響を受ける判断を明示し、その範囲の結論は保留します。
そのうえで、項目ごとに入力する場面、入力担当、欠損時に確認する相手を決めます。記録を補った後は同じ条件で集計し直し、既存の集計との差が説明できるか確かめます。差が残るなら、対象レコードを突き合わせて、計上時点の違いか、重複か、入力の不足かを切り分けます。差の理由が分からないままなら、画面の数値を業務判断の根拠に切り替えません。
分析結果を解釈する前には、比較する期間に同じ入力・集計ルールが使われていたか、対象レコードが判断したい範囲を表しているかも確認します。
レイアウトを作り、利用者と見直す
現状を上部、変化の要因を調べるレポートを中段、個別に動く対象を下部に配置します。判断目的が明確な画面から作り、利用者に実際の会議や業務で使ってもらいます。
利用者には「差を見つける」「理由を調べる」「対応対象と担当を決める」まで画面上で進めてもらいます。数値を見つけられても次の対応を決められない場合は、必要な内訳や対象レコードへの導線を確認します。数値の意味で議論が止まる場合は、レイアウトより先に定義へ戻ります。対象レコードが見つかっても記録が足りない場合は、入力する項目と場面を見直します。
HubSpotのレポートとダッシュボードを使う場合も、表示したいKPIに対応するデータとレポート条件を先に確認します。必要な情報を表現できない場合は、元データの持ち方とレポート方法を再検討します。（出典：HubSpot ナレッジベース）
見た目は、次の点を確認します。
- グラフ間の余白 ── 利用者が見出しと数値の対応を読み取れるかを画面上で確かめて調整します
- 色 ── ステータスの意味を利用者が区別できるようにそろえます
- 指標の配置 ── 結果指標と原因を調べる指標は、利用者が判断の流れをたどれる位置に配置します。左から右へ確認する構成が合うかどうかも、実際の業務で試して見直します
良好・注意・警告の区分を使う場合も、色だけに頼らず、状態を示す文字や対象レコードと合わせて確認します。良好な状態は緑、注意が必要な状態は黄、警告が必要な状態は赤で示します。それぞれの状態に該当する条件を先に決め、表示された顧客や取引の記録と照合します。色と実態が食い違う場合は、対応を決める前に条件を見直します。
重要な指標の配置と、画面を読み取りやすくする工夫を整理します。配置後は、利用者に会議で扱う差を一つ選んでもらい、該当する内訳と対象レコードを迷わず開けるか確認します。
会議と定期レビューに組み込む
会議では、数値と比較基準を確認し、差が出た箇所の内訳を調べ、次の対応と担当を記録します。経営レビュー、営業定例、マーケティング施策レビュー、CS顧客レビューなど、画面を使う場を決めます。
運用後は、利用者が参照しているか、指標から行動が決まるか、元データに欠損がないかを確認します。使われない指標は、判断目的が残っているかを聞きます。目的がなくなったなら表示を見直し、必要な情報が足りないなら定義と入力状況を確かめてから追加します。会議で決めた対応が対象レコードや担当者に結び付いているかも確認し、結び付かない場合は画面からの導線を見直します。
会議や定期レビューで使うダッシュボードは、利用者ごとに閲覧権限を設定し、必要な画面を見られるようにします。権限を設定した後は、実際の利用者が会議で必要な数値と詳細を開けるか確認します。
新メンバーには、画面の操作だけでなく「差が出たらどの内訳を見て、誰に確認するか」を案内します。会議や定期レビューで使い方を確認し、手順どおりに進めない箇所があれば画面か運用方法を見直します。
ダッシュボード構築を定着させる支援の進め方
StartLinkはHubSpotゴールドパートナーとして、150社以上のHubSpot支援に携わっています。ダッシュボードは、画面の見た目より先に、会議で使う数字の定義と入力ルールをそろえる工程に時間をかけます。支援の全体像は HubSpot導入・構築支援 にまとめています。
- 現状の整理・要件定義 ── 現在のExcel集計と会議資料を集め、会議ごとに「決めたいこと」と使う指標を書き出します。
- 設計・構築 ── KPIの計算式、必須入力、レポート、ダッシュボードを設計して設定します。
- データ移行 ── Excelの案件・売上データを移し、旧集計との差を突き合わせます。
- テスト・検証 ── 旧集計とHubSpotのレポートを同じ条件で並べ、差が説明できるかを確かめます。
- 定着・運用改善 ── 週次・月次の会議で使い、使われない指標は判断目的ごと見直します。
一つのダッシュボード（例えば営業マネージャー向けの週次）から始めて広げます。準委任で伴走し、設定の意図を社内に残します。請求・入金の数字を営業ダッシュボードに合わせたい場合は、Sync for freee でHubSpotの取引とfreeeをつなぐ方法があります。重複や表記ゆれの整理は Data Hub支援 で扱います。
分析の見方は 営業データ分析入門、予測の設定は 商談管理の基本と実践、レビュー会議の作り方は 週次パイプラインレビューとデータ品質ダッシュボード で解説しています。
よくある質問
CRMダッシュボードに表示するKPIはいくつが適切ですか？
指標の数を先に決めず、画面で行う判断から選びます。各KPIについて「変化したら何を確認し、誰が動くか」を説明できるか確かめます。異なる判断の指標が混在しているなら画面を分けます。同じ判断に必要な指標でも見つけにくいなら、集約値と詳細を分け、利用者が対応対象までたどれるか試します。指標を減らした後も判断が止まるなら、数ではなく定義や導線を見直します。
ダッシュボードの更新頻度はどう決めますか？
利用者が判断する時点で、必要なデータが更新されているかを基準にします。営業担当者が次の活動を決める画面なら、案件の記録が判断時点の状況を表しているか確認します。経営向けには会議で使う期間と集計の締め方を決めます。データの更新が間に合わない場合は、影響する判断を明らかにし、入力する場面か会議での使い方を見直します。
経営会議で使う数値の信頼性をどう高めますか？
まず次の項目を文書化し、関係部門で定義をそろえます。
- KPIの計算方法
- 対象レコード
- 計測期間
- データ元
差が出た場合は集計条件を比べ、その後に元データの入力状況を確認します。CRMの受注実績と会計上の売上で定義が異なるなら、名称を分けて表示し、それぞれの用途を明らかにします。差の理由が説明できる状態になってから、会議での判断に使います。
ExcelからCRMのダッシュボードへどう移行しますか？
現在のExcelで管理している指標と、その指標を使う判断を一覧にします。CRMで算出できる指標を選び、計算方法、対象範囲、更新時点をそろえて集計結果を照合します。差があれば、対象レコードや入力の不足を調べます。差の理由が説明でき、利用者がCRMの画面で同じ判断を行えるようになった指標から、会議資料や更新作業を切り替えます。
CRMにないデータもダッシュボードで確認できますか？
必要なデータがCRMにない場合、CRM内のレポートだけでは集計できないことがあります。まず判断に必要な項目とデータの所在を整理します。CRMに記録する場合は入力担当と更新方法を決め、別の分析手段で扱う場合は指標の定義と比較条件をそろえます。どちらの場合も、同じ指標名で異なる範囲の数値を比較しないようにします。
まとめ
CRMダッシュボード設計では、利用者が決めることからKPIを選び、定義と比較基準をそろえます。数値に差が出たら内訳と元データを確認し、対応する案件・顧客と担当者へ進める構成にします。
まずは定例会議で使っている指標を一つ選び、次の順序で確かめます。
- その指標で何を決めるかを明らかにし、計算方法、対象範囲、期間を関係者とそろえます。
- CRMのどの項目から算出するかを確認し、既存の集計との差や入力の不足を調べます。差の理由が説明できなければ、判断に使う範囲を明示して保留します。
- ダッシュボードを会議で使い、差の理由、次の行動、担当を記録します。判断できなかった箇所は定義、データ、表示方法の順に見直します。
CRMを活用した業務効率化やAIとの連携に関するご相談は、StartLinkまでお気軽にお問い合わせください。
あわせて読みたい
CRM導入の判断材料、営業活動の記録、運用ルールをさらに検討する際は、次の記事も参考にしてください。ダッシュボードで必要な数値が定まった後、入力方法や社内での説明を具体化できます。
記事の内容を、そのまま実務に落とし込みたい方向け
HubSpotゴールドパートナーのStartLinkが、HubSpot導入・AI活用・CRM整備・業務効率化までをまとめて支援しています。記事で気になったテーマを、そのまま相談ベースで整理できます。
次に読む
株式会社StartLinkは、事業推進に関わる「販売促進」「DXによる業務効率化（ERP/CRM/SFA/MAの導入）」などのご相談を受け付けております。 サービスのプランについてのご相談/お見積もり依頼や、ノウハウのお問い合わせについては、無料のお問い合わせページより、お気軽にご連絡くださいませ。
著者情報
