第39回｜MQLとSQLの違いを、現場の言葉で説明してみた。 ― 教科書の定義では、現場は動かない。

先に結論を言う。MQL（Marketing Qualified Lead）は「マーケが"良さそう"と判断した見込み客」、SQL（Sales Qualified Lead）は「営業が"会う価値あり"と認めた見込み客」のことだ。

違いは一言でいえば、「誰が」「何を基準に」良いと判断したかにある。

教科書には「MQLはマーケが評価した有望リード、SQLは営業が承認した商談化リード」と書いてある。間違ってはいない。でもこの定義だけでは、現場で何をすればいいかわからない。

MQLとSQLの違い（基本の定義）

まず整理する。

$$
\begin{array}{|l|l|l|} \hline
\text{} & \text{MQL} & \text{SQL} \\ \hline
\text{判断する人} & \text{マーケティング} & \text{営業} \\ \hline
\text{判断基準} & \text{興味・関心の行動} & \text{商談に進める条件} \\ \hline
\text{具体例} & \text{資料DL、価格ページ閲覧、セミナー参加} & \text{予算・決裁権・導入時期が揃っている} \\ \hline
\text{段階} & \text{「興味がある」} & \text{「買う検討に入っている」} \\ \hline
\end{array}
$$

MQLは「この人、興味を持ってくれていそうだ」というマーケ側の期待だ。SQLは「この人なら商談として成立する」という営業側の判断だ。

リードは、MQL→SQL→商談→受注という順番で進んでいく。

なぜこの違いが、現場で問題になるのか

定義を知っていても、現場ではトラブルが起きる。

マーケは「MQLを30件渡した」と報告する。営業は「使えるリードは3件だった」と言う。

この食い違いが、マーケと営業の対立の最大の原因だ。

なぜ起きるか。MQLの判断基準（興味の行動）と、SQLの判断基準（商談の条件）の間に、大きなギャップがあるからだ。

「資料をダウンロードした」は興味の証拠だが、「予算がある」ことの証拠にはならない。情報収集しているだけの人も、資料はダウンロードする。MQLの基準だけで営業に渡すと、「興味はあるが買う気はない人」が大量に流れていく。

MQLとSQLのギャップを埋める方法

このギャップを埋めるのが、本来のマーケティングとインサイドセールスの仕事だ。

$$
\begin{array}{|l|l|l|} \hline
\text{手段} & \text{何をするか} \\ \hline
\text{MQL基準の精緻化} & \text{「興味」だけでなく「課題の深さ」を測る行動を基準に加える} \\ \hline
\text{インサイドセールスの介在} & \text{MQLとSQLの間に、ISが電話やメールで条件を確認する} \\ \hline
\text{共通定義の文書化} & \text{マーケと営業が「SQLとは何か」を一枚の文書で合意する} \\ \hline
\end{array}
$$

特に効くのがインサイドセールスの介在だ。MQLをそのまま営業に渡すのではなく、ISが「予算は？」「いつ頃の導入を？」「決裁は誰が？」を確認してからSQLに昇格させる。

このワンクッションがあるだけで、営業に渡るリードの質が劇的に変わる。

現場で一番大事なこと

MQLとSQLの違いを理解することより、もっと大事なことがある。

「自社にとってのMQLとSQLを、自分たちの言葉で定義すること」だ。

教科書の定義をそのまま使っても機能しない。自社の顧客、自社の営業プロセス、自社の商材に合わせて、「うちのMQLはこう、SQLはこう」と決める。そしてマーケと営業が同じ文書に合意する。

その一枚があるかないかで、組織の連携が決まる。

MQLとSQLの違いは、用語の問題じゃない。

マーケと営業が、どこで責任を引き継ぐかという、組織の設計の問題だ。

定義を覚えるより、自社の定義を作ることから始めてほしい。

用語は借り物でいい。でも基準は、自分たちで決めるしかない。

次回：「CVRが上がらない」と悩む前に、確認すべき3つのこと。