「事件は現場で起きている！」踊る営業組織で、これだけ押さえれば責任を取れる指標4選

部下「今月は600万円の見込みです！」

上司「絶対やれるんだな？」

部下「はい、やり切ります！」

上司に報告するためだけの見込み数字。報告した数字と、月末の着地がズレる。報告する側も聞く側も、内心では無駄だと思っている。それでも来週も同じ会議をやる。

私も新卒で証券会社に入ったとき、何の説明もなく「見込みを出せ」と言われて固まりました。何をどう積み上げたら600万円になるのか、誰も教えてくれない。営業力が強いと言われる会社でも、ここまで肌感で管理しているのかと驚いた記憶があります。

ただ、これは上司が怠けているという話ではありません。部内で数字の定義が揃っていない、指標同士の因果がつながっていない、そもそも計算に必要なデータが残っていない。 だから指標の数だけは多いのに、来月いくら立つのか部長自身にも読めない。構造の問題です。

この記事が、その構造を直すためのHow toになると幸いです。読み終わったときに、自社のCRMで何を直せばいいかまで分かる粒度にしています。

■ 第1部 土台 ─ 自社に適した指標を決める

自社の収益構造を式に分解

まず、収益予測というと、ツールを入れる話、ダッシュボードを整える話として語られがちです。実際にやることは、もっと素朴で、もっと厄介です。

自社の営業組織の成果が何の掛け算でできているのかを、一本の式に固定する。 これが最初で、指標選びはそのあとです。順番が逆になると、指標を増やせば増やすほど混乱する形になります。世の中の「営業指標30選」みたいな記事が実務で効かないのは、式になっていないまま指標だけ並べているからです。

営業部門が使う式は、下記になることが多いです。

売り上げ予測 ＝ SQL数 × ナーチャリング通過率 × クロージング率 × ARPU

この式の何がいいかというと、数字がズレたときの答えが4つしかないことです。600万円のはずが400万円で着地した。原因は必ず、入口が細かった（SQL）、育たなかった（通過率）、決め切れなかった（クロージング率）、単価が落ちた（ARPU）のどれか、あるいはその組み合わせの結果になります。

そして重要なのは、この式の項が、そのまま週次で見る指標になるということ。だから4つに絞って、式に入っていない数字は週次では見ないくらいの運用が必要です。

なお、これはWinning by Designのボウタイモデルでいう「左半分」だけを扱う式です。受注後のオンボーディング・定着・拡張まで入れると項が増えます。既存売上比率が高い事業なら、この式の外にもう一本、NRRのラインを立てる必要がありますが、今回は新規獲得のラインに絞ります。

重要：式より先に、データモデルを直そう

ここが実務で一番飛ばされるところです。

上の4項は、すべて「いつ、どの状態に入ったか」のタイムスタンプがないと計算できません。 ステージを上書きするだけのCRM運用だと、先週の状態が残らないので、通過率もリードタイムも後から復元できない。「集計しようとしたら過去が消えていた」は本当によくあります。

最低限、次のイベントに日時を残します。

• リード獲得日

• MQL到達日

• 営業へのハンドオフ日（SAL）

• SQL判定日（および判定者、差し戻しの場合は理由）

• 各商談ステージへの遷移日（入った日と出た日）

• 提案・見積提出日

• クローズ日（受注／失注／不決定の別と、理由コード）

理由コードは自由記述にしないこと。自由記述は集計できないので、結局読まれません。10個以内の選択式にして、「その他」の比率が2割を超えたら選択肢の設計を疑う、という運用にします。

計測方法：コホートで測るか、スナップショットで測るか

もう一つ、測定の技術論として避けて通れないのが母集団の測定定義です。

「今週の提案化率＝今週提案に進んだ件数 ÷ 今週のSQL件数」。この式は、分子と分母の母集団が違います。今週提案に進んだ案件の多くは、先月や先々月に入ったSQLです。リードの流入が増減した月に、転換率が実態と逆になるケースも発生します。これはバグではなく、定義の欠陥です。

