BtoBのリード定義 ― MQLとSQLを分ける

資料請求も、問い合わせも、展示会で交換した名刺も、まとめて「リード」と呼んでいませんか。この状態だと、リード数が増えても商談が増えません。数えているものの中身が違うからです。この記事では、リードをMQLとSQLに分け、自社の基準を決める手順を説明します。

MQLとSQLの分け方は、1つの会社の案件に当てはめて追うと具体的になります。以下では次の架空の会社を例に、定義から数字の見方までを通して説明します。

MQLとSQLの違い

用語は英語の略ですが、覚えるべきは誰が「進めてよい」と判断したかの違いです。リードは連絡先が分かっただけの状態で、まだ誰も判断していません。そこからマーケティング側が選んだものがMQL、営業側が受け入れたものがSQLです。

呼び方	意味	判断する人
リード	連絡先が分かった人すべて	判断なし
MQL	営業に渡してよい、とマーケ側が判断した人	マーケティング
SQL	商談として追う、と営業側が受け入れた人	営業

重要なのはSQLは営業が決める点です。マーケ側が「有望なリードだ」と言っても、営業が追わなければ商談にはなりません。兼務の小さな組織で同じ人が両方を担う場合でも、「渡す判断」と「追う判断」を別の基準として書き分けておきます。

事例の会社に当てはめた、文章での定義の例です。MQLの条件には、後の「基準の決め方」で受注案件と失注案件を比べて残った2つを使っています。

• リード：資料請求、問い合わせ、展示会の名刺交換のいずれかで連絡先が分かった人
• MQL：リードのうち、従業員50名以上の会社に属し、かつ相談内容に導入時期が書かれている人。判断するのはマーケ担当で、毎週月曜に前週分を判定する
• SQL：MQLのうち、営業が最初の連絡で「検討の時期」と「相談の窓口となる担当者」を確認でき、商談として追うと決めた人

このように、条件・判断する人・判断する時機の3つを書いておくと、担当が変わっても同じ数え方が続きます。「有望そうな人」のような言葉は、人によって受け取り方が変わるので定義に使いません。

当てはまらない場合もあります。問い合わせのほとんどが「見積もりがほしい」「話を聞きたい」という直接の相談で、資料請求や名刺交換の窓口がない会社です。この場合、リードとMQLはほぼ同じものになり、分けても手間が増えるだけです。リードとSQLの2段階で始め、資料請求などの窓口を作った時点でMQLを足してください。

基準の決め方

MQLの基準は、他社の事例をそのまま使えません。商材と商流が違えば、有望さの条件も変わるからです。材料は自社の過去の案件にあります。次の3つの手順で決めます。

1. 過去に受注した案件を並べる … 直近1年の受注案件を、最初の接点までさかのぼって一覧にする
2. 共通点を探す … 企業規模・業種、最初に見たページ（料金ページか用語解説か）、問い合わせの内容（具体的な相談か一般的な質問か）、役職（決裁に近いか）の軸で見る
3. 条件を2〜3個に絞る … 条件を増やすほど正確になるが、判定が回らなくなる

ここで気をつけたいのが、受注した案件だけを見ると共通点を過大評価することです。事例でいえば、受注10件のうち8件が「料金ページから来た」としても、失注40件のうち30件も料金ページから来ていたなら、それは受注の条件ではありません。失注案件にも同じ条件が当てはまっていないか、必ず確認してください。この落とし穴は生存者バイアス ― 成功事例だけを見ないで扱っています。

事例の受注10件と失注40件について、条件ごとに当てはまる割合を出します。

条件（仮の数字）	受注10件で当てはまる割合	失注40件で当てはまる割合
料金ページから来た	80%（8件）	75%（30件）
従業員50名以上	70%（7件）	25%（10件）
相談内容に導入時期が書かれていた	60%（6件）	20%（8件）

この表では、料金ページは受注と失注でほとんど差がなく、基準に向きません。差が大きいのは従業員数と導入時期の記載で、この2つがMQLの条件の候補になります。ただし受注は10件しかないので、1〜2件の違いで割合は10〜20ポイント動きます。半年後に件数が増えたところで、同じ表を作り直して確かめてください。

よくある失敗

定義づくりでつまずく場所は、だいたい決まっています。どれも「仕組みを先に作り、中身を後回しにする」という共通点があります。次の表で、自社があてはまっていないか確かめてください。

