MQLとSQLの定義を社内で揃える

なお、TimeValue株式会社では、広告運用・クリエイティブ制作・LP改善・データ分析・AI導入までを一括で引き受けるWebマーケティング支援「KAIZEN」を提供しています。

現在、オンラインの無料マーケティング診断を毎月10社限定で実施中です。いまの数字を見ながら、どこから直すのが早いかを一緒に整理します。

今月の無料診断は残り4社です

無料マーケ診断を申し込む

広告からLPまで、まとめて見ます。オンラインで30分から対応しています。

定義が揃っていないと、何が起きるのか

MQLとSQLという言葉は、多くの組織で使われています。
その中身が文書になっている組織は、それほど多くありません。

文書がない状態でも、日々の運用は回ります。
問題が表に出るのは、数字を持ち寄って比べるときです。

数字は説明のための仮の値です。
マーケティングが報告するMQLが月200件、営業が認識しているのが月120件という差が出ます。

この80件の差の説明に、月次会議の前半が使われます。
原因の大半は、除外条件と計上のタイミングの不一致です。

差の説明に時間を使うこと自体が損失ですが、実害はその先にあります。
数字が一致しないと、率の計算が部門ごとに違う値になります。

マーケティングが分母を200件で計算した商談化率と、営業が120件で計算した商談化率は、同じ活動でも大きく違います。
どちらの率を使って逆算するかで、必要なリード数が変わります。

施策の評価も止まります。
ある月の施策が効いたかどうかを判定しようとしても、計上時期が違えば効果の出た月がずれます。

目標設定の段階でも影響が出ます。
過去の実績が複数の定義で混在していると、逆算に使う率が定まりません。

外部に委託している場合は、さらに層が増えます。
委託先が自社の管理画面で数えている件数が、社内のどちらの数字とも一致しない状態になります。

この状態が続くと、会議の参加者は数字を信用しなくなります。
信用されない数字をもとにした目標は、未達になっても誰も原因を追いません。

定義のない指標は、測るたびに値が変わります。
測るたびに変わる数字は、目標として置くことができません。

つまり、定義の不在は指標の不在と同じです。
指標の一覧に名前が並んでいても、判断には使えていません。

差の大きさより、差の中身を見る

部門間の差が80件あると分かった時点で、多くの組織は数字を合わせにいきます。
合わせにいく前に、差の中身を分解してください。

分解の軸は2つです。
除外条件の違いによる差と、計上時期の違いによる差です。

数字は説明のための仮の値です。
80件のうち50件が除外対象の混入、30件が計上時期のずれと分解できたとします。

この2つは、合意の難しさがまったく違います。
除外対象の合意には反対が出にくく、計上時期の合意は運用の変更を伴います。

分解せずに合意にいくと、簡単な論点と難しい論点が同じ議題になります。
難しいほうで議論が止まり、簡単なほうも決まらないまま会議が終わります。

MQLとSQLは、それぞれ何を指すのか

MQLとSQLの違いを、リードの質の段階として説明すると混乱します。
質は連続していて、どこで線を引くかが恣意的になるためです。

判断する主体で分けると、線の位置が明確になります。
MQLはマーケティング側の判断、SQLは営業側の判断です。

マーケティングは、渡す基準を満たしたかどうかを見ます。
営業は、追う価値があるかどうかを見ます。

同じリードについて、2つの部門が別々に判断する構造です。
この構造を残すことに意味があります。

マーケティングが渡したものを、営業がすべて追うとは限りません。
その差が数字として残らないと、渡し方の改善ができません。

MQLが200件でSQLが120件なら、渡したうちの4割が追われていないことになります。
この4割の中身を見れば、どの条件のリードが追われていないかが分かります。

追われていない理由は、質だけではありません。
営業の稼働が逼迫していれば、条件を満たしたリードでも後回しになります。

理由が質なのか稼働なのかは、SQLへの移行率と接触までの日数を並べると分かります。
移行率が下がり日数も伸びていれば、稼働側です。

判断の主体と、判断の基準

段階の名前そのものに意味はありません。
社内で別の呼び方をしているなら、そのまま使って構いません。

名前を英語の略語にそろえること自体には、実務上の利点がありません。
むしろ、社内の誰もが同じ意味で使える日本語のほうが、現場での誤用が減ります。

重要なのは、誰が判断した結果なのかが段階ごとに決まっていることです。
判断の主体が書かれていない段階は、数字が合わなくなったときに責任の所在が決まりません。

二段階にしなくてよい場合もある