正しい計測はコホート方式です。同じ月（または週）に発生したSQLを一つの集団として、その集団が何%提案に進み、何%受注したかを追跡する。ただしこの方式は、確定までにリードタイム分の時間がかかります。受注まで平均90日なら、あるコホートの最終値が出るのは3ヶ月後です。

実務では両方の視点を持つことで数字の実態把握を行います。

• スナップショット（期間内の分子÷分母）：週次の異常検知用。傾向が急に増加/減少したら気づける。

• コホート（集団の追跡）：月次の意思決定用。施策の良し悪しはこちらでしか判定できない。

週次会議でコホートの話をすると議論が止まるので、週次はスナップショットで異常を拾い、月次でコホートを確定させる。この二段構えにするのが現実的です。

■ 第2部 4指標の測定設計

さて、指標と取り方は決まりました。実際に実務でどのように動かすのかを決めていきましょう。

指標① SQL ─ リードの取り方が適切か

まず、階層とハンドオフを定義する

SQLを一枚岩で扱うと、マーケと営業の責任分界点がわからなくなってしままうので、最低でもこの3段に分けます。

MQL
意味：マーケ基準で有望と判定
責任：マーケ

SAL
意味：営業が受領し、着手を約束
責任：移管点

SQL
意味：営業が精査し、追う価値ありと確定
責任：営業

エンタープライズ寄りなら、SQLの先にSQO（Sales Qualified Opportunity）を置いて、商談として起票された時点を分けます。ここまで分けると、「マーケが悪いのか営業が悪いのか」の議論が、感情ではなく数字でできるようになると少なくとも敵対関係にはなりづらいです。

合格条件はフレームを選んで固定する

「温度感が高いリード」はSQLの定義になりません。人によって温度計が違うからです。フレームを一つ選んで、部長が条件を確定させます。

• BANT（予算・決裁権・必要性・時期）：SMB向け、商談サイクルが短い商材に向く。シンプルで浸透が速い。

• MEDDIC / MEDDPICC：エンタープライズ向け。指標・経済的決裁者・決裁プロセス・課題・チャンピオンまで見る。精度は高いが、全項目を毎週埋めさせると現場が死ぬ。

• CHAMP / GPCTBA&C&I：課題起点。インバウンド比率が高い組織と相性が良い。

重要なのは選ぶことより、SQL判定に使う項目を3つ以内に絞ることです。MEDDPICCを採用しても、SQLゲートで問うのは「経済的決裁者を特定できているか／次の関門が分かっているか／90日以内の検討意思があるか」の3つでいい。残りは商談進行の中で埋めます。

SQL差し戻し率を見る

一番効果的な分析がこれになります。営業がハンドオフを受けて却下した割合（SAL→SQLの否認率）。

• 差し戻しが高すぎる：マーケの定義が営業の実感とズレている

• 差し戻しがほぼゼロ：営業が惰性で全部受けている（＝ゲートが機能していない）

適正水準は商材で変わるので、他社ベンチマークより自社の3ヶ月移動平均をベースラインにして、そこからの乖離を見るほうが役に立ちます。そして必ず、差し戻し理由をコード化して残す。これがマーケへのフィードバックループの実体です。

スピードと在庫

• リードレスポンスタイム：獲得から初回接触までの時間。翌営業日対応が常態化しているなら、SQLの絶対数を増やす前に直すほうが早い。

• SQLエイジング：判定済みだが着手されていないSQLの滞留日数。在庫が積み上がっている状態で「リードが足りない」と言っているケースは非常に多いです。

• ソース別の受注率：同じSQL1件でも、流入元によって最終的な受注率が数倍違います。ソース別の受注率と単価まで見て初めて、SQL数を「重み付きで」読めます。

カバレッジは勝率の逆数で決める

パイプラインカバレッジは「3倍が定説」と言われますが、これは思考停止です。必要カバレッジ＝1 ÷ 勝率が原則。勝率25%の組織は4倍必要で、勝率40%の組織は2.5倍で足ります。他社の3倍をそのまま持ってくると、目標が過大にも過小にもなります。

指標② ナーチャリング通過率 ─ 取ったリードを育てられているか

定義：対象SQLコホートのうち、次の関門（提案・見積提出・具体検討）まで進んだ割合。分子と分母を必ず両方出す。

