売上目標から必要なリード・商談・受注を逆算する売上モデルの作り方

売上目標から必要なリード・商談・受注を逆算する売上モデルの作り方

この記事の要約

経営会議で「今期の売上目標」だけが降りてきて、マーケティングと営業がそれぞれ独自の前提で必要な行動量を見積もり、数字が噛み合わない——

この記事は、この状態を解消するための逆算モデルの作り方を整理します。
売上目標を、平均受注単価・商談→受注率・リード→商談化率という3つの比率で割り戻すと、必要な受注数・商談数・リード数が計算できます。ただし式そのものは単純な算数であり、値打ちが出るのは「売上」「受注」「商談」「リード」の定義、対象期間、集計単位、責任者を先に固定したときだけです。

本記事では逆算式の使い方、先に固定する前提、仮想計算例、運用時の確認事項とチェックリストを順に解説します。数値例はすべて仮想例であり、業界平均や達成保証ではありません。読後には、自社の実績値に置き換えて再計算できる計算表の骨格が手に入ります。

この記事でわかること

  • 売上目標から必要な受注数・商談数・リード数を逆算する基本式と、ステージが増えた場合の連鎖式
  • 逆算式を使う前に固定しておくべき「売上・受注・商談・リード・期間・責任者」の定義
  • 仮想数値を使った逆算の具体的な計算手順
  • 営業・マーケティング間で数字が食い違うときに確認する原因と防ぎ方
  • 売上モデルを運用に落とし込む際のチェックリスト

はじめに

四半期の頭、経営会議で「今期の売上目標は1.2億円」という数字だけが共有され、あとはマーケティングと営業それぞれに「よろしく」と投げられる——

そんな場面に心当たりはないでしょうか。
マーケティングは過去の感覚でリード数を積み増し、営業は自分たちの手応えで商談件数を見積もる。両者の前提がバラバラなまま並走すると、月末になって「リードは目標達成したのに受注が足りない」という食い違いを確認する場面があります。

売上目標を行動量へ変換する共通の計算式と定義がないことは、その差異を確認すべき要因の一つです。本記事では、この変換作業を仕組み化する考え方を解説します。

結論として押さえる逆算式と確認順

売上目標から必要な行動量を導く逆算式は

「目標売上 ÷ 平均受注単価 = 必要受注数」
「必要受注数 ÷ 商談→受注率 = 必要商談数」
「必要商談数 ÷ リード→商談化率 = 必要リード数」

という3段階の割り算で表せます。
この式は、定義済みの入力値から必要量を試算する算術モデルです。
問題は式の正しさではなく、式に入れる数字の「意味」がチーム内で揃っているかどうかにあります。

この記事で確認する順序は次の5つです。

  1. 逆算式そのものの構造を理解する
  2. 売上・受注・商談・リードという4つの言葉の定義を先に固定する
  3. 期間とコホート(いつ発生した何を数えるか)を揃える
  4. 責任者(誰が定義を決め、誰が数字を出すか)を明確にする
  5. 仮想計算例で式の読み方を確認し、自社の数字に置き換える準備をする

①の式だけを先に共有すると、②〜④が曖昧なまま計算を始めることになります。式は手段であり、定義を先に置くことで、後の議論で確認すべき前提をそろえやすくなります。

商談不足の原因を先に切り分ける

売上モデルに入れる数字を決める前に、そもそも商談不足がどの段階で起きているかを確認したい場合は、次の記事も参考になります。

BtoBの商談が増えない:最初に切り分ける7つのボトルネック
BtoBの商談不足に悩むCEO・営業マーケ責任者向けに、集客量・ICP・商談化・営業対応・計測の5接続点から原因を切り分ける7つの診断ポイントを解説します。
商談化率が低い原因:見込み顧客の評価、営業評価、初回接触を分解して改善する
商談化率が低い原因を見込み顧客の評価・営業評価・初回接触の3工程に分解し、確認順序と改善優先度の決め方をマーケ・Sales Ops向けに解説します。

売上目標から受注・商談・リードを逆算する式

基本式:目標売上を3つの比率で割り戻す

基本式は次の3つのステップで構成されます。

