マーケティングは「良いリードを送っている」と言い、営業は「質が低い」と言う。これは日本のBtoB企業で非常によく起きています。MA導入・インサイドセールス立ち上げ・MQL運用開始・CRM本格活用のタイミングで、営業とマーケティングの摩擦が急激に増えます。「SQLの定義って何?」「営業が追ってくれない」「商談化率が低すぎる」「マーケと営業で数字が違う」といった言葉が会議に出始めます。
しかしこれはコミュニケーション不足ではありません。本当の原因は、収益につながる顧客の定義が構造として設計されていないことにあります。MQLとSQLの分断は、収益の流れが整備されていない組織では必ず起きます。マーケティングと営業は本来、別の指標で動いているからです。
送っている」
の壁
リードばかり」
SQL定義がズレる5つの構造的原因
- 「良い顧客」の定義が部門で異なる
マーケティングは獲得件数・見込み客数・スコアを追い、営業は受注・年間売上・成約率を追います。見ている収益地点が違うため、同じ見込み客を「良い」と見るか「使えない」と見るかが自然にずれます。
- 見込み客の条件が行動量だけで決まっている
資料ダウンロード・セミナー参加・スコア数点といった行動量だけで見込み客を絞り込むと、導入時期不明・決裁権なし・情報収集段階の連絡先が大量に送られます。行動量と受注可能性は別物です。
- 商談候補の条件が担当者ごとに違う
営業マネージャーごとに「これは追う」「これはいらない」の判断が異なると、商談候補の基準は崩れます。基準が個人の経験に依存する限り、部門間の摩擦は解消されません。
- 指標の定義が統一されていない
マーケティングが見込み客数を追い、営業が商談転換率を追っていても、両者の定義がずれていれば会議は「数字の責任論」になります。共通の収益指標の土台がなければ、議論は建設的になりません。
- 収益の流れが部門で分断されている
マーケティングは見込み客獲得まで、営業は商談から——それぞれが担当範囲だけを見ていると、収益全体の流れが誰にも見えなくなります。これが分断の本質です。
SQL定義問題は「部門仲の問題」ではない
多くの会社はSQL問題を「部門連携不足」として捉えます。しかし本質は感情ではありません。指標の設計・収益の流れ・定義の統一・RevOpsの問題です。つまりSQL定義の問題は、Revenue Architectureの問題です。
コミュニケーション改善を試みても、収益構造が設計されていなければ同じ摩擦が繰り返されます。
Traffic
MQL
行動条件
SQL
時期確認
Opportunity
予算確認
ARR
本当に必要なのは「収益基準での顧客定義」
どの顧客を、どの条件で、どのタイミングで収益候補とみなすか——これを定義する設計が必要です。重要なのは見込み客数ではなく、収益につながる顧客を定義することです。この定義が整うと、マーケティングは収益に向けた獲得を最適化し、営業は質が揃った商談候補を受け取れます。
SQL定義が機能している会社には共通点があります。狙う顧客像(ICP)が明確に定義されている。見込み客の条件が収益基準で決まっており、行動量だけで判断していない。商談候補の条件が営業との合意のもとで設定されている。成功パターンが構造化されており再現できる。RevOpsが両部門の間に立って設計を維持している。
Revenue Architecture という考え方
SQL定義問題の本質はマーケティング問題ではありません。営業・マーケティング・カスタマーサクセス・CRM・KPI・データを「収益につながる一つの構造」として設計するRevenue Architectureの問題です。Revenue Architecture・収益基準での顧客定義・RevOps・KPI設計・収益の流れという構造が整うことで、SQL定義は部門を超えて機能するようになります。
営業に届く
一貫して追える
両部門が動く
日本企業でSQL問題が起きやすい理由
日本企業では部門分断・属人営業・指標の分断・Excel文化が根強く残っています。そのためマーケティングと営業が「別組織」として動きやすく、収益チームとして連携するための構造が整いにくい。必要なのは「収益チーム」として動くための共通設計であり、日本企業の組織文化に合ったRevenue Architectureの導入が求められます。
Consilegyの考え方
ConsilegyではMQL・SQL改善を単なるMAの運用改善とは考えていません。本質はRevenue Architecture・収益基準での顧客定義・RevOps・収益可視化・収益の流れの設計にあります。HubSpot・Salesforce・BI・Slack・Kintoneを横断しながら、「収益につながる顧客選別の構造」を設計します。目的は見込み客数を増やすことではなく、収益につながる商談を増やすことです。
| 課題 | Consilegyのアプローチ |
|---|---|
| マーケと営業でSQL基準がズレる | ICP定義 + 商談候補条件の合意設計 |
| 見込み客の商談転換率が低い | 収益基準の見込み客条件設計 |
| 指標の定義が部門ごとに違う | KPI統一設計 + 定義の明文化 |
| 部門間の摩擦が続く | RevOps整備 + 収益チーム設計 |
| 収益全体が見えない | 収益の流れ設計 + 収益可視化構築 |
まとめ:SQL問題はRevenue構造の問題
マーケティングと営業でSQL定義がズレる原因は部門仲の問題ではありません。Revenue Architecture不足・KPI設計不足・収益基準での顧客定義未設計・RevOps未整備が本質的な原因です。だからこそ必要なのは見込み客数の改善ではなく、「収益につながる顧客選別の構造」を設計することです。SQL定義はRevenue Architecture全体として設計されるべきです。
「質のいいリード」の前に、収益基準の顧客定義を
ConsilegyはICP定義から商談候補条件の合意設計まで、マーケティングと営業が収益チームとして動ける構造を支援します。まずは現状のSQL定義の課題を整理するところから始めましょう。
無料相談を予約する