失敗	なぜ困るか／どうするか
スコアリングから始める	基準が無いまま点数だけ作ると、点数の意味を誰も説明できない。基準を決めてから点数にする
営業に相談せずにMQLを決める	渡された側が「追えない」と言うなら基準が間違っている。決める段階から営業を入れる
件数が少ないのに率で判断する	月数件の商談では、MQLからSQLへの転換率が大きく振れる。3か月分をまとめるなど母数を確保する

表に加えて、見落とされやすい失敗がもう2つ。1つ目は、定義を途中で変えたのに、変える前の月と同じ表で比べてしまうことです。MQLの条件を緩めればMQL数は増えますが、それは集客が良くなったのではなく、数え方が変わっただけです。定義を変えた日を記録し、比べるときは同じ定義の期間どうしで比べてください。

2つ目は、MQLの数そのものをマーケ担当の目標にしてしまうことです。数が目標になると、条件を少しずつ緩める動機が生まれ、営業に渡る案件の質が下がります。目標にするなら、MQLの数ではなく、SQLや受注につながった数を置くほうが安全です。この問題は指標が目標になると壊れるで詳しく扱っています。

特に2つ目は、定義を作った後も続けて確かめる必要があります。営業が受け入れなかったMQLについて、理由を一言ずつ記録しておくと、基準を直す材料になります。

分けた後に見る数字

定義を分けると、どこで詰まっているかが見えるようになります。リード数だけでは「増えたのに商談にならない」理由が分かりませんが、段階ごとの率なら落ちている場所が特定できるからです。見るのは次の3つの率です。

1. リード → MQL の率 … 低ければ、集めている層がずれている
2. MQL → SQL の率 … 低ければ、マーケと営業の基準がずれている
3. SQL → 受注の率 … 低ければ、商談の進め方か商材の問題

事例の直近半年の200件を、獲得元ごとに並べます（仮の数字）。

獲得元	リード（件）	MQL（件）／率	SQL（件）／率	受注（件）／率
展示会	120	18／15%	6／33%	1／17%
記事	40	24／60%	12／50%	3／25%
広告	40	18／45%	6／33%	2／33%
合計	200	60／30%	24／40%	6／25%

リード数だけを見ると、展示会が全体の6割を占める一番の獲得元です。しかしMQLになる率は15%と低く、受注は1件にとどまっています。記事経由はリードが展示会の3分の1ですが、SQLの数は2倍です。ただし受注は1〜3件の差なので、受注率の違いは偶然でも起こる大きさです。判断に使うのはMQLやSQLまでの率にとどめ、受注率は1年分たまってから見直してください。

どの段階で落ちているかによって、打つ手が変わります。獲得元ごとにこの3つを並べると、どの獲得元が商談につながっているかも分かります。事例でいえば、展示会はリードが多いがMQLになる率が低く、記事はリードが少ないがSQLになる率が高い、という違いです。記録の残し方はリードの獲得元を記録する ― 後から聞けないことをご覧ください。

よくある質問

Q. MAツールが無くても、MQLとSQLを分けられますか。
分けられます。リードの一覧を表計算ソフトに作り、「MQLか」「SQLか」「受注したか」の列を足して、判定した日と判定した人を書き込むだけで始められます。月に数十件までのリードなら、この形で十分に回ります。MAツールは、判定の件数が増えて手作業が追いつかなくなったときに検討してください。導入前に決めておくことはMAツールを入れる前に決めることにまとめています。

Q. 営業が「SQLにしない」と判断したリードは、どう扱えばよいですか。
捨てずに、理由を付けてマーケ側に戻します。「時期がまだ先」「予算が合わない」「担当者が決裁から遠い」など、理由ごとに扱いを分けると、次の連絡の時機が決めやすくなります。「時期がまだ先」のリードは、半年後にもう一度連絡する、といった形です。戻ってきた理由を月ごとに数えると、MQLの基準のどこがずれているかも見えてきます。

Q. 基準はどのくらいの頻度で見直せばよいですか。
半年に1回が目安です。それより短いと件数がたまらず、たまたまの偏りで基準を変えることになります。ただし、主力の商材を変えた、価格を大きく変えたなど、顧客の層が変わる出来事があったときは、その時点で見直してください。

まとめ

リードをひとまとめに数えていると、増えても商談が増えない状態に気づけません。マーケが渡すMQLと、営業が受け入れるSQLを分けることが出発点です。基準は自社の受注案件から作り、失注案件と比べて差のある条件を選びます。定義を営業と決め、3つの転換率で詰まる場所を探してください。