ステップ式意味
①必要受注数 = 目標売上 ÷ 平均受注単価目標を達成するために必要な受注件数(端数は切り上げ)
②必要商談数 = 必要受注数 ÷ 商談→受注率受注数を生むために必要な商談件数
③必要リード数 = 必要商談数 ÷ リード→商談化率商談数を生むために必要なリード件数

ここで使う「商談→受注率」と「リード→商談化率」は、現在進行中の案件残高ではなく、すでに結果が確定した過去のコホート(同じ時期に流入した集団)から算出します。進行中の案件を分母に含む率は、確定済みコホートから算出した転換率と同じ意味では扱えません。

ステージが増える場合の連鎖式

自社の営業プロセスに「初回商談」「提案」「最終交渉」のように複数ステージがある場合は、隣接するステージ間の転換率をすべて掛け合わせてから割り戻します。

必要リード数 = 必要受注数 ÷ (p1 × p2 × ... × pn)

ここで注意したいのは、途中の各ステージで数値を丸めてしまうと、最終的な必要リード数が実際より過大に出ることがあるという点です。

計算表を作るときは、各ステージの未丸め値(小数点以下も含む値)を保持しておき、最後の必要件数だけを切り上げるようにすると、無駄な行動量の見積もりを避けられます。

逆算する前にそろえる定義と運用前提

式は誰が計算しても同じ答えが出ますが、「売上」「受注」「商談」「リード」という言葉の定義が部門ごとに違えば、同じ式を使っても答えは一致しません。

**逆算モデルを作る前に、四つの言葉の定義に加え、期間・コホートと責任者を一文で言い切れる状態にします。

売上・受注・商談・リードをどう定義するか

  • 売上目標:
    -「対象四半期にCloseした新規受注額」のように、売上の種類(新規かアップセルか)、通貨、対象顧客、計上またはClose基準日までを一文で定義します。新規受注額と会計上の売上、税抜と税込を無定義で混在させないことが肝心です。
  • 受注:
    -成功を表す最終ステージ(いわゆる契約確定の段階)に到達した一意の案件数として定義します。契約署名、請求開始、売上認識のどれを「受注」とするかは会社によって異なるため、決め打ちせず自社で確認します。
  • 商談:
    -「営業側が受諾した案件」か「CRM上のOpportunity」かのどちらか一方を採用し、その到達条件と集計単位を明記します。初回面談の予約と面談実施、案件化を同じ件数として扱ってはいけません。
  • リード:
    -連絡先・会社・購買グループのどれを一件と数えるかを決め、生成条件と適格化条件(いつリードと呼べる状態になるか)を定義します。商談と単位が違う場合(例:1案件に複数の連絡先が紐づく)は、変換ルールを記録しておきます。

HubSpotではLifecycle stageを連絡先または会社のマーケティング・営業プロセス上の位置として扱い、SalesforceではOpportunityを進行中の商取引としてステージで管理します。

両製品では自社のプロセスに合わせたステージの設計・カスタマイズが可能です。[S-01] [S-02] [S-03] したがって、ツールの既定値を自社の定義としてそのまま採用するのではなく、自社のプロセスに即して到達条件を書き下ろします。

期間とコホートをどう揃えるか

もう一つ確認するのが、期間の基準です。次の二つは、同じ指標として混ぜられません。

  • 「期間内にClosed Wonとなった案件数」(過去に確定した実績)
  • 「現在Opportunityのステージにある案件数」(いま進行中の残高)

この二つは、対象時点も集計条件も異なります。HubSpotの広告分析でも、現在のLifecycle stage件数と、Closed Won・関連付け・Close dateなどの条件を満たすDeals件数は別の条件で集計されます。[S-04]

目標の受注期間、各ステージへの到達日を集計する期間、対象を投入したコホート、データを確定させた日付は、それぞれ別の欄として管理します。

転換率は結果が十分に確定したコホートで算出します。ステージ定義やCRMの入力ルールを変更した期間は、変更前後の影響を分離できない限り、同じ転換率として比較せず「未確認」として扱います。

必要リード数が分かっても、目標四半期の初日にリードを作ればよいとは限りません。目標の受注時点から、自社で採用した営業サイクルまたはコホート観察期間をさかのぼり、リード創出の開始時点を置きます。

日数は企業ごとの実績が未確認のため、本記事では仮定せず、受注目標期間とリード投入期間を別欄で管理します。