リードの件数が少なく、営業が全件に接触する体制なら、段階を分ける必要はありません。
MQLとSQLがほぼ一致するため、2つ持つ意味がないためです。

目安は、月の件数と営業の人数の関係です。
1人あたり月20件程度までなら、全件に接触できる体制が成立します。

この状態で段階を増やすと、入力の手間だけが増えます。
入力の手間が増えると記録の精度が落ち、かえって数字が合わなくなります。

段階を増やすべきなのは、営業が選別せざるを得ない件数になったときです。
選別が発生した時点で、選別の結果を記録する必要が生まれます。

段階を増やすこと自体を目的にしないでください。
渡し方を改善するために差を可視化する、という目的から逆算して決めます。

定義は、誰が決めるのか

定義を決める順番を間違えると、合意まで数か月かかります。
最も多い失敗は、マーケティングが定義を作って提示することです。

渡す側が作った基準は、受け取る側から見ると常に緩く見えます。
提示された瞬間に、基準を厳しくする交渉が始まります。

交渉になると、合意の目的が質の担保から譲歩の量に変わります。
決まった定義も、双方が納得していないため運用で守られません。

守られない定義は、期中に自然に緩みます。
件数が足りない月に条件から外れたリードを渡す運用が始まり、翌月には定義書と実態が一致しなくなります。

順番を逆にしてください。
受け取る側である営業が、追いたい条件を先に出します。

出し方は、過去の受注案件から遡る形が最も具体的になります。
直近12か月に受注した案件のリードが、どんな条件を満たしていたかを挙げてもらいます。

この方法なら、条件が実績に基づきます。
感覚で挙げた条件と違い、なぜその条件かを説明できます。

営業が条件を挙げたら、マーケティングは該当件数を出します。
その条件を満たすリードが月に何件あるかという見通しです。

件数の見通しを添えないと、実行できない定義ができあがります。
条件を厳しくすれば質は上がりますが、月の該当件数が10件になれば事業が回りません。

条件ごとの該当件数を並べると、どこまで絞れるかがその場で分かります。
議論が、質と量のどちらを取るかという具体的な選択になります。

承認の場に経営が入る理由

両部門だけで決めると、どちらかが譲る形になります。
譲った側は、期中に前提を問い直します。

経営が同席し、この期は件数と質のどちらを優先するかを示すと、決まりやすくなります。
立ち上げ期なら件数、既存市場での収益改善なら質という判断です。

この優先順位は、事業計画から降りてくるものです。
両部門の判断で決められる範囲を超えています。

承認の場では、定義書に3つを明記してください。
条件、除外の対象、そして次に見直す時期です。

見直す時期を書いておくと、決定が最終的なものに見えなくなります。
最終的でないと分かると、譲った側も合意しやすくなります。

揃えるとき、何から合意していくのか

合意の順番には、効率のよい順があります。
難しい論点から始めると、そこで止まって簡単な論点も決まりません。

最初に決めるのは、外す対象です。
既存顧客からの問い合わせ、採用の応募、同業からの照会、学生や個人からの問い合わせ。

これらを外すことには、ほぼ反対が出ません。
先にここを決めると、部門間の数字の差の半分程度は解消します。

除外対象を決める作業には、もう1つの効用があります。
実際に過去1か月のリードを1件ずつ見る必要があるため、両部門が同じデータを同じ目で見る機会になります。

この作業を経ると、以後の議論の前提が揃います。
データを見ずに条件だけを議論すると、想像している対象がずれたまま話が進みます。

見る件数は、1か月分が多すぎる場合は無作為に30件を抜き出せば足ります。
30件見れば、除外すべき類型はほぼ出そろいます。

2番目に決めるのは、計上のタイミングです。
条件を満たした時点で数えるのか、営業に引き渡した時点で数えるのかを決めます。

この違いで、月をまたぐ件数が変わります。
月末に条件を満たしたリードを翌月に引き渡す運用なら、1か月分の差が常に残ります。

3番目は、判定に必要な情報の項目です。
どの項目が取れていないと判定できないかを決めます。

4番目に、渡す基準となる条件を決めます。
ここが最も議論が割れるため、最後に近い位置に置きます。

合意を進める順番

最後の項目を落とさないでください。
条件を満たさないリードをどう扱うかが決まっていないと、現場が独自に運用を始めます。

一度で完璧を目指さない

最初の定義は、3か月後に見直す前提で決めてください。
完璧を目指すと、決まらないまま時間だけが過ぎます。

