なぜ「良いリード」が増えているのに、
受注が増えないのか

はじめに：リード獲得と受注は、別の問題

リード数は増えている。CPAも改善している。広告も回り、ホワイトペーパーもダウンロードされている。それなのに、受注が増えない——この状況は、多くのBtoB企業で起きています。こうした場面で典型的に起きるのが、部門間の対立です。マーケティング側は「リードは渡している」と言い、営業側は「質が悪い」と言う。双方に言い分があり、どちらも間違っていません。しかし問題の本質はそこにはありません。

リード数が増えることと、売上が増えることは同義ではない

資料ダウンロード、セミナー申込、ホワイトペーパー、問い合わせが増えていても、その後の商談化・受注・継続につながらなければ、売上にはなりません。ところが多くの企業では、マーケティングKPIが「リード獲得数」で止まっています。商談化率もWin Rateも見ていない。施策からARRまでのデータがつながっていない。この状態では、リードがいくら増えても売上は動きません。

リードを増やすことと、収益につながる流れを作ることは、まったく別の設計課題です。この二つを混同しているうちは、「良いリードが増えているのに受注が増えない」という状況が続きます。

「良いリード」の定義が、部門ごとに違う

マーケティングはフォーム送信・MAスコア・資料ダウンロード・ウェビナー参加を見ています。一方、営業が見ているのは予算・緊急度・決裁者の有無・導入タイミングです。つまりそもそも「良いリード」の意味が違うため、どんなに施策を改善してもすれ違いは解消されません。

営業が不満を持つ理由は単純です。営業は「受注できるか」という基準でリードを評価しているからです。情報収集のみ・予算なし・導入時期未定というリードが多く流れてくると、「また質の低いリードだ」と感じます。一方、マーケティング側からすれば、CPA改善・CV数増加・MQL増加は正当な成果です。問題は、双方が別のKPIを見ており、共通のRevenue KPIが存在しないことにあります。

リード獲得だけを最適化すると、組織は壊れる

マーケティングが「リード数」だけを追い始めると、組織全体に歪みが生じます。以下の4つのパターンは、この状況で典型的に起きます。

本当の問題は「リード」ではなく「Revenue Flow」

見るべきなのはリード数やMQL数ではありません。重要なのは商談化率・SQL転換率・Win Rate・ARR・LTV・Payback Periodです。「どれだけリードを取ったか」ではなく、「どれだけ収益につながったか」を見る必要があります。これをRevenue Flow（収益の流れ）として設計することが、問題解決の出発点です。

リード獲得が受注につながっている企業には、4つの共通点があります。

Revenue Architectureという考え方

このように、リード獲得問題の本質はマーケティング単体では解決できません。必要なのはRevenue Architecture（レベニューアーキテクチャ）——営業・マーケティング・CS・CRM・KPI・データを「収益につながる一つの流れ」として設計する考え方です。KPI・SQL定義・CRM・Revenue Data Flow・RevOps・営業プロセスを横断した構造問題として捉え直すことで、初めて解決の糸口が見えます。

多くの企業はHubSpotやMarketoを導入すれば解決すると考えます。しかしMQL定義・SQL定義・商談条件・Revenue KPIが未設計であれば、MAは「大量送信ツール」になるだけです。ツールより先に設計が必要なのです。

Revenue Architectureを整えると、何が変わるのか

日本企業でこの問題が起きやすい理由

日本企業では部門分断・KPI分断・Excel文化・属人営業が根強く残っています。そのためマーケティングが「上流だけ」の役割に閉じやすく、CSや営業との接続が設計されないまま組織が動き続けます。Revenue Operationsは本来、マーケからCSまでつながるべきものです。しかし日本の商習慣や組織文化にそのまま欧米型のフレームワークを当てはめても機能しないことが多い。必要なのは、日本企業の実情に合ったRevenue Architectureの設計です。

Consilegyの考え方

Consilegyでは、マーケティング改善を広告改善の問題として捉えていません。本質はRevenue Architecture・RevOps・Revenue KPI・CRM・SQL定義・Revenue Data Flowにあります。HubSpot・Salesforce・Marketo・BI・Slackなどを横断しながら、「リード獲得」ではなく「受注につながるRevenue Flow」を設計します。目的はリードを増やすことではなく、収益につながる構造を作ることです。

まとめ：リード数ではなく、Revenue Flowを設計する

「良いリード」が増えているのに受注が増えない原因は、マーケティング施策の問題ではありません。多くの場合、KPI分断・SQL定義不足・Revenue Data Flow未設計・Revenue Architecture不足が根本原因です。だからこそ必要なのは、リード数の改善ではなく、施策から受注までの構造を設計することです。売上はマーケティング単体ではなく、Revenue Architecture全体で決まります。