MQLとSQLの違い｜定義・判定例・営業への受け渡しルール

HubSpotの公式資料では、MQLはマーケティングが営業へ渡せると判断した段階、SQLは営業が潜在的な顧客として判断した段階とされています。同資料では段階をカスタマイズできることも示されています。名称と実務上の条件をセットで決めてください。

資料請求や面談予約を判定条件に使うこと自体が誤りではありません。ただし、対象外企業や単なる情報収集をどう扱うかまで決めないと、同じ件数でも意味が変わります。

次はSaaSの法人営業を想定した仮の定義例です。予算確定や決裁者参加を全案件の必須条件にしたものではありません。

同じ会社に複数の担当者や複数案件がある場合は、企業・担当者・案件のどれを数えるかも決めます。担当者2人から問い合わせがあっただけで、同じ導入案件を2件のSQLとして数えないようにします。

迷った案件は点数を足して決着させるより、判定を変える未確認事項を一つ特定します。予算や時期に関する質問の聞き方は、顧客の検討段階に合わせて調整してください。

「営業へ渡した」で終わらせず、受け手が返す結果を統一します。

• 受け入れ：SQL条件を満たす根拠と、次の担当・行動を登録する。
• 追加確認：不足項目と確認する人、期限を登録する。連絡が取れない場合も状況を残す。
• 保留：今は進めない理由と再検討の時期を記録する。再連絡は相手の意向を確認する。
• 対象外：非対応用途など、確定した理由を記録する。単に情報が足りない状態とは分ける。

例えば「引き渡し後、翌営業日中に担当者を決める」という取り決めを置く場合も、自社の営業時間や対応可能件数に合わせた運用例として設定します。実行できない期限を形だけ設けず、担当不在時の引き継ぎ先も決めます。

MQLからSQLへの移行率は、同じ対象群を追って集計します。例えば、ある月にMQLになった架空の20件のうち、所定の観測期間で6件がSQLへ進めば30％です。これは計算例であり、目標値や業界平均ではありません。

今月のSQL件数に過去月のMQLが含まれる場合、「今月SQL ÷ 今月MQL」では移行状況を正しく比較できません。対象期間、観測期限、対象単位、未判定件数を併記してください。

週次の見直しでは、差し戻し理由を「対象条件」「情報不足」「時期」「重複」に分け、代表案件を共同で判定します。低い移行率を担当者の問題と決めつけず、流入元や定義の変更も確認します。