3か月あれば、定義の実務上の問題はほぼ出そろいます。
判定できないリードが多い、例外が多すぎる、件数が想定と違うといった形で現れます。

見直しの場は、最初の合意のときに日程まで決めておきます。
日程が決まっていないと、問題が出ても誰も言い出しません。

見直しで変えるのは、条件の水準までにしてください。
段階の構造や計上のタイミングまで変えると、比較の基準が失われます。

3か月後の見直しを終えたら、次は四半期ごとの確認に移します。
以後は、実態と定義が離れていないかを確かめるだけの作業になります。

スコアリングで定義を作るのは、うまくいくのか

ツールを導入すると、スコアリングの設定画面が早い段階で現れます。
そこから始めると、定義の議論が点数の配分の議論にすり替わります。

点数方式の弱点は、根拠を説明しにくいことです。
役職に10点、企業規模に15点という配点の根拠を説明できる組織は多くありません。

根拠が説明できない基準は、営業から信頼されません。
信頼されない基準で渡されたリードは、点数が高くても後回しになります。

もう1つの弱点は、合計点が同じでも中身が違うことです。
役職が高いが規模が小さいリードと、規模が大きいが担当者レベルのリードが同じ点数になります。

この2つは、営業から見ると追い方がまったく違います。
点数だけを渡されると、判断に必要な情報が失われた状態になります。

点数を渡すときに内訳も併せて渡せば解決しますが、それなら最初から条件で渡すほうが早くなります。
点数化の利点は集計の簡便さにあり、判断の材料としての価値は条件のほうが高いためです。

条件の組み合わせで定義すると、この問題は起きません。
従業員規模、業種、役職、行動の4つで条件を組み、すべて満たしたものをMQLとします。

条件方式は、初期の設定が短時間で終わります。
議論すべきは4つの条件の水準だけで、配点表を作る必要がありません。

代わりに、細かい調整はしにくくなります。
条件を1つ緩めると該当件数が大きく動くため、微調整が効きません。

微調整が必要になるほど運用が成熟してから、点数化を検討してください。
最初から点数化すると、調整の余地が広すぎて誰も触らなくなります。

点数化するなら、受注実績から配点する

配点を感覚で決めないでください。
過去に受注した案件で、各条件がどれだけの割合で出現したかを見ます。

受注案件の80%で満たされていた条件と、30%でしか満たされていなかった条件では、重みが違います。
出現率の差をそのまま配点の比率に使うと、根拠が説明できます。

この作業には、受注案件が数十件は必要です。
年間の受注が10件程度の事業では、統計として成立しません。

件数が足りない事業では、点数化しないでください。
条件の組み合わせのまま運用するほうが、判断の根拠が残ります。

点数化したあとも、配点の根拠を文書に残します。
根拠のない配点は、担当者が代わった時点で意味を失い、誰も見直せなくなります。

定義を変えたとき、過去の数字はどうするのか

定義の変更は、過去との断絶を生みます。
その扱いを決めずに変えると、目標設定の根拠が失われます。

再集計できるかどうかは、情報が残っているかで決まります。
過去のリードに、新しい定義で判定できるだけの項目が記録されているかを先に確認してください。

従業員規模を新しい条件に加えた場合、過去のリードに従業員規模が記録されていなければ判定できません。
この確認を後回しにすると、再集計の作業を始めてから不可能だと分かります。

情報が残っている場合は、過去12か月を再集計します。
12か月あれば、季節性を含めた比較ができます。

一部の情報しか残っていない場合は、判定できる範囲で再集計します。
その際、どの範囲を再集計したかを明記してください。

明記がないと、再集計済みの数字と未再集計の数字が混ざります。
混ざった状態の数字は、どちらの定義でもない値になります。

情報が残っていない場合は、変更の時期を記録して比較を止めます。
新しい定義での実績が12か月揃うまで、前年同期比は使えません。

この期間は、前月比と計画値との比較で運用します。
比較の相手がないことを明示しておけば、誤った読み方は避けられます。

明示の方法は、月次の資料に注記を1行入れることです。
注記がないと、半年後に着任した担当者が前年同期比を計算し、定義変更による差を施策の成果として報告します。

移行期間は二つの数字を並べる

変更の前後3か月程度は、旧定義と新定義の両方で集計してください。
両方を並べると、その差が定義変更による影響そのものになります。

数字は説明のための仮の値です。
旧定義で200件、新定義で150件なら、定義変更で25%減ったことになります。

