「MQLとSQLの違いが、社内でいまひとつ整理できていない」
「マーケティングは有望だと思って営業に渡しているのに、営業からは“まだ早い”と言われる」
「MAやCRMを導入したものの、どのタイミングで営業に渡すべきか曖昧なまま運用している」
このような悩みを抱える企業は少なくありません。
BtoBマーケティングやインサイドセールスの現場では、MQLやSQLという言葉はよく使われます。
しかし、言葉だけは知っていても、実際にどう定義し、どう運用すればよいのかが曖昧なケースは非常に多いです。
その結果、マーケティングは「有望なリードを渡している」と考え、営業は「まだ商談するには早い」と感じる、といったすれ違いが起きやすくなります。
この状態では、リード数が増えても商談化率や受注率は安定しません。
重要なのは、MQLとSQLの言葉の違いを覚えることではありません。
自社にとって、どの状態ならマーケティングが持つべきで、どの状態なら営業が追うべきかを決めることです。
本記事では、MQLとSQLの基本的な違いから、定義の考え方、見分け方、営業への受け渡し方、運用でよくある失敗までを体系的に解説します。
マーケティングと営業の連携を改善したい方、リード管理を仕組み化したい方は、ぜひ参考にしてください。
「リードはあるのに商談化しない」を解消。営業につながる運用設計を支援するヒルハーバー
目次
※本記事は合同会社ヒルハーバーによる寄稿記事です。LISKUL編集部監修のもと公開しています。
MQLとSQLとは？
まずは、MQLとSQLの定義からおさらいしましょう。
そもそも、MQL、SQLとはどのようなものなのでしょうか。
MQLは「マーケティングが有望だと判断したリード」
MQLとは、Marketing Qualified Leadの略です。
日本語にすると、マーケティングの観点で有望と判断されたリードを指します。
ここでいう「有望」とは、必ずしも今すぐ商談になるという意味ではありません。
あくまで、ターゲットとしての適合度や、行動の内容から見て、今後の商談化や受注につながる可能性があると判断された状態です。
たとえば、次のようなケースはMQLとして扱いやすいです。
- ターゲット業種・企業規模に当てはまる
- 想定している部門や役職に近い
- 特定の課題テーマに関する資料をダウンロードした
- 複数回サイトを訪問している
- ウェビナー参加やお問い合わせなど、一定の関心行動が見られる
つまりMQLは、営業がすぐに受け取るべき案件というより、営業接続の候補として一段階上がったリードと考えると整理しやすくなります。
SQLは「営業が案件として追う価値があると判断したリード」
SQLとは、Sales Qualified Leadの略です。
日本語にすると、営業の観点で案件化の可能性があると判断されたリードを指します。
MQLとの違いは、単に温度感が少し高いということではありません。
より本質的には、営業が今追う価値がある状態かどうかがポイントです。
たとえば、次のような状態はSQLとして扱いやすくなります。
- 課題がある程度明確になっている
- 導入時期や検討タイミングが見えている
- 予算や体制のイメージがある
- 社内で検討を進める立場の人と接点がある
- 営業接触に対する反応が前向きである
つまりSQLは、マーケティング上の有望さではなく、営業活動の対象として現実的かどうかが判断基準になります。
MQLとSQLは「優劣」ではなく「役割の違い」
MQLとSQLを理解するときに注意したいのは、SQLのほうが上、MQLはその手前、という単純な段階論だけで捉えないことです。
たしかに多くの場合、MQLからSQLへ進む流れになります。
ただし重要なのは、MQLとSQLが単なる上下関係ではなく、マーケティングと営業のどちらが主に持つべきかを分けるための役割定義だということです。
MQLは、まだマーケティングやインサイドセールスの育成が有効な状態。
SQLは、営業が直接追って前に進めるべき状態。
このように考えると、違いがかなり整理しやすくなります。
参考：リードとは？5分で学ぶ最低限おさえておくべき基礎｜LISKUL
リードクオリフィケーションとは？基礎から評価方法まで紹介！｜LISKUL
MQLとSQLの違いはどこにあるのか
MQLとSQLは似た言葉に見えますが、実務上は見るポイントが異なります。
違いを理解するには、「誰が判断するのか」「何をもって次の段階とするのか」を分けて考えることが大切です。
1. 判断主体が違う
もっとも基本的な違いは、判断主体です。
MQLは、マーケティングやインサイドセールスの視点で、「このリードは今後の商談・受注につながる可能性が高そうだ」と判断した状態です。
一方、SQLは、営業の視点で、「このリードは今、案件として追う価値がある」と判断した状態です。
ここで重要なのは、同じリードでも、マーケティングには有望に見えて、営業にはまだ早く見えることがあるという点です。
だからこそ、MQLとSQLを分ける必要があります。
2. 見る基準が違う
MQLでは、主に次のような基準を見ます。
- ターゲットとの適合度
- 関心テーマ
- 行動履歴
- コンテンツ接触状況
- フォーム送信やウェビナー参加などの反応
つまり、この人は自社にとって有望かという視点です。
一方、SQLでは、次のような基準が重要になります。
- 課題の明確さ
- 導入意向の有無
- 時期の近さ
- 意思決定への関与度
- 営業接触の現実性
つまり、この人は今、営業が追うべきかという視点です。
この違いを曖昧にすると、マーケティングは「行動しているから有望」と考え、営業は「でも案件としてはまだ早い」と感じるようになります。
3. 期待されるアクションが違う
MQLとSQLでは、その後に取るべきアクションも変わります。
MQLであれば、必ずしもすぐ営業へ渡す必要はありません。ナーチャリングを続けながら、追加の情報提供や行動促進を行い、商談化しやすい状態へ育てることも有効です。
一方、SQLであれば、営業が具体的なヒアリングや提案に進めることが期待されます。ここで営業初動が遅れたり、ヒアリングの質が低かったりすると、せっかくのSQLを取りこぼすことになります。
つまり、MQLとSQLの違いは、言葉の違いというより、次に誰がどんな動きをするべきかの違いなのです。
なぜMQLとSQLを分ける必要があるのか
MQLとSQLを分けずに運用している企業もあります。
もちろん、扱うリード数が少なく、営業とマーケティングが一体で動いている組織なら、それでも回ることがあります。
ただし、一定以上のリード数がある企業や、マーケティング・インサイドセールス・営業の役割が分かれている企業では、MQLとSQLを分ける意味は大きくなります。
1. 営業の負荷を適正化しやすくなる
営業にすべてのリードを渡してしまうと、本来はまだ育成すべきリードまで営業が追うことになります。
その結果、営業工数が膨らみ、本当に優先すべき案件への対応が遅れやすくなります。
MQLとSQLを分けることで、
- 「今はマーケティング側で持つべきもの」
- 「今は営業が追うべきもの」
を整理しやすくなります。
これは、営業の負荷を減らすというより、営業が力を使うべき相手に集中しやすくするために重要です。
2. 商談化率の議論がしやすくなる
MQLとSQLを分けていないと、商談化率の議論が感覚的になりやすくなります。
マーケティングは「たくさんリードを取れている」と考えていても、営業は「でも商談にならない」と感じる。
このとき、どの段階で問題が起きているのかが分かりにくくなります。
MQLとSQLを分けておけば、
- そもそもMQLの基準が広すぎるのか
- MQLからSQLへの転換が弱いのか
- SQLは十分あるのに商談化できていないのか
といった切り分けがしやすくなります。
3. ナーチャリングの設計がしやすくなる
すべてのリードを同じように扱っていると、ナーチャリングも営業接続も雑になりやすいです。
しかし、MQLとSQLを分けることで、
- 「今は育成すべきか」
- 「今は営業が具体的に前進させるべきか」
を考えやすくなります。
その結果、メール配信、ホワイトペーパー、ウェビナー、営業通知などの設計がしやすくなり、取りこぼしも減らしやすくなります。
参考：リードマネジメントとは？マーケティング成熟度による課題整理と解決方法｜LISKUL
リードナーチャリングとは？16種の方法と成功のための5つのポイント｜LISKUL
MQLとSQLの定義はどう決めるべきか
ここで重要なのは、MQLやSQLに正解の定義があるわけではないということです。
業種、商材、検討期間、営業体制、リード数によって、適切な定義は変わります。
大切なのは、一般論をそのまま持ち込むことではなく、自社の現場で運用できる定義を作ることです。
1. まずは「受注しやすい案件」の特徴を整理する
定義を考えるときは、言葉から入るより、受注実績から逆算したほうが実務的です。
たとえば、過去に受注しやすかった案件には、どのような共通点があるでしょうか。
- どの業種が多いか
- どの企業規模が多いか
- どの部門・役職が起点か
- どんな課題テーマが多いか
- どの流入経路やオファーが多いか
- 導入時期や検討背景にどんな傾向があるか
この整理をすると、MQLやSQLで見るべき要素が見えてきます。
2. MQLは「ターゲット適合度」と「関心行動」で考える
MQLを定義する際には、主に2つの観点を組み合わせると考えやすくなります。
1つ目は、ターゲット適合度です。
業種、企業規模、部門、役職などが、自社の狙いたい条件に合っているかを見ます。
2つ目は、関心行動です。
資料ダウンロード、ウェビナー参加、特定ページの閲覧、複数回訪問など、一定の興味や課題感が見えるかを見ます。
この2つがそろってくると、単なるリードではなく、MQLとして扱いやすくなります。
3. SQLは「営業が今追うべきか」で決める
SQLを定義するときに大切なのは、細かい条件を増やすことではありません。
もっとも重要なのは、営業が今追っても意味があるかです。
たとえば、
- 課題がある程度明確
- 社内で検討が始まっている
- 導入時期が見えている
- 担当者が前向きである
- 次回打ち合わせやヒアリングが現実的に進みそう
といった条件がそろっているかを見ます。
逆に、ターゲット適合度が高くても、まだ課題が曖昧で検討も先なら、MQLにとどめて育成したほうがよいことがあります。
4. 最初から細かくしすぎない
MQLやSQLの定義を作るときによくある失敗が、最初から複雑にしすぎることです。
点数表を細かく作りすぎたり、条件分岐を増やしすぎたりすると、一見精度が高そうに見えます。
しかし実際には、運用する人が理解しきれず、データも十分にたまらず、結局形骸化しやすくなります。
多くの企業では、まずはシンプルに
- MQLはどの状態か
- SQLはどの状態か
- 誰がどのタイミングで判断するか
を明確にするだけでも十分効果があります。
重要なのは、最初から完璧な定義を作ることではなく、あとで見直せる前提で運用し始めることです。
MQLとSQLをどう見分けるか
では、実務の中でMQLとSQLはどのように見分ければよいのでしょうか。
考え方をシンプルにすると、次のように整理できます。
MQLの見分け方
MQLは、次のような状態で判断しやすくなります。
- ターゲット企業に近い
- 想定部門・役職に近い
- 自社が扱う課題テーマへの関心が強い
- 一定以上の接触行動がある
- 継続的な情報提供に反応する可能性がある
つまり、将来的に営業機会へつながる可能性が見える状態です。
SQLの見分け方
SQLは、次のような状態で判断しやすくなります。
- 課題が具体的に言語化されている
- 導入・改善への意志がある
- 商談設定や詳細ヒアリングに応じる
- 営業が前に進めるための情報がある
- 次回アクションの合意が取りやすい
つまり、営業が今、具体的に前進させられる状態です。
判断に迷うときは「今営業が持つべきか」で考える
実務では、MQLかSQLか迷うケースが必ず出てきます。
そのときに役立つのが、「このリードは今、営業が持つべきか」という問いです。
- まだ早いと感じるなら、MQLとして育成する
- 今動く価値があるなら、SQLとして営業へ渡す
この考え方にすると、定義が多少曖昧でも、現場では判断しやすくなります。
MQLからSQLへ、どう受け渡すべきか
MQLとSQLの違いを定義しても、受け渡しの設計がなければ運用はうまくいきません。
重要なのは、定義そのものだけでなく、どう次の部門へつなぐかです。
1. 誰が判定するのかを決める
まず決めておきたいのは、MQLからSQLへの判定を誰が行うのかです。
- マーケティングが機械的に渡すのか
- インサイドセールスが一次確認して渡すのか
- 営業が初回接触後にSQL判定するのか
ここが曖昧だと、同じリードでも扱いがばらばらになりやすくなります。
2. 受け渡し時に必要な情報をそろえる
営業に渡すときは、単に「このリードは有望です」と伝えるだけでは不十分です。
たとえば、次のような情報があると、営業の初回接触の質が上がります。
- どのコンテンツに反応したか
- どんな課題テーマに興味があるか
- どの流入経路から来たか
- いつ、どんな行動をしたか
- フォームで取得した導入時期や検討背景
- 過去の接触履歴やメール反応
こうした情報があれば、営業はゼロから探るのではなく、仮説を持って接触できます。
3. 営業の初回対応期限を決める
SQLとして渡すなら、営業がどれくらいのスピードで対応するかも重要です。
高意図のリードほど、時間が経つと温度感が下がりやすくなります。
そのため、SQL化したら何営業日以内に初回接触するのか、接触できなかった場合はどうするのか、といったルールを決めておく必要があります。
4. 返却ルールを作る
営業に渡したものの、実際にはまだ商談化に早かった、というケースもあります。
このとき重要なのは、「営業に渡したら終わり」にしないことです。
たとえば、
- 時期未成熟
- 課題顕在化不足
- ターゲット適合は高いが検討前
- 担当者の情報収集段階
といった案件は、営業が追わないと判断しても、マーケティング側で再育成する価値があります。
そのため、SQLとして渡した後に営業がどう評価し、どの条件ならマーケティングへ返すのかまで決めておくと、運用が安定しやすくなります。
参考：インサイドセールスとは？Withコロナ時代に必須となった営業手法の基本～実践導入完全ガイド｜LISKUL
CRMとは？目的・メリット・機能から導入の流れまで一挙解説！｜LISKUL
MQLとSQLの運用でよくある失敗
MQLとSQLは、言葉を導入するだけでは機能しません。
ここでは、実務でよくある失敗を整理します。
1. 用語だけ導入して、定義がない
もっとも多いのがこのケースです。
社内でMQL、SQLという言葉は使っているものの、
- 何をもってMQLとするのか
- 何をもってSQLとするのか
- 誰が判定するのか
が明確でない状態です。
これでは、部門間の共通言語にはなりません。
2. MQLを広く取りすぎる
MQLを増やしたいあまり、資料ダウンロードやフォーム送信だけで機械的にMQL扱いしてしまうことがあります。
しかし、それではターゲット適合度や課題感が十分でないリードまで混ざりやすくなります。
結果として、MQL数は増えても、その後のSQL化率や商談化率が伸びず、営業からの信頼も下がりやすくなります。
3. SQLの基準が厳しすぎる
逆に、SQLの条件を厳しくしすぎると、今動けば商談になったはずの案件まで取りこぼすことがあります。
予算、時期、決裁者接触などを完璧にそろってからSQLにしようとすると、営業が関わるには遅すぎるケースもあります。
SQLは「受注直前」である必要はありません。
あくまで、営業が追う価値がある状態で考えることが大切です。
4. スコアリングを細かくしすぎる
MQLやSQLの運用を始めると、点数化したくなることがあります。
もちろん、スコアリング自体が悪いわけではありません。
ただし、リード数がそこまで多くない企業や、商材・ターゲットが多様な企業では、細かいスコア設計が実務に合わないことも少なくありません。
条件を増やしすぎると、運用が複雑になり、見直しもしにくくなります。
多くの企業では、まずはシンプルな定義と営業フィードバックを回しながら、商談や受注まで見て調整するほうが現実的です。
5. 受け渡し後の評価が戻ってこない
営業に渡したSQLが、その後どうなったのかがマーケティングへ返ってこないケースもよくあります。
これでは、MQLやSQLの定義が妥当だったのかが検証できません。
結果として、同じようなズレが繰り返されます。
重要なのは、MQL数やSQL数を増やすことではなく、その定義が商談化率や受注率につながっているかを見ることです。
参考：MAとCRMの違いとは？くわしい違いや選定方法まで徹底解説｜LISKUL
MQLとSQLの運用で見るべきKPI
MQLとSQLを導入するなら、数だけでなく歩留まりも見る必要があります。
主に見たいのは次のような指標です。
入口指標
入口では、リードの量と質を見ます。
- リード数
- ターゲット含有率
- オファー別CV数
- 流入経路別の反応
中間指標
中間では、MQLとSQLの転換を見ます。
- MQL化率
- MQLからSQLへの転換率
- SQL化までの期間
- 営業接触率
- 商談化率
この部分を見ることで、定義が適切か、受け渡しが機能しているかが見えやすくなります。
出口指標
出口では、最終成果を見ます。
- 受注率
- 受注件数
- CAC
- 商材別・チャネル別の成果
MQLやSQLは、あくまで途中の管理指標です。
最終的に受注につながっていなければ、定義や運用を見直す必要があります。
参考：インサイドセールスのKPI設定・管理方法とは？フェーズ別に紹介｜LISKUL
まとめ：MQLとSQLの違いは、誰が持つべきかを分けることにある
MQLとSQLは、単なる用語の違いではありません。
その本質は、そのリードを今、マーケティングが持つべきか、営業が持つべきかを分けることにあります。
MQLは、マーケティングの観点で有望と判断された状態。SQLは、営業の観点で案件として追う価値があると判断された状態です。
この違いを明確にすると、
- 営業が追うべき相手が整理される
- ナーチャリングすべき相手が見える
- 商談化率や受注率の課題が切り分けやすくなる
- マーケティングと営業の認識がそろいやすくなる
といった効果が期待できます。
重要なのは、一般論としての定義を覚えることではありません。
自社のターゲット、営業体制、検討期間に合わせて、運用できる定義を作り、商談・受注まで見ながら調整していくことです。
MQLとSQLが機能しない企業の多くは、言葉の問題ではなく、運用の問題を抱えています。
だからこそ、定義、受け渡し、営業フィードバックまで含めて設計しましょう。
【PR】MQL・SQLの定義や営業接続を見直したい方へ
MQLとSQLがうまく機能しない原因は、MAやCRMの設定だけにあるとは限りません。
ターゲット設計、オファー設計、獲得チャネル、ナーチャリング、営業接続、失注後の再育成まで、複数の工程にまたがっていることが多くあります。
ヒルハーバーでは、マーケティング・営業領域のコンサルティングから、施策実行、改善、運用支援まで一気通貫でご支援しています。SEO、制作、広告配信はもちろん、MAやCRMの導入・運用、MQL・SQL定義の整理、営業につながる運用設計まで対応可能です。
「MQLとSQLの定義が曖昧で、営業とマーケの認識がずれている」
「MAやCRMは入っているが、営業接続が仕組み化できていない」
「リードはあるのに、商談化・受注につながらない」
このようなお悩みがある方は、ぜひご相談ください。
「リードはあるのに商談化しない」を解消。営業につながる運用設計を支援するヒルハーバー
※本記事は合同会社ヒルハーバーによる寄稿記事です。LISKUL編集部監修のもと公開しています。
コメント