SQLを取れていても、そこから育たなければパイプライン総額は中身のない数字になります。ここは「取り方」ではなく「育て方」を見る場所です。

分母を出さない転換率は情報量ゼロ

「今週の提案化率は40%でした」だけでは、10件中4件なのか100件中40件なのかで打ち手が変わります。必ずこう書きます。

ここまで出れば、翌週の宿題が自動的に決まります。

ステージ滞留日数（Time in Stage）を持つ

通過率だけを見ていると、「進んでいない」と「まだ進んでいないだけ」の区別がつきません。ステージごとの滞留日数の中央値を出して、その1.5倍を超えた案件を自動でフラグする。これが週次のレビュー対象になります。

滞留の中央値は、そのままフォーキャストの精度にも効きます。「ステージBに45日いる案件」は、統計的にはもう死んでいることが多い。感触ではなく分布で判断できるようになります。

マルチスレッド率

Gartnerの調査では、複雑なB2Bソリューションの購買では意思決定者が6〜10人関与し、それぞれが独自に4〜5個の情報を集めているとされています。Forresterの2024年の調査では、平均13名の関与者という数字も出ています。

つまり、接点が1名しかない案件は、確度以前にリスク案件です。チャンピオンが異動した瞬間に消えます。

指標としては「案件あたりの有効接点数（直近30日以内にやり取りのある人数）」を出して、1名の案件の比率を見ます。これが半分を超えているチームは、通過率を上げようとしてトーク改善に走っても効きません。接点を増やすほうが先です。

リサイクル導線がないと、通過率は必ず操作される

通過率を評価対象にすると、現場は分母を減らす方向に動きます。「これはSQLじゃないことにしよう」が起きる。

これを防ぐのは精神論ではなく仕組みです。育たなかったSQLを、マーケのナーチャリングに戻す導線（リサイクル／クローズドロスト・ナーチャー）を作っておく。戻す先があれば、現場は正直に「今は無理」と判定できます。戻した先で再獲得された案件の比率も、立派なRevOps指標です。

指標③ クロージング率 ─ その前に、確度の定義を決める

クロージング率を数える前に、決めることが3つあります。分母、ステージ定義、重み付けの根拠です。ここを飛ばすと、この指標は「測っている風の数字」になります。

分母に「不決定」を入れるか

一番の論点はこれです。

勝率A ＝ 受注 ÷（受注 ＋ 失注）
勝率B ＝ 受注 ÷ 全クローズ案件（不決定・立ち消えを含む）

多くの組織はAを使っています。ところが実務上、最大の敵は競合ではありません。JOLT Effectの研究では、250万件の商談会話を分析した結果、失注の40〜60%は競合に負けたのではなく顧客の意思決定不全（現状維持）によるものだとされています。

Aだけを見ている組織は、この最大の失注要因を分母から除外していることになります。Aは営業力の指標、Bはレベニューの指標。 読みに使うのはBです。両方出して、AとBの乖離幅そのものを「立ち消え率」として監視するのが実務的です。

ステージは「出口条件」で定義する

確度A・B・Cを営業の感触で付けている限り、この指標は動きません。同じAでも人によって中身が違うからです。

ステージはExit Criteria（そのステージを出るために満たすべき条件）で定義します。しかも条件は、営業側の行動ではなく顧客側で観測できた事実で書きます。

初期
出口条件（顧客側の事実）：課題と予算枠を、顧客の言葉で確認できた

検証
出口条件（顧客側の事実）：経済的決裁者と直接接触した／評価基準を提示された

提案
出口条件（顧客側の事実）：正式な見積を提出し、比較検討の土俵に乗った

最終
出口条件（顧客側の事実）：稟議・調達プロセスに上程され、決裁日が判明した

「顧客側の事実」に統一するのがポイントです。「提案書を送った」は営業の行動なので条件になりません。「先方が社内共有すると明言した」なら条件になります。

重みは主観%ではなく実績勝率で置く

各ステージの確度%は、営業の申告ではなく、そのステージに到達した案件が過去に実際どれだけ受注したか（ヒストリカル勝率）で置きます。四半期ごとに再計算します。