この影響の大きさが分かれば、過去との比較に補正を掛けられます。
補正を掛けた比較は正確ではありませんが、傾向の判断には使えます。

両方で集計する作業は手間がかかりますが、3か月で終わります。
この3か月を惜しむと、以後1年間は過去との比較ができません。

変更そのものは、期の切り替えで行ってください。
期中の変更は、目標値の前提を崩します。

緊急で変更が必要になるのは、定義に明らかな欠陥があった場合だけです。
除外すべき対象が含まれていたといった場合で、この場合は期中でも直します。

定義を運用に乗せるには、何が要るのか

定義書ができた時点で終わりにすると、運用は定着しません。
3か月ほどで、担当者ごとの解釈の違いが積み重なります。

最初に必要なのは、判定の自動化です。
条件による判定なら、ツール上のルールとして設定できます。

人が毎回判断する形にすると、担当者ごとに判定が揺れます。
繁忙期には判断が甘くなり、月末には件数を作るために緩みます。

自動化には、判定に使う項目が取れていることが前提になります。
フォームで取得していない項目を条件に入れると、判定不能なリードが大量に出ます。

一方で、フォームの項目を増やすと入力の離脱が増えます。
判定に本当に必要な項目だけに絞ってください。

不足する情報は、後から補う経路を用意します。
企業規模や業種は、社名から後で付与できることが多くあります。

後から補う運用にする場合は、補うまでの猶予を決めてください。
猶予を決めないと、判定待ちのリードが滞留し、営業に渡るまでの日数が伸びます。

2つ目に必要なのは、例外の扱いです。
条件を満たさないが明らかに有望な案件は、必ず出ます。

例外として渡す経路を用意し、例外の件数を記録してください。
経路がないと、現場が個人的な連絡で渡し始めます。

個人的な経路で渡されたリードは、どちらの数字にも入りません。
数字が合わない原因が、また1つ増えることになります。

例外が全体の2割を超えたら、定義そのものを見直してください。
2割が例外なら、条件が実態に合っていません。

定義書に管理者を明記する

定義書には、管理の責任者を1人明記してください。
担当者が変わっても定義が引き継がれる状態を作るためです。

管理者の役割は、四半期ごとに条件と実態が離れていないかを確認することです。
確認の材料は、例外の件数と判定不能なリードの件数です。

管理者を決めないと、問題が見つかっても誰も直しません。
直す権限が誰にあるかが不明なため、次の会議に持ち越されます。

定義書の保管場所も、1か所に固定します。
複数の場所に写しがあると、更新されていない版が参照されます。

更新したときは、変更した内容と日付を同じ文書に追記してください。
変更履歴があれば、過去の数字を見るときにどの定義かが判別できます。

改善の順番をどう決めるか

定義合わせは、差の確認から始めます。
差がどれだけあるかを知らないまま合意にいくと、何を決めるべきかが決まりません。

突き合わせは、直近1か月の同じ期間で行ってください。
期間がずれていると、差の原因に期間の違いが混ざります。

実行の並び

この6工程で、着手から運用開始まで9週間前後が目安になります。
期初に間に合わせるには、前の期の第3四半期のうちに工程1と2を終えておく必要があります。

数字は説明のための仮の値です。
マーケティングの報告が月200件、営業の認識が120件なら差は80件です。

除外対象の混入が50件、計上時期のずれが30件と分解できれば、合意すべき論点は2つに絞られます。
分解しない状態で会議を開くと、80件という数字の大きさだけが議題になります。

効果を見る指標

このうち最初に見るのは、部門間の差です。
差がゼロに近づくまで、他の数字を見ても判断できません。

数字が一致しない段階で目標値を置くと、達成の判定ができません。
一致を確認してから、目標の議論に入ってください。

一致したあとに見るのは、MQLからSQLへの移行率です。
移行率が低ければ渡す基準が緩く、高すぎれば厳しすぎます。

移行率の水準そのものに正解はありません。
自社の3か月の実績を基準に、下がったか上がったかで判断してください。

移行率が下がったときは、リードの質と営業の稼働の両方を確認します。
接触までの日数が伸びていれば稼働側、日数が同じなら質の側です。

この確認を毎月続けると、定義を見直すべき時期が自然に見えてきます。
移行率が3か月続けて下がっている場合は、条件の水準が実態から離れています。

MQLとSQLの定義が揃っていない状態が分からない場合は、無料相談で現状を見てもらうところから始められます。
リードの受け渡しの仕組みごと見直す段階ならWeb集客改善サービスもあります。

よくある質問

まとめ