MQL と SQL と SAL の違いとは？定義、受け渡し基準、よくあるずれを整理する
MQL と SQL と SAL の違いを、用語の暗記ではなく、営業とマーケの受け渡し基準として整理します。BtoB ではよく使われる言葉ですが、実務では会社ごとに定義がぶれやすく、同じ言葉を使っているのに話が噛み合わない原因になりがちです。
結論から言うと、MQL はマーケが営業へ渡す候補、SAL は営業またはインサイドセールスが受け入れた状態、SQL は商談化条件を満たした状態と置くと整理しやすくなります。大事なのは名称そのものより、誰が受け取り、どの条件で次工程へ渡し、どの条件で戻すかをそろえることです。
本記事のポイント
- MQL はマーケが営業へ渡す候補、SAL は営業またはインサイドセールスが受け入れた状態、SQL は商談化条件を満たした状態と整理するとずれにくくなります。
- 定義が崩れる最大原因は、件数目標だけを先に置き、受け渡し条件と戻し条件を CRM や MA に落としていないことです。
- 改善の順番は、SQL 条件の固定、SAL の要否判断、MQL 条件の整理、運用 KPI の設計です。
MQL と SQL と SAL は「役割」と「受け渡し点」で分けると理解しやすい
この3つは、温度感を細かく点数化するための言葉ではありません。営業とマーケ、あるいは インサイドセールス の間で、どの状態を次工程へ渡すかを決めるための言葉です。
| 用語 | 意味 | 主に持つ部門 | 次に起こること |
|---|---|---|---|
| MQL | マーケティング側から見て、営業接続を検討できる状態 | マーケティング | 営業またはインサイドセールスへ渡す候補になる |
| SAL | 渡されたリードを営業またはインサイドセールスが受け入れた状態 | 営業 / インサイドセールス | 初回接触やヒアリングへ進める |
| SQL | 商談化条件を満たし、営業案件として扱う状態 | 営業 | 案件化、提案、受注プロセスへ進む |
MQL と SQL だけで運用している会社もありますが、その場合は「営業が受け取ったかどうか」が見えにくくなります。インサイドセールス SLA を運用している会社ほど、SAL を挟んだ方が責任点が明確になりやすくなります。
MQL、SAL、SQL の違いは、見込み度のラベルではなく、部門をまたぐ受け渡しの定義です。
なぜ定義がずれやすいのか
このテーマがややこしくなるのは、言葉だけ導入して運用条件が入っていない会社が多いからです。たとえば、資料請求したら全件 MQL とする会社もあれば、役職や業種条件まで満たして初めて MQL とする会社もあります。どちらが正しいというより、営業との合意がないまま使うとずれます。
件数目標が先に立つ
MQL 数を増やす目標だけ先に置くと、営業が追う価値の低いリードまで流れやすくなります。結果として、営業は MQL を信用しなくなります。
受け入れ条件が明文化されていない
SAL を定義していない会社では、「営業が見た」「営業が連絡した」「営業が追う価値ありと判断した」が混ざりやすくなります。これでは受け渡しの責任点が曖昧です。
戻し条件がない
まだ早い案件をどう戻すかが決まっていないと、SQL にならなかったリードがそのまま消えやすくなります。リードナーチャリング と接続して戻し先を決める必要があります。
実務で定義するときの順番
定義づけは MQL からではなく、SQL から決める方が崩れにくくなります。営業が「ここまで来たら商談として追う」と言える条件が決まらない限り、その前段の MQL や SAL も曖昧なままだからです。
1. まず SQL 条件を決める
導入時期、対象部署、課題の明確さ、次回打ち合わせ設定など、営業案件として扱う条件を先に固定します。ここは BtoBマーケティング KPI の受注逆算ともつながります。
2. SAL を挟むか決める
営業が直接リードを受けるのか、インサイドセールスが一次判定するのかで SAL の意味は変わります。インサイドセールスがある会社では、営業へ渡る前の「受け入れた」状態を別に持つ方が運用しやすくなります。
3. MQL を行動と属性で決める
資料請求、ウェビナー参加、料金ページ閲覧のような行動だけでなく、業種、役職、対象部門、会社規模などの属性も合わせて定義します。マーケティングオートメーション を使う会社ほど、行動だけに寄せると件数偏重になりやすくなります。
4. CRM / MA / SFA に落とし込む
定義を文書で決めても、管理画面のステータスや戻し先が一致していなければ運用できません。ステータス名、戻し理由、通知条件までシステムへ落とし込みます。
| 決めること | 例 | 曖昧だと起きること |
|---|---|---|
| SQL 条件 | 課題顕在化、対象部門一致、次回打ち合わせ設定あり | 営業案件の質がばらつく |
| SAL 条件 | 営業または IS が受け取り、初回接触に進めると判断 | 受け取ったのか放置なのか判別できない |
| MQL 条件 | 役職条件と行動条件の両方を満たす | マーケ都合で件数だけ増える |
| 戻し条件 | 時期未定、権限者不在、課題未顕在 | 案件が消えるか、営業が無理に追う |
運用で見るべき KPI
MQL 数だけでは、定義が機能しているか分かりません。少なくとも次のように、受け渡しの前後を見る方が実態に近づきます。
- MQL から SAL への転換率
マーケが渡した候補が、実際に受け入れられているかを見ます。 - SAL から SQL への転換率
受け入れた案件が本当に商談化条件を満たしているかを見ます。 - 戻し理由比率
時期未定、対象外、情報不足など、どこで定義がずれているかを見ます。 - 初回接触速度
SAL に入ったあと動けているかを見ます。ここは インサイドセールス KPI と一緒に見る方が自然です。
この4つが見えていれば、件数が足りないのか、定義が緩いのか、営業連携が止まっているのかを切り分けやすくなります。
よくある失敗パターン
MQL を問い合わせ件数の言い換えにしてしまう
全件を MQL 扱いすると、営業から見ると意味のないステータスになります。MQL はマーケから営業へ渡す候補であり、単なる流入件数ではありません。
SAL を置かず、営業が見たかどうかを測れない
営業が受け取ったのか、まだ未着手なのかが分からないと、責任の所在が曖昧になります。インサイドセールスを挟む会社ほど SAL の有無が効きます。
SQL を受注見込みと混同する
SQL は商談化条件を満たした状態であって、受注確度の高低とは別です。案件管理やパイプライン管理の段階とは分けて持つ方が整理しやすくなります。
よくある質問
SAL は必ず必要ですか？
必須ではありません。ただし、営業とマーケの間にインサイドセールスがいる会社や、営業が受け取ったかどうかを可視化したい会社では置く価値があります。
MQL と SQL の違いだけで十分ではないですか？
十分な場合もあります。営業が直接すべてのリードを受ける小規模組織なら、MQL と SQL だけで回ることがあります。ただし、受け取り判断の責任点が曖昧なら SAL を入れた方が運用しやすくなります。
MQL は行動だけで判定できますか？
おすすめしません。資料請求やセミナー参加だけでは、営業が追う価値が高いとは限りません。役職、業種、対象部門などの属性条件も合わせる方がずれにくくなります。
SQL は商談設定だけで決めてよいですか？
商談設定だけだと緩すぎる場合があります。課題顕在化、対象部門一致、次回打ち合わせの目的が明確かなど、最低限の条件を合わせて置く方が再現性があります。
関連ページと関連記事
MQL、SAL、SQL の違いを整理したあとに、SLA、KPI、ナーチャリングの順で見ていくと、定義が運用へつながりやすくなります。
- BtoBマーケティング KPIとは？見るべき指標と設計順を実務で整理する：MQL や SQL をどの順で KPI に落とすかを整理できます。
- インサイドセールス SLAとは？営業とマーケの受け渡し基準を実務で整理する：SAL を置くべきか、どう受け渡し基準を決めるかを補えます。
- インサイドセールス KPIとは？見るべき指標、設計順、改善の進め方を実務で整理する：受け渡し後の初回接触や有効商談率の見方を整理できます。
- リードナーチャリングとは？MOFUファネルの設計と実践ステップ：戻し条件を決めたあと、どう再育成するかを確認できます。
- マーケティングオートメーションとは？MAの役割と導入判断：MQL 条件を MA にどう落とし込むかを整理できます。
- SDR と BDR の違いとは？役割・KPI・分担の考え方を整理する：営業接続の役割分担を細かく見直したい場合に役立ちます。
MQL、SAL、SQL の定義を、自社の営業とマーケの受け渡しに合わせて揃えたい場合
記事で整理した定義を、自社の KPI や運用フローに合わせて実行順へ落とし込みたい場合は、BtoBマーケティング施策一覧も確認しておくと進めやすくなります。