そのうえで、フォーキャストカテゴリ（Commit / Best Case / Pipeline / Omitted）は確度とは別レイヤーで持ちます。 確度は案件の客観的な状態、カテゴリは営業の宣言です。この2つを一つのフィールドで兼用すると、宣言が状態を汚染して、加重パイプラインが機能しなくなります。

予測精度そのものを指標にする

「読める組織」を名乗るなら、読みが当たったかを記録するのが本筋です。

• フォーキャスト誤差：月初の読みと着地の乖離率。±10%以内が入口、±5%を目指す。

• スリページ率：当月Commitのうち、翌月以降にずれ込んだ金額の比率。ここが常時20%を超えるなら、Commitの定義が甘い。

この2つを毎月記録し始めると、営業の申告そのものが変わります。当たり外れが可視化されるからです。

指標④ ARPU × n数 ─ 単価と件数はセットで見る

まず単位を確定させる

ARPUという言葉は便利ですが、B2Bでは曖昧です。何を数えているか先に決めます。

• ACV（年間契約金額）：サブスク型の標準。複数年契約は年換算する。

• TCV（契約総額）：複数年の総額。ACVと混ぜると単価が跳ねる。

• ARPA（顧客あたり平均収益）：既存拡大まで含めた実態を見るとき。

• 初回受注単価：単発・プロジェクト型商材ならこれ。

複数年契約とオプションの扱いを決めていないチームは、ほぼ確実に単価がブレます。 平均が動いたときに、実態が動いたのか数え方が動いたのか分からなくなるからです。

平均ではなく分布で見る

平均単価は、大型1件で簡単に壊れます。必ず中央値と分位（P25 / P50 / P75）を併記します。

平均が上がって中央値が動いていない月は、大型1件で持ち上がっただけ。この状態で「単価が改善した」と報告すると、翌月に必ず落ちます。分布を持っていれば、その1件を除いた地力が見えます。

値引き率とプライスリアライゼーション

提示価格に対して、実際いくらで受注できたか。 これを案件ごとに残すと、いろいろなことが見えます。

• 勝率は悪くないのにARPUだけ落ちている → 営業が価格で勝ちにいっている

• 特定の担当だけ値引き率が高い → 交渉スキルではなく、ゲート設計の問題（Deal Deskの出番）

• 期末に値引き率が跳ねる → 期の切り方がインセンティブを歪めている

値引きは「良くないこと」ではなく、測っていないことが問題です。承認閾値（この率を超えたら部長承認）を決めるだけでも、分布は締まります。

ミックスとn数

同じレベニューでも、中身が違えば来月が違います。

• 新規／既存の比率

• セグメント別（従業員規模・業種）の構成

• プラン・商材別の構成

n数はこのミックスと合わせて見ます。「件数横ばい・単価横ばい」でも、大型セグメントが減って小型が増えていれば、来月以降にリードタイムと勝率が両方変わります。

既存拡大のラインを持っているなら、ここからNRR / GRRにつながります。さらにその先にLTV/CAC・CACペイバック期間があり、ここまで来ると経営会議の言語になります。ただし部門の週次に持ち込む数字ではありません。四半期の話です。

■ 第3部 運用 ─ どの粒度で、いつ見るか

指標を決めても、見る頻度を間違えると運用がうまく行きません。粒度を3つに分けます。

週次（部長が5分で確認する）

式に代入して、読みを更新するだけです。

• SQL：先週比 −3件。新規と在庫を分けて表示。→ 今週SQL判定まで持っていくリストを決める

• 通過率（スナップショット）：40% → 28%。→ 乗らなかったSQLの理由を3件だけ回収

• クローズ：確度B帯の滞留が中央値の1.5倍を超えた案件が4件。→ 部長が2件に同席

• ARPU × n数：ARPU −8%、n数横ばい、値引き率 +5pt。→ 値引きの発生箇所を1件確認

異常が出た項だけ深掘りする。全部を毎週振りからないのがコツです。

月次（数字の定義や前提のズレの確認）

• コホートの確定（先月SQLの到達点）

• フォーキャスト誤差とスリページ率の記録

