MQLとSQLの違いは？営業とマーケティングで判断をそろえる方法

MQL（Marketing Qualified Lead）は、マーケティング担当が「営業で確認する価値がある」と判断した見込み客です。SQL（Sales Qualified Lead）は、営業担当が情報を確かめ、次の営業対応を進める対象と判断した見込み客です。どの条件を満たせばMQLやSQLにするか、SQLと商談を同じ状態にするかは会社や使用するシステムで異なります。

大切なのは、名前を付けることよりも、誰が、何を根拠に判断し、次に何を確認するかをそろえることです。資料を受け取ったこと、営業に通知したこと、営業が引き受けたことは、それぞれ別の出来事です。それだけで商談が成立したとは言えません。

設備点検会社への相談を例に、MQLの判定から営業の確認までを追います。

MQLとSQLは、判断する人と確認する内容が違う

HubSpotの公式資料では、既定の区分としてMQLはマーケティングが営業へ渡せると判断した人や企業、SQLは営業が潜在顧客と判断した人や企業です。取引に関連付いた「Opportunity」は別の区分として説明されています。これは同製品の既定例で、すべての会社が同じ段階や基準を使うという意味ではありません。自社の定義を、使っているCRMの設定と一緒に確かめてください。

「リード」は、ここでは将来の取引につながる可能性のある人や企業を指します。問い合わせが届いた人を個人単位で数えるのか、会社単位でまとめるのかも、自社で決める必要があります。

一つの相談で、判定から次の行動まで追う

設備点検会社に、A市の工場から「換気設備の定期点検を依頼できるか」という問い合わせが1件届いたとします。連絡に関する利用目的と希望は、会社が確認できる記録で確かめるものとします。

この会社の仮の基準は、マーケティング担当が「対象地域・設備の種類・具体的な相談」を確認できたら営業へ渡す候補とし、営業担当が「型式と設置場所を確認し、対応範囲と次の相談を判断できる」場合にSQLとする、というものです。これは教材の基準であり、他社へそのまま適用するものではありません。

1. 受付

   A市の工場、換気設備、定期点検についての相談を確認。型式は未確認。受付1件として残す。問い合わせだけでSQLや商談にしない。

2. マーケティング

   仮のMQL条件に合う情報を確認。MQLと判定し、相談内容・根拠・型式未確認を営業へ渡す。

3. 営業への通知

   担当者へ通知した記録がある。通知済み。営業本人の受領・引受はまだ確認できない。

4. 営業の確認

   担当者が内容を受け取り、型式が不足していると判断。確認待ち。通知や受領だけでSQLにしない。連絡できる条件を確認してから型式を尋ねる。

5. 回答後の判断

   型式を確認でき、自社の対応範囲に合い、次の相談を希望したと仮定。営業がSQLと判定。商談を登録するかは会社の別の条件で確認する。

最後の段階は、必要な回答が得られた場合の分岐です。実際に顧客へ連絡した結果や商談があったという意味ではありません。型式が分からないままなら、SQLの判断を保留します。対応範囲外と確認された場合は、その理由を記録し、同じ案件を無理に進めません。

たとえば資料を受け取った後に「連絡は不要です」と本人が答えた場合、返信があったという理由だけで営業への連絡候補にしません。本人の希望と利用目的、自社の連絡ルールを確認し、連絡しない扱いを記録します。資料の受領や返信そのものは、購入意思や連絡への同意を証明しません。

通知・受領・SQL・商談を混ぜない

営業担当へメッセージを送っても、本人が見たか、引き受けたかは別です。受け取った後も、営業が必要な条件を確認できなければSQLの判断は保留できます。SQLと判断しても、提案のための商談を別途登録する運用なら、登録前に商談件数へ加えません。

• 通知：マーケティング担当が営業へ確認を依頼した。
• 受領・内容確認：営業担当が通知を受け取り、内容を確認した。確認しただけでは引受やSQL判定を意味しない。
• 引受・保留：営業担当が担当するか、情報不足などで保留するかを判断し、結果と理由を返した。
• SQL：営業が自社で決めた条件を満たすと判断した。
• 商談：自社が定めた案件・商談の登録条件を満たした。

同じ相談の各状態は一つの履歴としてつなぎ、通知1件とSQL1件を足して別々の相談2件としません。通知した時刻と営業が引き受けた時刻の残し方は、MQLの判定・通知・引受を分ける記事で詳しく説明しています。

判断が食い違ったら、根拠と不足を同じ記録で確かめる

マーケティングがMQLとした相談を、営業が確認待ちとすることはあります。これは、どちらかの判断が必ず間違いということではありません。判断した時点で見えていた情報が異なる場合もあります。

先ほどの例では、マーケティングは地域・設備・相談内容を確認しました。営業は、型式がなければ対応範囲を判断できません。そこで元のMQL判定を消さず、「型式未確認」「確認する担当」「確認方法と期限」を同じ相談の履歴に残します。確認後に営業が対応可能と判断したら、その根拠と日付を追記します。期限は社内で決める確認予定であり、本人へ連絡してよいという許可ではありません。

営業が対象外や情報不足とした場合の戻し方は、営業が受け取れないリードの再確認でも扱っています。点数の高さと対象への適合を分ける判断は、リード点数と適合性の見方を参照してください。

件数を比べるときは、同じ対象と期間をそろえる

数を比べるときは、同じ受付群について、どの時点まで追ったかをそろえます。たとえば4月にMQLと判定した20件を、6月末まで追った結果、営業がSQLと判定した相談が8件だったとします。この例のMQLからSQLへの割合は 8件 ÷ 20件 × 100＝40％ です。

残る12件の内訳が未確認なら、すべて対象外・失注とは言えません。6月末時点で保留中のものがあれば、未確定として別に残します。また、4月にMQLとなった20件と、以前の月に受け付けた相談から生じた6月のSQL件数を割っても、同じ受付群の割合にはなりません。

分母のMQLが0件なら、割合は計算できません。「0％」と記録せず、対象となるMQLがないため算出できないと示します。人、会社、問い合わせのどれを1件とするか、期間と判断条件の版も一緒に記録してください。

まず、判断が分かれた相談を一つ確認する

マーケティング担当と営業担当で、同じ相談の記録を一つ開きます。次の順に確かめれば、用語の違いを社内の仕事へ結び付けられます。

1. マーケティングは何を根拠に営業へ渡したか。
2. 営業は内容を受領・確認したか。必要な情報は何か。
3. SQLとするか、保留・対象外とするか。誰が、いつ判断したか。
4. 商談は別の条件で登録するか。本人の連絡希望はどう記録するか。
5. 判断条件を変えるなら、変更日と版を残し、過去の数字と比較できる範囲を確認する。

担当間で条件が決まったら、次の相談でも同じ方法で記録し、判断しにくかった理由を見直します。条件を追加する前に、今ある記録から確認できる情報を使ってみましょう。

参考資料

• HubSpot：Use contact and company lifecycle stages — 同製品の既定ステージとカスタマイズを確認。2026年11月4日確認。自社の判定条件や商談成果を示すものではありません。

関連する支援を見る