数字が部署ごとに合わない

先月報告した商談化率が、今月見たら変わっていた

公開 2026年8月25日

先月の営業会議で報告した商談化率を、今月まったく同じ条件で開いたら、数字が変わっていました。ツールの不具合ではありません。

レポートは過去を保存していません。開いたその瞬間のデータで、過去を計算し直しています。だから直す先はレポートではなく、締めの工程です。

商談化率が毎月ずれるのは、ツールの不具合ではない

CRMを入れて半年ほどのB2B企業で、月次の営業会議に流入経路別の商談化率を出していました。あるとき、前月に報告した数字と、今月同じ期間で開いた数字が数ポイントずれていることに気づきます。

差が小さいので会議では誰も指摘しません。ただ、報告する側は毎回「先月と違いますが」と前置きを用意することになり、数字そのものが信用されなくなっていきました。指標が動いているのではなく、指標を測る土台が動いていた状態です。

背景には、入力が締めに間に合っていないという日本の営業現場の実態があります。キーウォーカーが2025年10月8日から10日にPRIZMA経由のインターネット調査で行った n=1,034（SFA・CRM・BIツール導入済み企業の営業部門の現場担当者と管理職）では、営業活動後に「毎回すぐ入力している」は40.2%。残りは1日の終わりにまとめて32.2%、週に数回まとめて11.2%、月に数回まとめて3.9%、入力自体ができていない・入力漏れが多いが12.5%でした。即時入力は4割で、6割は後追いです。BIツールの導入支援会社による自社調査で、モニター調査である点は割り引いて読む必要がありますが、後追い入力が例外ではないことは押さえておく価値があります。

直したのはレポートではなく、数字を確定させる締めの工程

原因を3つに分けました。

月初に集計した時点で、まだ入力されていない活動がある。 その後に追加されても作成日は先月のまま入るので、先月の分母と分子が後から増えます。
集計に使う日付が、人の手で書き換えられる項目だったこと。 HubSpotの公式ドキュメント「Funnel (legacy) report types」（最終更新2025年11月19日）には、従来のファネルレポートが createdate プロパティの値を使い、この項目は利用者が手動で変更できると明記されています。移行時の一括更新やデータ整理でここを触れば、過去の集計対象が動きます。
重複レコードの統合。 同じ資料に、レコードの統合によってプロパティが並べ替えられ、その結果としてファネルに現れる連絡先がある、と書かれています。展示会や問い合わせで同じ人が複数回登録される限り、統合は起き続けます。

判断は、レポートを直さないことでした。締め日を月初第3営業日に固定し、その時点の数字を別の場所に保存して、会議に出すのは保存した値だけにする。集計の起点は、担当者が編集できないタイムスタンプ側に寄せる。この3つです。

採らなかったのは、レポートの条件を精緻にしていく案です。条件をいくら足しても、レポートが実行時点のデータで計算する仕組みは変わりません。変動は減らせても消えません。

数字を動かさなくしたのではなく、動かす数字と動かさない数字を分けた

数字が動かなくなったわけではありません。動かす数字と動かさない数字が分かれました。会議に出すのは保存値、日々の追いかけは生の値です。締め時点と現在の乖離が大きい月は、それ自体が入力遅れの警報になりました。

効かなかったのは、入力を早めるよう呼びかけることです。同じキーウォーカー調査で、入力の動機付けになる要素の1位は「入力の目的やデータの使い道が明確」54.8%でした。用途を見せずに速度だけ求めても動きません。

もうひとつ。同調査では、ダッシュボードの用途として管理職の58.2%が「営業会議の数値確認」を挙げた一方、「次のアクションの検討」は15.4%にとどまりました。確認するだけの数字は、変わっても誰も気づきません。気づかないまま意思決定に使われるほうが、数ポイントのずれより高くつきます。

レポートは過去を保存していません。毎回いまのデータで過去を計算し直します。確定させたい数字は、締め日を決めて人の手で保存します。

今週やることは1つです。先月の会議資料に載せた数字を、いまレポートで開いて突き合わせてください。合っていなければ、締めの工程がまだ存在していません。