責任者をどう固定するか

定義と期間が決まっても、誰が数字を確定させ、誰が差異の最終判断を下すのかが曖昧では、数値差異を確認する窓口を持ちにくくなります。役割ごとの責任分担を、実名または役職名で表にします。

役割主な責任
CEO/CRO目標売上・売上範囲の承認
Marketingリードの定義・創出条件の管理
Sales商談の受諾・ステージ更新の運用
RevOpsまたはData担当定義書の維持、集計、欠損値の監査

役職名だけでなく、定義変更や数値差異が出たときの最終決定者も置きます。表には更新頻度と、差異が出たときの決定者まで書き込みます。

部門間で数字をそろえるための関連記事

売上モデルを部門共通の運用にするには、計算式だけでなく、マーケティング・営業・RevOpsの役割と定義をそろえる必要があります。

マーケティングと営業が連携できない5つの構造問題
マーケ・営業の連携不全を、定義・責任・データ・プロセス・会議体の5構造問題に分解。CMO・CROが対立の原因を仕組みとして整理し、優先順位をつけて改善するための視点を解説。
RevOpsとは何か:営業企画・マーケティング企画との違いと導入条件
RevOpsの定義を営業企画・マーケティング企画と比較して整理。担当範囲、横断課題、導入条件、職種採用と既存体制どちらで始めるべきかを解説します。

仮想計算例で式の読み方を確認する

ここからは、あくまで式の「読み方」を確認するための仮想例です。業界平均でも実績値でもなく、あくまで説明用の数値であることを前提に読み進めてください。

対象期間を「四半期」、売上範囲を「同一の新規受注売上」、商談を「定義済みの営業受諾案件」、リードを「定義済みの対象」と仮定し、次の仮想入力値を使います。

入力項目仮想値
目標売上(R)12,000,000円
平均受注単価(A)3,000,000円
商談→受注率25%
リード→商談化率20%

この仮想値を基本式に当てはめると、計算は次の順で進みます。

  1. 必要受注数 = 12,000,000 ÷ 3,000,000 = 4件
  2. 必要商談数 = 4 ÷ 0.25 = 16件
  3. 必要リード数 = 16 ÷ 0.20 = 80件

つまりこの仮想シナリオでは、四半期に80件のリードを獲得し、そこから16件の商談を作り、4件の受注に結びつける、という行動量の見取り図が描けます。

ただし、この「80件」という数字は、平均受注単価や転換率が読者企業の実績と一致して初めて意味を持ちます。実際に使うときは、この仮想値をすべて自社の定義済み実績値に置き換えて再計算してください。

転換率が未確認であれば、必要リード数もまた「未確認」として扱い、「この率なら必ず達成できる」といった言い切りをしないことが大切です。

売上モデルで確認する4つの不整合とチェックリスト

売上モデルでは、式の前に定義の不一致を確認します。次の四つは、計算表で確認する不整合です。

  • 分母のすり替え:商談→受注率を計算するときに、進行中のパイプライン件数を分母に使うと、確定済みコホートの転換率と比較できない率になります。
  • 期間の混在:今月時点の残高と、過去に確定した実績を同じ「月次転換率」として扱ってしまう。
  • 定義変更の見落とし:CRMのステージ定義や入力ルールを変えた前後で、転換率の連続性を確認せずに比較してしまう。
  • 単位のねじれ:リードを「連絡先単位」で数える一方、商談を「案件単位」で数えているのに、変換ルールを決めないまま同じ式に当てはめてしまう。1つの案件に複数の連絡先が紐づく場合、その値は「連絡先→案件」の率となり、会社・購買グループ単位の率とは比較できません。

これらを防ぐために、計算表を作る段階で以下を確認しておくと安心です。

運用前チェックリスト

  • 売上目標の種類・通貨・対象期間・計上基準日を一文で書けるか
  • 受注・商談・リードの到達条件と集計単位をそれぞれ定義したか
  • 転換率は「結果が確定したコホート」から算出しているか(進行中の残高を使っていないか)
  • 各指標の対象期間と基準日(到達日またはClose date)を分けて記録しているか
  • 定義・集計・監査の責任者を役職名だけでなく決定権者まで明記したか
  • 仮想例と実績値を混同せず、実績値へ置き換えて再計算する運用になっているか

