MQLとSQLの定義合ってますか？

こんにちは。「マーケと営業をつなぐISレター」の目木です。「リードの数は目標を達成しているのに、なぜか商談化率が上がらない」「営業とマーケで、リードの質をめぐる議論を毎月繰り返している」そんな状態に、心当たりはないでしょうか。今回は、MQL（Marketing Qualified Lead）とSQL（Sales Qualified Lead）という、マーケティングと営業の現場で日常的に使われている言葉を改めて整理しながら、この二つの定義が組織の中でどうズレていくのかを解説します。多くのBtoB企業のマーケティング・インサイドセールス・営業支援に携わってきた中で見えてきた、「測れる行動」と「測れない文脈」という構造の違いを軸に、実際にあった改善例も交えてお伝えします。こちらの記事をご覧いただくことで、リードの質をめぐる水掛け論が起きる根本原因と改善策が見えてくるはずです。ぜひ最後まで読み進めてみてください。営業責任者・経営者・事業責任者の方向けに、BtoB営業・マーケティング支援の現場から、売上プロセスの設計と改善を実務目線で発信しています。ご登録いただきますと情報を受け取ることができます。 MQLとSQLとは｜二つのリードの違いを整理する本題に入る前に、言葉の意味を簡単に整理しておきます。 MQL｜マーケティングが定義する「見込み」 MQLとは、Marketing Qualified Leadの略です。資料をダウンロードした、セミナーに参加した、料金ページを何度も見た。こうした行動データをもとに、マーケティング側が「見込みがありそうだ」と判断したリードのことを指します。 SQL｜営業が定義する「商談化してよい相手」 SQLとは、Sales Qualified Leadの略です。 * 決裁権がある * 予算がある * 検討時期が近い実際に商談を進めても大丈夫だと、営業側が判断したリードのことを指します。一般的な流れとしては、マーケがMQLを見つけて営業に渡し、営業がその中から本当に商談化すべき相手をSQLとして選び出します。このMQLからSQLへの「バトンタッチ」がうまくいっているかどうかは、マーケと営業の関係性を測るうえで、かなり重要な指標になります。今回お伝えしたいのは、まさにこの二つの言葉の「中身」が、会社によってどれだけズレているか、という話です。あるある失敗｜数字は達成しているのになぜか噛み合わないよくあるパターンから紹介します。マーケティング側は、月次のMQL目標を達成しています。 * 役職 * 企業規模 * 資料ダウンロード履歴 * サイト訪問回数 * メールの開封率こうした「測れる指標」でスコアリングして、基準を超えたリードをMQLとして営業に渡しています。数字の上では、ちゃんと機能しているように見えます。一方、営業側では商談化率が上がりません。渡されたリードに架電しても、決裁権がなかったり、予算がなかったり、そもそも本気で検討していなかったりする。そうすると、営業からは「マーケが渡してくるリードの質が悪い」という声が上がります。マーケからは「MQLの基準は満たしているから、営業の追客の問題では」という声が返ってきます。この水掛け論、聞き覚えのある方も多いのではないでしょうか。定義がズレる本当の理由｜「良いリード」の基準が部門ごとに別々に存在しているこの水掛け論が起きる根本原因は、コミュニケーション不足でも、運用ルールが整備されていないことでもありません。もっと手前の話として、「MQL」と「SQL」という言葉が指しているものが、マーケと営業でそもそも違うのです。マーケティングにとってのMQLは、「測れる行動」の組み合わせで定義されます。 * 資料をダウンロードした * 料金ページを見た * セミナーに参加したこうした行動データをスコア化して、一定の点数を超えたら「マーケティング的に見込みがある」と判断する。これはマーケティングという仕事の性質上、合理的なやり方です。多数のリードを効率よく処理するには、標準化されたスコアリングが欠かせません。一方、営業にとってのSQLは、もっと文脈的なものです。 * 決裁権を持っているか * 予算があるか * 検討のタイミングが近いか * 社内で本当に課題として認識されているかこれはスコアには現れない情報で、営業が一対一の会話の中で読み取っていくものです。つまり、マーケは「一対多」の論理で良いリードを定義し、営業は「一対一」の論理で良いリードを定義しています。この二つの定義は本来別ものなのに、多くの会社では「MQL」という同じ言葉を使って、両者が同じものを指しているつもりで会話してしまう。ここに、そもそものズレの出発点があります。部分最適の限界｜スコアの高いリードが、受注に一番近いとは限らないこのズレを放置すると、何が起きるでしょうか。マーケのスコアリングで上位のリードは、資料請求もするし、商談にも応じてくれます。ただ、意思決定者ではなかったり、本当の課題を抱えていなかったり、予算がなかったりすることも少なくありません。本当に受注につながるのは、スコアには現れない要素を持っている相手だったりします。組織内の力関係、検討している役員の温度感、競合との関係、社内の意思決定タイミング。こうした「測れない文脈」こそが、最終的に受注を決めます。営業はこの文脈を読む力で成果を出しているのですが、マーケのスコアリングは、この能力を前提にしていません。そして厄介なのは、MQLの数やSQLへの遷移率という数字は、経営会議で報告しやすいということです。ダッシュボードに並んで、可視化されます。一方で「このリードは決裁権はないけれど、半年後に部署異動で決裁側に回る可能性が高い」というような文脈情報は、数字にしにくいのです。結果として、経営陣は「見えるマーケの数字」を評価しやすくなり、「見えにくい営業の文脈判断」が軽視されがちになります。マーケのKPIが組織全体の評価軸になっていき、営業は与えられたリードに対して、決められたやり方で対応するだけの立場に押されていきます。これが続くと、営業からは「アポには繋がるけど、受注に繋がらない商談ばかり回ってくる」という不満が積み重なっていきます。そしてこの不満は、営業のモチベーションだけでなく、組織としての受注力そのものを削っていくのです。定義を共通言語にする｜一気通貫で見直す3つのポイントではどうすればいいのか。ポイントは、MQLとSQLの定義を、マーケだけで決めない、営業だけで決めない、ということです。両方の部門が、同じテーブルで、同じ言葉の中身をすり合わせていきます。 ①MQLの基準を、営業の結果から逆算するマーケ側のスコアリング指標を、営業側が実際に架電・商談してきた結果とセットで見直します。「スコアが高かったのに受注に至らなかったリード」に共通するパターンは何か。「スコアは低かったけれど受注できたリード」にはどんな文脈があったか。これを定期的に突き合わせることで、MQLの基準自体を、受注に近づける方向に調整していきます。 ②SQLの基準を、感覚ではなく言葉にする営業側がSQLと判断する基準も言語化します。「決裁権がある」「予算感がある」「検討時期が3ヶ月以内」といった条件を、感覚ではなく共通の言葉にする。そうすることで、マーケが渡すリードの温度感と、営業が求めている基準の間にあるギャップが、初めて可視化されます。 ③スコアだけで動かず、文脈確認のワンクッションを置く料金ページを何度も見ている、事例動画を最後まで見た、というアクションは確かに強いシグナルです。ですが、そこにインサイドセールスが実際に架電して、決裁権や予算、検討タイミングといった文脈を一言二言確認する。このワンクッションがあるだけで、商談化の精度はまったく変わってきます。これは以前の号でお伝えした架電設計やトスアップ設計にもつながる話ですが、結局のところ、KPI設計・情報設計・プロセス設計の三本柱は、この「定義