• 差し戻し率とその理由分布のマーケ共有

• 単価の中央値・分位の更新

四半期（設計を直す）

• ステージ別ヒストリカル勝率の再計算

• Exit Criteriaの見直し（形骸化した条件を捨てる）

• ICP・スコアリングモデルの再学習

• 必要カバレッジ倍率の再設定

■ 第4部 わざと見ない指標

追わないものも、はっきり決めます。
追うと現場が活動数競争になり、式から余計に離れてしまいます。

• 架電数・訪問数だけを見ること（先行指標としては有効だが、レベニューの読みには使わない）

• パイプライン総額だけを見ること（中身のSQL・通過率・確度を見ない総額は結果の影）

• CRM活動履歴の件数

• MEDDPICC 8項目を毎週、全案件で埋めた率（入力率は指標ではなく作業量です）

• 他社ベンチマークとの比較（自社の3ヶ月移動平均のほうが100倍役に立ちます）

総額は結果の影です。影だけを追っていると、着地とのズレは止まりません。式の4項は、影の手前で手が打てます。

■ 第5部 私がつまずいた3点

① 報告の圧力に負け、実務よりも見栄え重視の数字会議に戻してしまった。 上に説明しやすい数字を増やし、着地とズレる数字を毎週現場に課してしまう。報告する側も聞く側も無駄だと分かっているのに止められない状況に。そこから抜けられたのは、式の4項だけを並べたシートに切り替えて、レベニューの報告を行ったことです。

② 確度の定義を後回しにして、クロージング率を先に数えた。 見込み数字が毎週ごとにかなり変動してしまう原因になりました。判定基準が営業ごとに違ったからです。Exit Criteriaを顧客側の事実で書き直したら、翌月から読みが安定しました。定義が先、計測は後はかなり重要な教訓です。

③ タイムスタンプを残していなかった。 半年分を振り返って通過率を出そうとしたら、ステージが上書きされていて過去分が復元できませんでした。指標設計より先に、イベントログの設計が重要です。ここだけは、後から取り返しがつきません。

■ 第6部 3人以上のチームで崩れる境界線

ここまでの設計は、部長またはRevOps担当が集計する前提です。4指標の入力を現場に押し付けると崩れます。 現場は○×と件数を、良く見える方向に書き換えます。悪意ではなく、評価されるからです。

分担はこうします。

• 現場が入力するもの：顧客側で観測できた事実（会った人、提出した見積、言われた言葉）と、進まなかった理由コード

• 部長・RevOpsが計算するもの：4指標すべて

• 誰も入力しないもの：確度%（ステージから自動計算する）

確度を手入力させない、というのが最大のポイントです。ステージの出口条件を満たしたかどうかだけ現場が答え、確度は実績勝率から自動で決まる。この構造にすると、期末の楽観バイアスが構造的に入り込めなくなります。

■ 自己チェック

• ステージ遷移のタイムスタンプが残っていない（コホート分析ができない）

• 転換率をスナップショットだけで見ている

• 勝率の分母から不決定・立ち消えを外している

• 確度A/B/Cを営業の感触で手入力している

• ステージ確率が主観%で、実績勝率と紐づいていない

• ARPUを平均だけで見ていて、中央値と分位を持っていない

• 値引き率を案件単位で記録していない

• フォーキャスト誤差を毎月記録していない

• SQLの差し戻し率をマーケに返していない

3つ以上あてはまるなら、指標を足す前に、式とデータモデルを固定するところからです。

3ヶ月後に変わるのは、週次の長さと、来月の着地の予測です。報告用の数字会議が短くなるのは、その結果でしかありません。

■ 15分相談

レベニューの式の立て方、イベントログの設計、コホートとスナップショットの二段構え、Exit Criteriaの書き方、そして現場に渡す入力の型。営業の人数とCRMの状況に合わせて一緒に設計します。

https://forms.gle/Exsm4gAyVNJKfVJz6

*参考：Gartner（B2B購買の意思決定者数）、Forrester 2024（購買関与者数）、Matthew Dixon & Ted McKenna『The JOLT Effect』（不決定による失注比率）、Winning by Design（ボウタイモデル）*