MQLとSQLの違い｜判定基準・SLA・受け渡しシート
MQLはマーケティングが営業検討に適すると判断したリード、SQLは営業が確認し具体的な商談検討に進めると判断したリードを指します。ただし、判断条件やステージ名は企業・CRMで異なります。用語を導入するだけで部門間の認識がそろうわけではありません。
必要なのは、「誰が、どの証拠を見て、次に何をするか」を合意することです。SQLと商談案件を同じ状態にするのか、別ステージにするのかも明記します。
MQL・SQL・商談を分ける例
ステージ | 本記事の運用例 | 次の確認 |
|---|---|---|
Lead | 連絡可能な見込み顧客情報を取得 | 重複、対象適合、連絡条件 |
MQL | 対象適合と検討シグナルを確認 | 営業が相談の目的を確かめる |
SQL | 営業が課題と次の検討を確認 | 案件化の条件を整える |
商談案件 | 提案・評価する案件として管理 | 関係者、予定、金額等を更新 |
受注 | 自社の成立条件を満たす | 売上・継続利用は別途追跡 |
これは設計例です。資料DLを一律MQL、電話がつながればSQLといったルールが自社の目的に合うとは限りません。対象外の相談や既存顧客の支援依頼も区別します。
引き渡す条件と受け入れる条件をそろえる
確認項目 | マーケティング側 | 営業側 |
|---|---|---|
対象適合 | 業務課題と提供範囲の一致 | 実際の利用条件を確認 |
意向 | 本人の相談・比較等の行動 | 次に検討したいことを確認 |
情報 | 根拠、日時、取得経路 | 不明点を質問し更新 |
対応 | 担当へ通知、期限を設定 | 受入・保留・対象外を記録 |
連絡条件 | 同意・拒否・希望を引継ぐ | 希望に沿って連絡 |
営業日、休日、担当不在時の扱いを含めた対応目標を決めます。例えば翌営業日までの受入判断を置く場合、受入は「成約見込みを保証すること」ではなく「責任者を決めて確認を始めること」と定義できます。
差し戻しを学習できる記録にする
「質が悪い」だけでは改善できません。対象外、検討時期が先、重複、情報不足、連絡不成立、対応能力不足などに分け、何を変えれば再検討できるか記録します。情報不足であれば、営業が確認すべきことまでマーケティングへ押し返していないかも見ます。
保留の案件には再確認日または条件を設定します。配信停止や明確な拒否がある相手を、再育成リストへ自動で戻さないことも重要です。
同じ100件で転換率を計算する
説明用の例として、ある月のMQL100件を60日間追跡し、営業受入80件、SQL40件、商談30件、受注6件だったとします。
指標 | 計算 | 結果 |
|---|---|---|
MQL受入率 | 80÷100 | 80% |
MQL→SQL率 | 40÷100 | 40% |
受入→SQL率 | 40÷80 | 50% |
SQL→商談率 | 30÷40 | 75% |
商談→受注率 | 6÷30 | 20% |
60日時点で進行中の案件があるなら、最終結果ではないと注記します。今月のMQLと過去月由来の受注を割るだけでは、同じ集団の転換率になりません。率と一緒に実数、観測期間、未確定件数を示します。
営業連携シートと週次レビュー
シートは、案件ID／取得日・取得元／課題と本人の言葉／適合根拠／意向・時期／連絡条件／現在ステージ／担当／次の行動・期限／差し戻し理由をそろえます。CRMの入力項目は、実際の判断に使うものから始めます。
週次では未対応・期限超過・理由未記入を解消し、月次では獲得元別の受入と進行を比較します。広告単価が低くても有効案件に進まなければ獲得条件を見直します。一方、営業負荷や提案の問題も分けて扱い、部門の責任追及だけで終わらせないようにしましょう。
共通定義は固定して終わりではありません。新しい商品、対象顧客、営業体制に変わったときに版を更新し、過去データと単純比較できなくなる部分を明記します。
関連するガイド
数値を継続して振り返る
広告データの集約・比較・レポート作成を継続したい場合は、NeX-Rayの対応媒体と機能を確認できます。必要な分析機能とプランを確認して、無料で始めるから試してください。
