「資料請求は増えているのに、営業からは“商談にならない”と言われる」「MQLの件数を追っているが、売上とのつながりが見えない」。この課題は、リード数が足りないことよりも、マーケティングと営業で“渡すべきリード”の認識がそろっていないことで起こります。
結論からいえば、MQLとSQLは用語だけ定義しても機能しません。誰に・どの行動があったとき・どんな情報を添えて・いつ営業へ渡し・営業がどう結果を返すかまでを一連の運用として決める必要があります。
この記事では、MQLとSQLの違いから、営業が動きやすい引き渡し基準を設計する6ステップ、見るべき数字、失敗しやすいポイントまで解説します。
MQLとSQLの違いは「判定者」と「確認できている情報」にある
MQLはMarketing Qualified Lead、SQLはSales Qualified Leadの略です。ただし、両者の厳密な定義は企業の商材、営業体制、購買プロセスによって異なります。大切なのは一般論に合わせることではなく、自社の受注につながる条件を両部門で言語化することです。
| 区分 | 基本的な意味 | 主な判定者 | 判断材料 |
|---|---|---|---|
| リード | 連絡先を把握できた見込み客 | マーケティング | 問い合わせ、資料請求、イベント参加など |
| MQL | 営業に渡す価値があるとマーケティングが判断したリード | マーケティング | ターゲット企業との適合性、Web行動、資料利用、問い合わせ内容など |
| SAL | 営業が引き渡しを受け入れ、対応対象と判断したリード | 営業 | 担当エリア・担当者の確認、重複や既存商談の確認、初期情報の妥当性 |
| SQL | 営業の接触・ヒアリングを通じ、商談化を進める価値があると判断したリード | 営業 | 課題、導入背景、関係者、検討時期、予算・稟議の状況など |
SAL(Sales Accepted Lead)は必須の区分ではありません。しかし、MQLを渡した後に営業が受け入れたのか、連絡が取れず保留なのか、そもそも対象外なのかを分けたい場合には有効です。MQLからSQLまでを一気に追うだけでは、問題が「引き渡し基準」「初回対応」「ヒアリング」のどこにあるか見えにくくなります。
なお、資料請求や問い合わせがあったからといって、必ずしもSQLとは限りません。たとえば採用目的の閲覧、既存顧客からの問い合わせ、対象外の企業規模、情報収集段階の担当者である可能性があります。一方で、対象企業からの具体的なデモ依頼なら、合計スコアを待たずに優先対応すべきこともあります。
MQLの前に決めるべきは「受注につながりやすい条件」
リードスコアリングを始めると、「価格ページ閲覧は10点」「資料請求は20点」のような点数設定から着手しがちです。しかし、先に点数を決めると、見た目は整っていても営業が納得しないモデルになりがちです。
まずは、直近の受注案件と失注・失格案件を見比べて、受注につながりやすい条件を整理しましょう。件数が少ない企業でも、営業責任者や現場担当者へのヒアリングを組み合わせれば、初期基準は作れます。
確認したい4つの条件
- 企業適合:業種、従業員規模、地域、利用中の環境、予算規模などは理想顧客像(ICP)に合うか
- 人物適合:担当者の部署、役職、課題への関与度、決裁者や推進者への接続可能性はあるか
- 関心・行動:製品ページ、料金、導入事例、比較資料、セミナー、問い合わせなど、どの情報に触れているか
- 購買文脈:何を解決したいのか、導入時期はいつか、社内で誰が関わるのか
このうち、企業適合と人物適合はマーケティングでも一定程度判断できます。対して、課題の切実さや稟議の進行状況は、営業が会話して初めて分かることが多い情報です。だからこそ、MQLとSQLを同じ条件で扱わないことが重要です。
営業に渡す基準を設計する6ステップ
1. リードのステージと担当部門を一枚にまとめる
最初に、リード獲得から受注までのステージを並べ、各ステージの判定者と次のアクションを決めます。MA、CRM、SFAでステータス名称が異なる場合も、運用上の意味を統一してください。
| ステージ | 判定者 | 次のアクション |
|---|---|---|
| 新規リード | マーケティング | 属性補完、流入元確認、初回コンテンツ配信 |
| 育成対象 | マーケティング | 課題や検討段階に合う情報を提供 |
| MQL | マーケティング | 必要情報を添えて営業キューへ引き渡し |
| SAL | 営業 | 担当割り当て、初回接触、対応可否を記録 |
| SQL | 営業 | ヒアリング、提案、商談化 |
| 再育成 | マーケティング | 見送り理由に応じたナーチャリングへ戻す |
ここでのポイントは、失格と再育成を混同しないことです。「今は時期ではない」「担当者はいるが課題が不明」といったリードは、対象外ではありません。理由を残して再育成に戻せば、将来の商談機会を失わずに済みます。
2. 受注・失注データと営業の所感から仮説をつくる
過去の受注案件を見て、「どの業種・企業規模・役職・流入経路・コンテンツ接触が多かったか」を確認します。同時に、営業に差し戻されたリードの理由も集計しましょう。
- 対象外の業種・規模だった
- 既存顧客、競合、採用・協業目的だった
- 連絡先が不正確だった
- 課題や導入意向が確認できなかった
- 検討時期が遠く、今すぐの営業対応には向かなかった
差し戻し理由は、営業の評価ではなく、上流の設計を改善する材料です。たとえば「対象外企業が多い」ならフォーム項目や広告ターゲティングを見直し、「検討時期が遠い」なら営業へ急いで渡すのではなく育成シナリオを整えます。
3. 合計点だけでなく「適合」と「関心」を分けて評価する
実務では、すべてを一つの合計点にすると判断を誤りやすくなります。ターゲットに合わない企業が多くのコンテンツを見た場合と、理想顧客企業がまだ情報収集段階にある場合では、取るべきアクションが違うためです。
初期設計では、次のように二軸で管理すると運用しやすくなります。
| 関心が高い | 関心が低い | |
|---|---|---|
| 適合度が高い | 営業へ優先引き渡し、または個別フォロー | 課題別コンテンツで育成し、再評価 |
| 適合度が低い | 対象外条件を再確認し、必要なら限定的に対応 | 原則として配信対象を見直す |
適合度には業種、企業規模、部署、役職などを使います。関心には、料金・導入事例・比較ページの閲覧、ウェビナー参加、個別相談、トライアルといった行動を使います。さらに、行動の直近性を別に見てください。半年前の資料請求と、昨日の料金ページ閲覧を同じ重さにしないためです。
4. MQLの基準は「除外条件+適合+行動」で決める
最初のMQL基準は、複雑にしすぎないほうが改善しやすくなります。たとえば、以下のような構造です。
- 除外条件:既存顧客、採用目的、競合、明確な対象外業種・規模、連絡不能なデータ
- 適合条件:ターゲット業種かつ一定以上の企業規模、関係部署・役職に該当する
- 行動条件:導入事例・料金・比較資料の閲覧、セミナー参加、複数回のサイト訪問、資料請求など
- 即時対応トリガー:デモ依頼、見積もり依頼、個別相談、トライアル申込など
「合計30点以上」のような閾値を置く場合も、即時対応トリガーは別ルールにしましょう。明確な相談をしている見込み客を、点数不足のために育成へ戻すのは機会損失になり得ます。
また、点数は正解を当てるための数字ではありません。優先順位をそろえ、次の行動を決めるための仮説です。初期は評価項目を絞り、営業の受け入れ状況を見ながら調整するほうが有効です。
5. SLAで「渡し方」と「営業の返し方」を約束する
MQL基準があっても、通知だけで営業に任せると放置されます。SLA(Service Level Agreement)として、マーケティングと営業の双方の約束を明文化しましょう。
最低限、以下を決めます。
- マーケティングがMQLとする条件
- 営業へ渡す情報:企業・担当者属性、流入元、直近の行動、閲覧・ダウンロードしたコンテンツ、問い合わせ内容、スコア内訳
- 営業が初回対応する期限
- 営業が記録する結果:受け入れ、商談化、再育成、失格、連絡不能など
- 再育成へ戻す場合の理由と、次に見直す時期
特に重要なのは、「スコアが何点だったか」だけでなく、「なぜ今このリードを渡すのか」を営業に伝えることです。たとえば「製造業・従業員300名・情報システム部門。直近7日間で導入事例と料金ページを閲覧し、比較資料をダウンロード」といった文脈があれば、最初の会話を準備しやすくなります。
6. MQL数ではなく、引き渡し後の歩留まりで見直す
改善では、MQL数だけをKPIにしないでください。件数だけを追うと、閾値を下げてリードを増やす方向に偏り、営業の対応負荷や不信感を高めることがあります。
まずは、以下の流れを同じ期間・同じ集計条件で追います。
- リード数
- MQL数・MQL率
- SAL率(営業受け入れ率)
- SQL率・MQLからSQLへの転換率
- 商談化率
- 受注率、受注金額、受注までの日数
- 再育成率・失格理由の構成比
たとえばMQL数が増えてもSAL率が下がっているなら、基準や流入元の見直しが先です。SAL率は高いのにSQL率が低いなら、営業の初回接触で得られる情報、提案内容、ヒアリング基準に課題があるかもしれません。
KGIからKPIをつなぐ考え方は、WebマーケティングのKPI設計方法でも詳しく解説しています。MQLを単独で評価せず、商談・受注までの因果を追える状態にしましょう。
リードスコアリングでよくある4つの失敗
メール開封に過度な点数を付ける
メール開封は関心の補助シグナルにはなりますが、それだけで購買意欲を判断するのは危険です。件名や配信タイミングにも左右されます。料金、導入事例、比較、個別相談など、検討の深さを示しやすい行動と組み合わせて評価しましょう。
営業に渡す条件をマーケティングだけで決める
営業が日々の会話から得ている「受注しやすい会社・担当者・検討状況」の知見を使わなければ、基準は机上のものになります。初期設計の段階から営業責任者と担当者を巻き込み、月次または四半期ごとに差し戻し理由を確認する場を設けてください。
失格にしたリードを放置する
「時期尚早」「担当者が違う」「予算未確定」は、将来も見込みがないことを意味しません。失格理由を一つのステータスにまとめず、再育成の対象か、明確な除外対象かを分けます。育成コンテンツを増やす前に、見送り理由別に必要な情報を整理することが先です。
検討段階ごとのコンテンツ設計は、コンテンツマーケティング戦略の立て方も参考にしてください。
AIや予測スコアを導入すれば解決すると考える
予測型スコアリングは、受注・失注の履歴と、整った属性・行動データがあって初めて精度を検証できます。データ量が少ない、失格理由が記録されていない、営業活動がCRMに残っていない段階では、まずルールベースで基準とフィードバックの流れを整えるほうが現実的です。
AIは、基準ができた後に「どの条件が受注に効いているか」「優先順位をどう変えるか」を補助するために使います。ツール導入そのものを目的にせず、営業の対応時間と商談化の改善につながるかで判断しましょう。
Ad屋が考える、商談化につながるMQL運用の本質
MQLはマーケティングの成果指標である前に、営業の時間をどこへ配分するかを決める運用ルールです。そのため、良いMQL設計とは、スコアが精巧な設計ではありません。営業が「この情報なら次の一手を決められる」と感じ、マーケティングも「どの獲得施策・育成施策を直すべきか」を数字で判断できる設計です。
最初から複雑な100点満点のモデルを作る必要はありません。まずは、対象外を除く、適合度と関心を分ける、即時対応の行動を決める、返却理由を記録する。この4点を小さく実装し、1〜3か月程度の運用結果を見て改善します。
リード獲得、ナーチャリング、営業連携、商談化は別々の施策ではなく、一つの流れです。MQLとSQLの定義を共通言語にできれば、広告、SEO、コンテンツ、イベントで得たリードを、商談につながる学びへ変えやすくなります。
まとめ
- MQLはマーケティングが営業へ渡す価値があると判断したリード、SQLは営業の接触・確認を経て商談化を進める価値があると判断したリード
- 自社のMQL・SQL定義は、受注案件と営業の知見を基に作る
- 評価は合計点だけでなく、企業・人物の適合度、関心行動、行動の直近性を分けて考える
- SLAで、引き渡し条件、共有情報、初回対応期限、営業からの結果返却を明文化する
- MQL数だけでなく、SAL率、SQL率、商談化率、失格・再育成理由を追って改善する
まずは、直近のMQLを10〜20件ほど取り出し、営業が受け入れた理由・見送った理由を確認するところから始めてみてください。その結果を基に、最初の引き渡し基準とフィードバック項目を一枚にまとめると、実務で使えるMQL設計に近づきます。
参考情報
- MQLとSQLの違いとは?定義から基準設定、部門連携強化で売上を最大化する方法|セールスフォース・ジャパン
- リード・スコアリングとは|Oracle 日本
- Lead scoring|Oracle
- The state of lead scoring models and their impact on sales performance|Information Technology and Management / PubMed
- https://www.heysid.com/resources/mq-vs-sql-b2b-lead-definitions-that-matter|www.heysid.com
- https://pmc.ncbi.nlm.nih.gov/articles/PMC9890437/|pmc.ncbi.nlm.nih.gov
- https://syncgtm.com/blog/b2b-marketing-and-sales-alignment|syncgtm.com
- https://saleshive.com/blog/mql-vs-sql-b2b-lead-qualification|saleshive.com
- https://btobmarketing-textbook.com/mql-sql-difference/|btobmarketing-textbook.com
- https://mantasauk.com/articles/mql-sql-handover-blueprint-marketing-sales-alignment/|mantasauk.com
- https://www.leadseed.io/blog-en/mql-to-sql-criteria-workflow-b2b/|www.leadseed.io
- https://pmc.ncbi.nlm.nih.gov/articles/PMC11925937/|pmc.ncbi.nlm.nih.gov
