お問い合わせ
MQLやSQLについて調べていると、SAL、MAL、PQL、TQLなど、次々と別の用語が出てきます。しかし、すべての用語を覚え、自社の管理プロセスに取り入れる必要はありません。大切なのは、自社のマーケティング・営業プロセスに必要な分類だけを選び、それぞれの判定基準を部門間でそろえることです。
特にBtoB企業では、マーケティング部門が「有望」と考えるリードと、営業部門が「今アプローチすべき」と考えるリードが一致しないことがあります。この認識のズレを残したままMQLやSQLの基準を設けても、営業に渡したリードが放置されたり、商談につながらなかったりする可能性があります。
本記事では、MQLとSQLの定義や違いを整理したうえで、MQLからSQLへの移行方法、自社に合った判定基準と受け渡しルールの作り方まで解説します。
この記事の重要ポイント
・MQLとSQLは、マーケティングと営業で見込み顧客を評価・引き継ぐための基準
・MQL・SQLに正解の基準はなく、自社の営業プロセスに合わせて設計することが重要
・判定基準は、過去データをもとに作成し、マーケティングと営業で継続的に見直す
・MQLの成果を高めるには、受け渡しルールやSLAを整備し、部門間で改善サイクルを回す
シャコウではBtoBマーケティングに関する情報をYouTubeで発信しています。初心者の方でも網羅的に理解できる内容になっていますので、ぜひ参考にご視聴ください。
MQLとSQLとは？定義と全体像
MQLとSQLは、見込み顧客が購買プロセスのどこにいるかを表す分類です。一般的には、マーケティング部門が育成・評価したリードをMQL、その後に営業部門がアプローチ対象として評価したリードをSQLと呼びます。
| 分類 | 正式名称 | 主な状態 | 主な担当部門 |
|---|---|---|---|
| MQL | Marketing Qualified Lead | 自社への関心や一定の適合性が確認され、継続的に育成・評価すべき状態 | マーケティング部門 |
| SQL | Sales Qualified Lead | ニーズや導入意向などが確認され、営業が商談化に向けて優先的に対応すべき状態 | インサイドセールス・営業部門 |
ただし、MQLやSQLに世界共通の判定基準があるわけではありません。「どの状態をMQLとするか」「どの時点でSQLへ移すか」は、商材の単価や検討期間、分業体制などに合わせて定義する必要があります。
MQLとは
MQL（Marketing Qualified Lead）とは、マーケティング活動で獲得したリードのうち、自社の商品・サービスへの関心やターゲットとの適合性が一定以上あると判断された見込み顧客です。
たとえば、資料をダウンロードした、セミナーに参加した、製品ページを複数回閲覧したなどの行動が見られるリードが候補になります。ただし、資料を1回ダウンロードしただけでMQLとするか、企業規模や役職などの属性も満たす必要があるかは、企業によって異なります。
SQLとは
SQL（Sales Qualified Lead）とは、営業が接触・確認した結果、商談化に向けて優先的にアプローチすべきと判断された見込み顧客です。
一般的には、MQLのうち、解決したい課題や導入時期、予算、意思決定プロセスなどが確認できたリードがSQLになります。問い合わせやデモ依頼のように検討意向が明確なリードや、営業が独自に開拓したリードが直接SQLとなる場合もあります。
MQLとSQLの違い
MQLとSQLの違いは、判定する部門・判断材料・判定後のアクションにあります。
| 比較項目 | MQL | SQL |
|---|---|---|
| 判定の主体 | 主にマーケティング部門 | 主にインサイドセールス・営業部門 |
| 主な判断材料 | 企業・担当者の属性、Web行動、コンテンツへの反応 | 課題、ニーズ、予算、決裁への関与、導入時期、商談意思 |
| 確認方法 | データやスコアによる評価が中心 | 電話、オンライン面談、商談前ヒアリングなどが中心 |
| 主な目的 | 育成対象や営業連携候補を絞る | 営業が優先的に対応する対象を決める |
| 次のアクション | ナーチャリング、インサイドセールスへの連携 | 商談化に向けた提案・ヒアリング |
MQLは主に属性や行動データをもとに判定しますが、SQLでは顧客との対話から課題や導入意向などを確認します。なお、具体的な判定項目や基準の作り方は、以降の章で詳しく解説します。
MQL・SQLの周辺用語とその関係
リード分類には、MQLとSQL以外にもさまざまな用語があります。ただし、すべてが同じ軸の用語ではありません。
MALやSALはリード管理プロセスの段階を表しますが、PQLは製品利用、SGLは営業活動というリードの発生・評価方法を表します。まずはそれぞれの位置づけを整理し、自社で区別する必要があるかを判断しましょう。
MQL・SQLの周辺用語を役割別に整理
| 分類 | 用語 | 一般的な意味 | MQL・SQLとの関係 |
|---|---|---|---|
| プロセスの段階 | MAL | Marketing Accepted Lead。獲得したリードのうち、マーケティング部門が育成対象として受け入れたリード | MQLの前段階に置かれることがある |
| プロセスの段階 | SAL | Sales Accepted Lead。マーケティングから渡されたリードのうち、営業が対応対象として受け入れたリード | MQLとSQLの間に置かれることが多い |
| プロセスの段階 | TQL | Teleprospecting Qualified Leadなど。インサイドセールスや電話での確認を経て、有望と判断されたリード | MQLとSAL・SQLの間に置かれることがある |
| 製品利用による評価 | PQL | Product Qualified Lead。無料トライアルなどの製品利用状況から、有望と判断されたリード | SaaSやPLG型ビジネスで使われることが多い |
| 営業起点のリード | SGL | Sales Generated Lead。新規開拓、紹介、既存人脈など、営業活動から創出されたリード | MQLを経ず、営業側からSQL候補になることがある |
| 独自の評価区分 | HQL | Highly Qualified Lead。属性や意向など、通常のMQLより厳しい条件を満たすリード | 標準的な区分ではなく、企業独自の定義として使われることが多い |
代表的なプロセスは、MAL→MQL→SAL→SQLです。ただし、すべての企業がこの4段階を設ける必要はありません。
また、PQLやSGLはプロセス上の段階ではなく、リードがどのように生まれ、評価されたかを示す分類です。MALからSQLまでの流れと同じ一本の順序に並べるものではありません。
なお、BANTはリードの種類ではなく、SQLを判定する際の確認項目です。そのため、後述する「自社独自のMQL・SQL判定基準をどう設計するか」で解説します。
自社のリード管理は何段階に分けるべきか
用語を増やすほど、リード管理が精緻になるとは限りません。担当者や判定、施策が変わらない段階に別の名称を付けても、入力・集計作業が増えるだけです。
次の3つの観点から、自社に必要な段階を絞りましょう。
-
担当部門が切り替わるか
マーケティングからインサイドセールス、インサイドセールスから営業など、リードを担当する部門が変わる地点を確認します。
-
新たな判定が発生するか
「営業が対応対象として受け入れる」「商談化に向けて対応する」といった判定がある場合は、段階を分ける意味があります。
-
異なるKPIを追う必要があるか
段階ごとに受け入れ率やSQL化率などを確認したい場合は、別のステータスを設けます。担当者・施策・KPIが変わらない場合は、無理に分ける必要はありません。
マーケティングから営業へ直接引き渡す体制なら、MQLとSQLの2段階でも運用できます。
一方、営業がリードを受け入れた後、接触やヒアリングによってSQLかどうかを判断する場合は、MQLとSQLの間にSALを設けると、営業の受け入れ率と、受け入れ後のSQL化率を分けて確認できます。
MQLからSQLへの移行を進める具体的な方法
MQLからSQLへの移行は、単にスコアが閾値を超えたリードを営業へ送る作業ではありません。接点をつくり、検討に必要な情報を届け、営業が対応すべき状態かを確認する一連のプロセスとして設計します。
リードナーチャリングの3ステップ
STEP1：見込み顧客との接点をつくる
広告、検索流入、展示会、セミナー、資料ダウンロードなどを通じてリードを獲得します。この段階では連絡先の数だけでなく、どの課題やコンテンツに反応したかも記録しておきます。
STEP2：継続的な情報提供で検討を支援する
見込み顧客の課題や検討段階に応じて、メール、ホワイトペーパー、ウェビナー、導入事例などを提供します。同じ資料を一斉配信するのではなく、関心テーマや過去の行動に合わせて情報を出し分けることが重要です。
STEP3：営業対応の必要性を確認する
属性と行動をもとにMQL候補を抽出し、必要に応じてインサイドセールスが課題や検討状況を確認します。スコアだけでSQLとみなさず、営業が商談を進められる条件を満たしているかを確認して引き渡します。
各ステップでのMA・SFA・CRM活用
MA（Marketing Automation）、SFA（Sales Force Automation）、CRM（Customer Relationship Management）は、役割を分けたうえで連携させます。
| ツール | 主な役割 | MQL・SQL運用での活用例 |
|---|---|---|
| MA | マーケティング施策と行動データの管理・自動化 | メール配信、Web行動の記録、スコアリング、MQL候補の抽出 |
| SFA | 営業活動と案件進捗の管理 | 初回対応、ヒアリング結果、SQL判定、商談進捗の記録 |
| CRM | 顧客情報・接点履歴の統合管理 | 部門横断で顧客情報を参照し、過去の接点や商談履歴を共有 |
連携時に重要なのは、リードの氏名や会社名だけでなく、「なぜMQLになったのか」が営業に伝わる状態を作ることです。閲覧ページ、ダウンロード資料、参加イベント、スコアの内訳、過去の接触結果などを引き渡せるようにします。
ツールを導入しても、判定基準や担当者、差し戻し先が曖昧なままでは運用は改善しません。先にプロセスを決め、そのプロセスを再現・記録する手段としてツールを使うことが基本です。
BtoBコンサルタント
柴犬先輩
MQLからSQLへの移行は、点数だけでなく「営業が動ける状態か」を見極めることが大切！
MQL→SQL転換率とは？計算方法と確認すべきKPI
MQL→SQL転換率とは、MQLと判定されたリードのうち、SQLへ移行した割合です。MQLの質や営業への受け渡し状況を確認するための指標として用いられます。
MQL→SQL転換率の計算方法
MQL→SQL転換率は、次の式で計算します。
MQL→SQL転換率（％）＝SQL化したMQL数÷MQL総数×100
たとえば、1カ月に創出した100件のMQLのうち、20件がSQLへ移行した場合、MQL→SQL転換率は20％です。
ただし、同じ月のMQL数とSQL数を単純に割ると、前月以前に創出されたMQLが混ざる可能性があります。正確に把握するには、MQLと判定されたリードごとに、その後SQLへ移行したかを追跡する必要があります。
また、MQLやSQLの定義、SQLへの移行を確認する期間も統一しましょう。集計条件が異なると、月ごとの数値を正しく比較できません。
MQL→SQL転換率とあわせて確認したいKPI
| 確認する観点 | KPI例 | わかること |
|---|---|---|
| リードの量 | MQL数、SQL数 | 各段階に十分なリードがあるか |
| 受け渡し | 営業が対応対象とした割合、差し戻し件数 | MQLの基準が営業の認識と合っているか |
| 対応速度 | 初回対応までの時間、SQL化までの期間 | 引き渡し後にリードが滞留していないか |
| 商談への接続 | SQLから商談への転換率 | SQLの判定基準が適切か |
| 最終成果 | 商談から受注への転換率 | SQLが売上につながっているか |
| 改善材料 | 差し戻し理由、失注理由 | どの基準や施策を見直すべきか |
MQL→SQL転換率に一律の正解はありません。商材単価や検討期間、MQL・SQLの定義によって数値が変わるため、業界平均よりも、自社の過去推移や流入経路別の違いを確認することが重要です。
自社独自のMQL・SQL判定基準を設計する4ステップ
MQL・SQLの判定基準は、他社のスコアリング表をそのまま流用するのではなく、自社のターゲットや営業プロセスに合わせて設計する必要があります。
重要なのは、最初から理想的な基準を作ろうとしないことです。まずは過去のリードデータからマーケティングと営業の判断差を把握し、暫定的な基準を運用しながら改善します。
STEP1．過去のリードから認識ギャップを把握する
最初に、直近数カ月にマーケティングから営業へ引き渡したリードを確認します。マーケティングが有望と判断した理由と、営業が実際に対応したか、その後どの段階まで進んだかを突き合わせましょう。
主に確認したいのは、次の項目です。
- マーケティングがMQLと判定した理由
- 営業が対応した、または見送った理由
- 引き渡しから初回接触までにかかった時間
- SQL・商談・受注へ進んだリードの属性と行動
- 営業から差し戻された理由
- 差し戻し後に実施したナーチャリング
たとえば、マーケティングは資料の閲覧回数を重視している一方、営業は企業規模や導入時期を重視しているかもしれません。
このような判断の違いを明らかにすることで、どの情報をMQL・SQLの基準に反映すべきかを具体化できます。
STEP2．属性と行動からMQLの判定基準を作る
MQLの判定基準は、主に属性情報と行動情報の2軸で設計します。
- 属性情報：業種、企業規模、地域、部署、役職など、自社のICP（Ideal Customer Profile／理想顧客像）との適合度
- 行動情報：資料ダウンロード、メールクリック、セミナー参加、製品・料金ページの閲覧など、関心や検討の強さ
属性情報だけでは、ターゲット企業ではあるものの、現時点では関心のないリードまでMQLに含まれる可能性があります。一方、行動情報だけでは、対象外の個人や競合企業が、閲覧回数によってMQLになるかもしれません。
そのため、どちらか一方ではなく、両方を組み合わせて判定します。
以下は、MQL判定に使用するスコアリング表の一例です。点数はあくまで仮の値であり、自社の過去データをもとに調整する必要があります。
| 評価軸 | 条件例 | 仮の点数 |
|---|---|---|
| 属性 | 対象業種に該当 | ＋10 |
| 属性 | 想定する企業規模に該当 | ＋10 |
| 属性 | 意思決定に関与する部署・役職 | ＋10 |
| 行動 | 課題解決資料をダウンロード | ＋5 |
| 行動 | セミナーに参加 | ＋10 |
| 行動 | 導入事例・料金ページを閲覧 | ＋10 |
| 行動 | 問い合わせ・デモを依頼 | ＋20または営業へ即時連携 |
| 除外・減点 | 競合企業、個人アドレス、長期間反応なし | 除外または減点 |
実際の運用では、「合計30点以上」のような点数だけでなく、必須条件も設定します。
たとえば、「対象業種・企業規模を満たし、行動スコアが10点以上」と定めれば、ターゲット外のリードが行動回数だけでMQLになるのを防げます。
STEP3．営業が確認するSQLの判定基準を決める
MQLのスコアが高いだけで、自動的にSQLになるわけではありません。SQLは、インサイドセールスや営業が顧客と接触し、商談化に向けて対応できる状態かを確認して判定します。
主な確認項目は次のとおりです。
| 確認項目 | 確認する内容 |
|---|---|
| 課題・ニーズ | 自社の商品・サービスで解決できる課題があるか |
| 導入意向 | 情報収集だけでなく、具体的な検討意思があるか |
| 導入時期 | 導入希望時期や検討スケジュールが見えているか |
| 予算 | 予算があるか、今後予算化する可能性があるか |
| 意思決定プロセス | 決裁者や関係部署、承認の流れがわかっているか |
| 次のアクション | 次回のヒアリングや提案に進む合意があるか |
すべての条件を満たすことをSQLの必須条件にする必要はありません。検討初期には、予算や導入時期が決まっていないこともあります。
まずは「課題が確認できている」「自社の提供価値と合っている」「次のアクションに進める」など、自社が商談を進めるために最低限必要な条件を決めましょう。
STEP4．暫定基準を運用し、結果をもとに見直す
最初に設定する点数や閾値は、完成版ではなく仮説です。一定期間運用したら、次の指標を確認します。
- MQL→SQL転換率
- SQLから商談への転換率
- 商談から受注への転換率
- 営業がMQLを差し戻した件数と理由
- MQLの引き渡しから初回対応までの時間
MQL数が多いのにSQLへ進まない場合は、MQLの閾値が低すぎる可能性があります。反対に、MQL数が極端に少ない場合は、条件が厳しすぎるかもしれません。
また、SQLから商談へ進まない場合は、SQLの判定条件やヒアリング内容を見直す必要があります。マーケティングと営業で定期的に結果を確認し、点数・必須条件・除外条件を調整しましょう。
どの項目を重視すべきかは、商材の検討期間や営業プロセスによって異なります。シャコウの「BtoBマーケ定石診断・戦略策定支援」では、自社の現状と課題を可視化し、最短1カ月で戦略方針を策定します。自社に合ったMQL・SQL基準がわからない場合は、現状診断から整理できます。
MQLの受け渡しでマーケティングと営業の連携を改善する方法
MQL・SQLの定義をそろえるだけでは、部門間連携は改善しません。
マーケティングから営業へどのようなリードを渡し、営業がいつまでに対応し、SQLに至らなかった場合はどうするのかまで決める必要があります。
受け渡し前後の行動を明文化し、営業からマーケティングへ結果を返す仕組みを整えましょう。
なぜマーケティングと営業でリードの評価がズレるのか
マーケティングと営業でリードの評価が分かれるのは、それぞれが見ている情報や時間軸、追っているKPIが異なるためです。
| ズレが生まれる要因 | マーケティング部門 | 営業部門 |
|---|---|---|
| 判断材料 | Web上の行動、コンテンツへの反応、属性情報 | 顧客との会話で確認した課題や導入意向 |
| 重視する時間軸 | 将来の商談候補も含めて中長期で育成する | 現時点で商談を進められるかを判断する |
| 主なKPI | MQL数、MQL→SQL転換率など | 商談数、受注率、売上など |
| リードへの期待 | 関心が高まっているため、営業に対応してほしい | 課題や導入意向が確認できるリードを優先したい |
マーケティングは「関心が高まっている」と判断しても、営業から見ると「まだ具体的な検討段階ではない」ということがあります。
これは、どちらかの判断が間違っているのではありません。両部門が異なる情報と時間軸でリードを見ていることが原因です。
そのため、単に「有望なリードを渡す」と決めるのではなく、どの状態なら営業へ引き渡すのか、引き渡した後に何を確認するのかを具体的に定める必要があります。
SLAでMQLの受け渡しルールを明文化する
SLA（Service Level Agreement）とは、部門間で合意する運用ルールです。
MQLの受け渡しでは、判定基準だけでなく、引き渡し先、対応期限、共有する情報、SQLに至らなかった場合の扱いまで決めます。
| タイミング | 決めること | 具体例 |
|---|---|---|
| 引き渡し前 | MQLの判定基準 | 必須属性、行動条件、スコアの閾値、除外条件 |
| 引き渡し時 | 引き渡し先 | インサイドセールス、営業担当、担当不在時の振り分け |
| 引き渡し時 | 共有する情報 | 企業・担当者属性、行動履歴、関心テーマ、MQLと判定した理由 |
| 引き渡し後 | 初回対応の期限 | 引き渡しから何時間・何営業日以内に対応するか |
| 引き渡し後 | 対応方法 | 電話やメールを、どの頻度で何回実施するか |
| 営業による確認後 | SQLの判定条件 | 課題、導入意向、導入時期、意思決定への関与など |
| SQLに至らなかった場合 | 差し戻しルール | 差し戻し理由、戻し先、再育成の方法 |
| 運用後 | フィードバック方法 | SFA・CRMへの入力項目、レビュー頻度、参加者 |
SLAがないと、次のような問題が起こりやすくなります。
- 資料ダウンロードだけで一律にMQLと判定される
- 引き渡したMQLが営業に放置される
- 営業が対応しなかった理由が記録されない
- SQLにならなかったリードの戻し先がない
- MQL・SQLの基準が実態と合わなくなっても見直されない
最初から細かいルールを作りすぎる必要はありません。まずは、「判定条件」「対応期限」「結果の記録」「差し戻し」の4項目から決めるとよいでしょう。
差し戻しと定例レビューまで仕組み化する
MQLの受け渡しは、営業へ渡して終わりではありません。SQLに至らなかったリードをマーケティングへ戻し、再育成につなげる流れまで設計します。
具体的には、次のサイクルを作ります。
- 営業がMQLへの対応結果をSFA・CRMへ記録する
- SQLに至らなかった場合は、理由を選択・入力する
- 再検討の可能性があるリードをマーケティングへ戻す
- 関心テーマや見送り理由に応じてナーチャリングを行う
- 定例会で転換率や差し戻し理由を確認する
- 結果をもとにMQL・SQLの基準とSLAを更新する
たとえば、「導入時期が未定」という差し戻しが多い場合、リードの質が低いとは限りません。すぐに営業が追う対象からは外し、導入事例や比較資料を届けながら、検討時期が具体化するまで育成する方法があります。
一方、「対象企業ではない」という差し戻しが多い場合は、MQLの属性条件や除外条件を見直す必要があります。
このように、差し戻し理由をマーケティング施策と判定基準の改善に活かすことで、MQLの受け渡しが一方向の作業ではなく、部門間の改善サイクルとして機能します。
MQL・SQLの基準設計は内製できる？外部支援との判断基準
MQL・SQLの基準設計は、内製でも進められます。ただし、過去のリードデータを確認できること、マーケティングと営業の担当者が話し合えること、基準を継続的に見直す責任者がいることが前提です。
これらの条件がそろっていない場合、基準を作っても部門間で合意できなかったり、運用が定着しなかったりする可能性があります。内製か外部支援かは、設計作業ができるかだけでなく、客観的な現状分析と部門間の合意形成まで進められるかで判断しましょう。
内製と外部支援を判断する4つのポイント
内製と外部支援のどちらが適しているかは、次の4つの観点から判断します。
| 判断する観点 | 内製が向いている状態 | 外部支援が有効な状態 |
|---|---|---|
| 推進体制 | マーケティング・営業の責任者と、基準設計を進める担当者が決まっている | 責任者が不明確で、設計や意思決定が進まない |
| データ環境 | リード獲得から受注までのデータを追跡できる | MA・SFA・CRMにデータが分散し、全体像を把握できない |
| 部門間の合意 | マーケティングと営業が共通の目的で話し合える | 部門間でリードの評価が対立し、合意形成が進まない |
| 運用・改善 | 定期的に結果を確認し、基準を見直す時間を確保できる | 日常業務が優先され、設計や見直しが止まっている |
内製に向いているのは、過去データをもとに仮説を立て、マーケティングと営業が協力して基準を改善できる企業です。専任チームを置けない場合でも、推進責任者を決め、定例で結果を確認できれば進められます。
一方、部門間の対立やデータの分断がある場合は、社内の話し合いだけで結論を出しにくくなります。特定部門の意見に偏らないよう、第三者が現状を整理し、共通の判断材料を示すことが有効です。
外部支援はどこまで活用すべきか
外部支援を利用する場合も、MQL・SQLの運用をすべて任せる必要はありません。
たとえば、立ち上げ時の現状診断や基準設計のみ外部の知見を取り入れ、その後の運用と改善を社内で担う方法があります。
外部支援を活用できる主な範囲は、次のとおりです。
- マーケティングと営業の認識ギャップの整理
- リードから受注までのデータ分析
- MQL・SQLの判定基準の設計
- 部門間の受け渡しルールやSLAの策定
- KPIと定例レビュー方法の設計
- MA・SFA・CRMの運用整理
初期設計のみ外部の視点を取り入れれば、部門間の合意形成を進めながら、その後のノウハウを社内に蓄積できます。
反対に、社内に運用担当者がいない場合は、基準設計だけでなく、ナーチャリングやインサイドセールスなどの実行支援まで依頼する方法もあります。
重要なのは、内製か外注かを二者択一で考えるのではなく、自社で担える範囲と、外部の知見が必要な範囲を分けることです。
シャコウは、BtoBマーケティングの上流課題を診断し、経営と現場をつなぐ戦略方針の策定から、マーケティング・セールス施策の実行まで一貫して支援しています。「どこまで内製できるかわからない」という段階でも、「BtoBマーケ定石診断・戦略策定支援」を通じて、現状の可視化と取り組む範囲の整理から始められます。
MQL・SQLに関するよくある質問
Q1：MQLとSQLの違いは何ですか？
MQLはマーケティング部門が属性や行動から有望と判断したリード、SQLは営業部門が接触・確認した結果、商談化に向けて優先的に対応すべきと判断したリードです。主な違いは、判定する部門、判断材料、次に行うアクションにあります。
Q2：SALとMQLの違いは何ですか？
MQLはマーケティング部門が有望と判定したリード、SALはそのうち営業部門が対応対象として受け入れたリードです。MQL→SAL→SQLと分けると、営業の受け入れ率と、受け入れ後のSQL化率を別々に確認できます。
Q3：MQL→SQL転換率とは何ですか？どう計算しますか？
一定期間に創出したMQLのうち、SQLへ移行した割合です。「SQL化したMQL数÷MQL総数×100」で計算します。MQLの定義によって数値が変わるため、自社内で条件と集計期間をそろえて推移を確認することが重要です。
Q4：MQLとはどういう意味ですか？
MQLはMarketing Qualified Leadの略で、マーケティング活動で獲得したリードのうち、自社への関心やターゲットとの適合性が一定以上あると判定された見込み顧客を指します。
Q5：日本と海外でMQL・SQLの用語運用に違いはありますか？
基本的な考え方は共通していますが、判定基準や担当部門、SALなどの中間段階を設けるかは企業ごとに異なります。国による違いを前提にするよりも、自社内で定義を明文化し、関係者が同じ意味で使える状態を作ることが重要です。
Q6：MAツールによってMQL・SQLの基準設定に違いはありますか？
スコアリングやステータス管理の機能、SFA・CRMとの連携方法には違いがありますが、MQL・SQLの基準そのものは自社の顧客像と営業プロセスに合わせて決めます。ツールの初期設定をそのまま基準にせず、自社の判定ルールを先に整理しましょう。
まとめ｜MQL・SQLの基準づくりを次の一歩につなげるために
MQLはマーケティング部門が有望と判断したリード、SQLは営業部門が商談化に向けて優先的に対応すべきと判断したリードです。両者を分ける目的は、用語を増やすことではなく、見込み顧客の状態に応じて、適切な部門が適切なアクションを取れるようにすることにあります。
運用を始める際は、次の順序で進めましょう。
- 過去のMQLと営業の対応結果を突き合わせ、認識のズレを把握する
- 自社に必要なリード分類だけを選ぶ
- 属性と行動を組み合わせて暫定的なMQL基準を作る
- SQLの判定条件と、受け渡し・差し戻しのSLAを決める
- 転換率や対応速度、差し戻し理由をもとに定期的に改善する
自社の基準設計やマーケティング・営業間の橋渡しに迷ったら、シャコウの「BtoBマーケ定石診断・戦略策定支援」で、現状を客観的に見える化するところから始められます。
新卒BtoBマーケター
白ポメちゃん
2つの言葉の違いはわかりました！でもMALやらTQLやら他にも似た言葉がたくさん・・・💦