MQL・SQL・SALの違いとは？営業に渡す基準と失敗しない定義方法
MQL、SQL、SALは、BtoBマーケティングと営業連携でよく使われるリードステージです。しかし、名称だけを導入しても、営業に渡す基準が曖昧だと「質の低いリードが来る」「営業が追わない」という問題が起きます。
この記事では、MQL、SQL、SALの違い、受け渡し基準、CRM/MA/SFAで管理すべき項目、よくあるずれと改善方法を整理します。
MQLはマーケティングが営業へ渡す候補、SALは営業やインサイドセールスが受け入れた状態、SQLは商談化条件を満たした状態です。重要なのは名称ではなく、どの条件で渡し、誰が受け取り、どの条件で戻すかを決めることです。
本記事のポイント
- MQL、SAL、SQLは部門ごとの呼び名ではなく、リードをどの条件で次工程へ渡すかをそろえるための定義です。
- 件数目標だけでMQLを増やすと営業が信用せず、SQL化率が下がります。受け渡し条件と戻し条件を先に決める必要があります。
- CRM、MA、SFAでは、スコア、行動履歴、会社属性、営業受け入れ、商談化理由を同じルールで残すことが重要です。
この記事で扱うテーマ
関連キーワード
- MQL SQL SAL
- MQL SQL 違い
- SAL SQL 違い
- MQL 判定基準
- SQL 条件
- リード 受け渡し 基準
- MQL 定義
- 営業 マーケ 連携
このページで答える質問
- MQL・SQL・SALの違いは何か？
- 営業に渡す基準はどう決めるか？
- MQL定義がずれる原因は何か？
- CRM/MA/SFAで何を管理するか？
MQL・SAL・SQLの定義
MQLはMarketing Qualified Leadの略で、マーケティング上の条件を満たしたリードです。資料DL、ウェビナー参加、特定ページ閲覧、会社属性などをもとに判断します。
SALはSales Accepted Leadで、営業またはインサイドセールスが受け入れた状態です。すべての会社に必要ではありませんが、マーケティングと営業の間に確認工程を置きたい場合に有効です。
SQLはSales Qualified Leadで、商談化に進める条件を満たしたリードです。予算、課題、導入時期、決裁関与、具体的な要件などを確認して判断します。
営業に渡す基準の作り方
最初に決めるべきなのはSQL条件です。営業が本当に追う価値がある条件を定義し、そこから逆算してMQL条件を作る方がずれにくくなります。
MQL条件には、属性条件と行動条件があります。属性条件は業種、従業員規模、役職、既存顧客かどうかなどです。行動条件は資料DL、料金ページ閲覧、セミナー参加、問い合わせ内容などです。
SALを置く場合は、営業が受け入れない理由も定義します。対象外業種、競合、学生、営業対象外地域、情報不足など、戻し条件をCRMに残すと改善できます。
よくあるずれと改善方法
よくある失敗は、MQL件数だけをKPIにして営業の受け入れ率を見ないことです。営業が追わないリードを増やしても、商談化率は上がりません。
もう一つの失敗は、スコアリングを細かく作りすぎることです。点数が高い理由が営業に伝わらなければ、実務では使われません。点数より、どの行動があったかを見える形で残すことが重要です。
改善するには、SQL化したリードと失注したリードを月次で見直し、MQL条件を調整します。営業の感覚ではなく、CRM上の履歴と商談結果をもとに見直すと、部門間の議論が進みやすくなります。
AIを使う場合の注意点
AIは、問い合わせ文の要約、会社情報の補完、行動履歴からの優先順位付けに向いています。営業が読む前にリードの文脈を整理できるため、初動の質が上がります。
ただし、AIスコアだけでSQLにするのは危険です。なぜ高スコアなのか、どの行動や属性を根拠にしたのかを営業が確認できる必要があります。
AIを使うなら、判定理由、次の推奨アクション、営業のフィードバックをCRMに残し、MQL条件を継続的に見直す運用にしてください。
実装手順と運用チェックリスト
MQL定義を作るときは、営業が過去に商談化したリードを先に見ます。成功したリードの行動、会社属性、問い合わせ内容を洗い出し、その共通点をMQL条件に反映します。
SQL条件は営業が会話を始められる具体性で決めます。課題、時期、対象部門、導入背景が分からないままSQLにすると、初回対応が確認作業だけで終わってしまいます。
実装は、現状の数字を確認するところから始めます。流入数、資料DL、問い合わせ、MQL、SQL、商談、受注のうち、どこまで計測できているかを確認してください。数が取れていない段階があれば、記事や広告を増やす前に計測点を整えます。
次に、各段階の責任者を決めます。マーケティングが見る段階、インサイドセールスが確認する段階、営業が商談化する段階を分けると、リードの受け渡しが安定します。責任範囲が曖昧なままだと、良いリードでも対応が遅れます。
最後に、月次で見直す項目を固定します。クリックや表示回数だけではなく、次段階へ進んだ割合、営業が受け入れた割合、商談化した理由、失注した理由を見ます。この見直しを続けることで、ファネルは一度作った図ではなく、改善し続ける運用になります。
| 確認項目 | 見る内容 | 改善アクション |
|---|---|---|
| 計測 | 流入、DL、MQL、SQL、商談を追えているか | 不足しているイベントやCRM項目を追加する |
| 受け渡し | 営業が受け取る条件が明確か | MQL/SAL/SQLの定義を文書化する |
| 接点 | 段階ごとのコンテンツが足りているか | 比較表、事例、チェックリストを補う |
| 改善 | 月次で条件を見直しているか | 商談化・失注理由から条件を更新する |
判断軸の比較表
| ステージ | 意味 | 主な判定者 | 確認項目 |
|---|---|---|---|
| MQL | 営業へ渡す候補 | マーケティング | 属性、行動、関心テーマ |
| SAL | 営業が受け入れた状態 | IS/営業 | 対象可否、情報不足、追客方針 |
| SQL | 商談化条件を満たした状態 | 営業 | 課題、時期、予算、決裁関与 |
BtoB現場での具体例
例えば、検索記事から初回訪問した担当者が、数日後に比較記事を読み、さらにチェックリストをダウンロードした場合、この行動は単なるページビューではなく、検討段階が進んだサインとして扱えます。ここで営業へ即時に渡すのではなく、会社属性、過去接点、閲覧テーマを確認し、MQL候補として整理します。
その後、同じ会社の別担当者が料金、導入事例、要件整理の記事を閲覧した場合は、個人単位ではなく会社単位で検討が進んでいる可能性があります。BtoBでは、このような複数人の行動を一つのアカウントとして見られるかどうかが重要です。
営業へ渡すときは、「資料をダウンロードしました」だけでは情報が不足します。どの記事を読み、どのテーマに関心があり、どの資料を取得し、どの会社属性に該当するのかをまとめることで、営業は初回連絡で確認作業ではなく課題整理から入れます。
AIを使う場合は、この一連の接点を要約し、営業メモや次アクション案に変換できます。例えば「MA導入を検討しており、HubSpotとCRM連携に関心が高い。比較表とMQL定義の記事を閲覧しているため、営業連携の設計相談が有効」といった形にすると、ファネル改善が実務に接続します。
この具体例で大切なのは、流入、記事、資料、CRM、営業活動を別々に見ないことです。各接点が次の状態へ進めているかを確認し、進んでいない場合は、コンテンツ、CTA、営業受け渡し、メールシナリオのどこを直すべきかを切り分けます。
また、改善施策は一度に増やしすぎないことが重要です。まず一つの段階で仮説を立て、記事、CTA、フォーム、営業通知のどれを直したのかを記録します。変更点と結果を対応させて残すことで、次の改稿やMAシナリオ改善の判断がしやすくなります。
ファネル設計は、マーケティング部門だけの資料ではありません。営業、インサイドセールス、カスタマーサクセスが同じ定義を見て動けるように、段階名、条件、担当、次アクションを共通言語として整える必要があります。
よくある質問
SALは必ず必要ですか？
必須ではありません。営業受け渡しのずれが大きい組織や、インサイドセールスが一次確認する組織では有効です。
MQLの点数は何点からにすべきですか？
固定点から始めるより、過去にSQL化した行動と属性を見て決めるべきです。点数だけでなく理由も残してください。
営業がMQLを追わない場合はどうしますか？
受け入れ条件と戻し条件を明確にし、SALの状態を置くと改善しやすくなります。営業が追わない理由をCRMに残すことも必要です。
AIでMQL判定はできますか？
補助はできます。問い合わせ内容、閲覧行動、会社属性を要約し優先順位付けできますが、営業フィードバックで継続的に調整する必要があります。
関連ページと関連記事
- リードスコアリング
- TOFU/MOFU/BOFU
- BtoBファネル
- BtoBマーケティング支援
MQL・SQL定義を相談する
MQL、SAL、SQLの定義が曖昧なままだと、MAやCRMを入れても営業連携は改善しません。受け渡し基準、戻し条件、CRM項目をまとめて整理したい場合は、ファネル設計から相談できます。