このチェックリストは、逆算式を経営目標から部門共通の行動KPIを試算する道具として扱うための前提です。式を先に共有するのではなく、定義を固定してから式を回す順で確認します。

CRMとデータの状態も確認する

実績値を使って逆算モデルを運用する段階では、CRMの入力定着とデータ品質が計算結果の信頼性を左右します。関連する確認方法は次の記事で整理しています。

実績値を使った運用では、CRMの入力定着とデータ品質が計算結果の信頼性を左右します。次の2記事で確認方法を整理しています。

HubSpot/Salesforceのデータ品質が悪化する原因と、最初の是正順序
HubSpot/Salesforceのデータ品質悪化を入力・定義・運用・重複・連携の原因に分解し、Sales Ops/IT向けに最初の是正順序と判断基準を解説します。
HubSpotを売上を生む仕組みとして設計し直す:診断から90日まで
HubSpot責任者・CMO向けに、顧客名簿化したHubSpotを定義・データ・運用・レポートの4視点で診断し、90日の実行順序で再設計する考え方を解説します。

まとめ

売上目標から必要なリード・商談・受注を逆算する式自体は、目標売上を平均受注単価・商談→受注率・リード→商談化率で順に割り戻す算術です。

しかしその答えを部門横断の行動KPIとして試算するには、売上・受注・商談・リードの定義、対象期間とコホート、責任者という前提を先に固定します。仮想計算例は式の読み方を確認するための教材です。実際の運用では自社の定義済み実績値に置き換えて再計算し、転換率が未確認の項目は「未確認」として扱います。

Q&A

Q
商談→受注率やリード→商談化率は、どの期間のデータを使えば良いのですか?
A

現在進行中の案件残高ではなく、結果が受注または失注として確定した過去のコホート(同じ時期に流入した集団)から算出します。進行中の案件を分母に含む率は、確定済みコホートの転換率と同じ意味では扱いません。

Q
業界平均の転換率がわからない場合、必要リード数はどう見積もれば良いですか?
A

自社の転換率が未確認の場合は、外部の平均値を当てはめず、必要リード数も「未確認」として扱います。まずは自社のCRMまたは記録システムから過去の確定コホートのデータを集め、実績に基づく転換率を算出します。

Q
マーケティングと営業で「商談」の定義が違う場合、どちらに合わせれば良いですか?
A

どちらが正しいかを決める前に、まず双方が「商談」と呼んでいる状態の到達条件(初回面談実施なのか、CRM上のOpportunity化なのかなど)を洗い出し、一つの定義に統一することが先決です。統一した定義のもとで、リード→商談化率と商談→受注率の分子・分母を揃えて計算します。

専門用語解説

  • リード:本記事では、定義済みの対象として数える連絡先・会社・購買グループのいずれか
  • 商談:本記事では、定義済みの営業受諾案件またはCRM上のOpportunityのいずれか
  • コホート:同じ時期や条件でグループ化された集団の単位
  • 転換率:ある段階から次の段階へ進んだ割合を示す数値
  • CRM:本記事では、リード・商談の定義、到達条件、集計値を記録・確認するシステム
  • Opportunity:Salesforceでステージを通じて管理する進行中の商取引 [S-02]
  • RevOps:本記事では、定義書の維持、集計、欠損値の監査を担う役割
この記事の執筆・監修者
Kazuhiko Nishikawa

GTM Engineer / BizOps / RevOps。Web制作・UI/UXを10年経験。BtoB・BtoCマーケティング、CRM/MA設計、プロダクト開発、Webディレクション/デザイン、CSを横断した事業改善に従事。外国人材ベンチャーでBtoBマーケティングを0→1で立ち上げ、リード獲得と営業支援を中心に収益プロセスを改善。HubSpot、AI、CRM、データを活用した業務設計・自動化・分析・制作を経験。

本記事は、BtoBマーケティング、HubSpotの導入・運用、CRM設計、営業・マーケティング連携に携わってきた実務経験をもとに、現場で実際に感じた課題や判断、起こりうるパターンを整理・想定し、AIライティングにて執筆・編集、監修者によるリライトを行なっています。
CROKPI設計営業戦略売上モデル逆算思考