MQL・SQLとは？リード定義の合意・受け渡し・SLA設計を実務解説

MQL・SQLとは（定義と判断主体の違い）

MQL（Marketing Qualified Lead）とは、マーケティング側の基準を満たし、営業に渡してよい確度に達したと判断された見込み客を指します。資料ダウンロードやウェビナー参加、特定ページの閲覧といった関心を示す行動が積み上がり、自社のターゲット像にも合致したリードが該当します。まだ購入を即決する段階ではなく、関心が高まりつつある層と捉えると実態に近くなります。

SQL（Sales Qualified Lead）とは、営業側がMQLを精査し、実際に商談を進める価値があると確認した見込み客を指します。価格の問い合わせや機能の詳細確認、デモの依頼といった購買意欲を示す動きがあり、予算や決裁権、必要性、導入時期といった条件も一定程度そろっている状態です。マーケが渡した候補を、営業が自らの基準で選別した結果がSQLになります。

両者の決定的な違いは、判断の主体です。MQLはマーケティングが「ここまで来たら営業に渡せる」と評価する段階で、SQLは営業が「これは商談として追う」と評価する段階です。同じリードでも、誰がどの基準で見るかによって評価が変わります。だからこそ、両部門が見ている基準が食い違うと、受け渡しの現場で摩擦が起きやすくなります。

MQLとSQLを分けて管理する目的は、限られた営業リソースを確度の高い相手に集中させることにあります。すべてのリードを営業が同じ工数で追うのは現実的でないため、マーケが一次選別してMQLにし、営業が二次選別してSQLに絞り込みます。この段階設計があることで、関心の薄い相手への過剰な営業や、有望なリードの放置を同時に防げます。

本記事は、スコアの組み方そのものよりも、MQLとSQLの定義を両部門でそろえ、受け渡しとSLAを設計する側面に重点を置いて解説します。スコアリングの仕組みが整っていても、定義の合意と引き渡しの設計が抜けていると成果につながらないためです。リードを部門間で滑らかに動かすための運用に焦点を当てます。

定義のずれが招く部門間のすれ違い

MQLとSQLの運用でつまずく多くの原因は、ツールの問題ではなく定義の認識ずれにあります。マーケが「資料を二回ダウンロードしたらMQL」と考えていても、営業が「価格を聞いてきて初めて追う価値がある」と考えていれば、渡されたMQLの大半は営業から見て時期尚早です。同じ言葉を使っていても、中身がそろっていないと噛み合いません。

このずれは、典型的な対立として現れます。マーケは「せっかく渡したリードを営業が動かさない」と感じ、営業は「確度の低いリードばかり渡される」と感じます。どちらも自部門の基準では正しいのですが、基準そのものが共有されていないため、互いの努力が成果に結びつかず、リードの受け渡しが形骸化していきます。

定義が曖昧なまま運用を続けると、データの解釈もばらつきます。MQL数が増えても、それが本当に営業の役に立つ増加なのか、単にカウント基準が緩いだけなのかを判断できません。指標が共通言語にならず、会議のたびに「そのMQLはどういう意味か」を問い直すことになり、改善の議論が前に進みません。

解決の出発点は、リードを表す言葉の中身を両部門で一つひとつ突き合わせることです。「リードとは何か」「どこからがMQLか」「何を満たせばSQLか」を、解釈の余地が残らない具体的な条件で書き出します。抽象的な合意ではなく、第三者が読んでも同じリードを指せる粒度まで落とすことが、すれ違いを断つ前提になります。

リード定義をマーケと営業で合意する手順

定義の合意は、共通の顧客像をそろえるところから始めます。自社が本当に取りたい顧客はどんな企業・担当者かを、業種や規模、役職、課題の観点で両部門が一緒に言語化します。ここがずれていると、その後のMQL・SQLの条件もずれるため、最上流のターゲット像を先に固めることが合意全体の土台になります。

次に、リードの段階ごとに満たすべき条件を具体的に定義します。単なる連絡先取得を「リード」、関心行動と属性適合が一定基準を超えた状態を「MQL」、予算や決裁などの商談条件を確認できた状態を「SQL」と置き、それぞれに観測可能な条件を割り当てます。「興味がありそう」ではなく「料金ページを閲覧し、対象業種に該当する」のように、判定できる形にします。

条件を決める際は、過去の受注・失注データを根拠にすると合意が早まります。実際に受注した案件がMQL・SQLのどの段階でどんな状態だったかを振り返れば、感覚論ではなく事実に基づいて基準を引けます。営業が経験的に重視している購買シグナルをヒアリングし、マーケの行動データと照らし合わせると、双方が納得しやすい定義になります。

合意した定義は必ず文書化し、両部門がいつでも参照できる場所に置きます。口頭の合意は時間とともに各自の解釈に戻っていくため、定義書として残すことが形骸化を防ぎます。担当者の異動や増員があっても同じ基準で運用できるよう、なぜその条件にしたのかという背景もあわせて記録しておくと、後の見直しが容易になります。

定義は一度で完成させようとせず、運用しながら磨く前提で合意します。最初から細かく作り込むと、どの条件が効いているか検証できなくなります。受注との相関がはっきりした少数の条件から始め、商談化率を見ながら条件を足し引きしていくほうが、現場で回る定義に育ちます。

MQLからSQLへの受け渡しフロー設計

定義が合意できたら、MQLが発生してからSQLとして商談に進むまでの動線を設計します。受け渡しは「リストを渡す」一点の作業ではなく、通知・初回接触・条件確認・昇格判定・記録という一連の流れです。この流れのどこかが詰まると、せっかくのMQLが対応されないまま温度感を失います。各工程の担当と期限を明確にしておくことが要点です。

MQLが発生したら、できるだけ早くインサイドセールスへ自動通知する仕組みを組みます。関心が高まった直後ほど反応が良いため、通知から初回接触までの速さが商談化率を大きく左右します。MAとSFA・CRMを連携させ、スコアや行動履歴を営業側でも参照できるようにすると、初回接触で相手の関心に合った話題から入れます。

初回接触では、SQLへ昇格させるための条件確認を行います。予算、決裁権、必要性、導入時期といった商談に必要な要素をヒアリングし、満たすものをSQLとして商談化します。ここで重要なのは、確認すべき項目を事前にそろえておくことです。担当者ごとにヒアリング内容がばらつくと、SQLの質が安定せず、定義の意味が薄れます。

昇格に至らなかったMQLの行き先も、フローに組み込みます。時期尚早と判断されたリードはマーケティング側に差し戻し、ナーチャリング（育成）を続けて温度感が再び上がったタイミングで渡し直します。この差し戻しと再評価の循環があることで、一度評価が低かったリードも取りこぼさず、獲得したリードを最後まで活かせます。

受け渡しの判断と理由は、CRMに記録する運用を徹底します。なぜSQLに昇格したのか、なぜ差し戻したのかを残すことで、判断基準が言語化され、属人化を防げます。蓄積された記録は、後に定義やSLAを見直す際の一次資料にもなり、感覚ではなく実績に基づく改善を支えます。

SLA（サービス品質合意）の作り方

SLA（Service Level Agreement／サービス品質合意）とは、マーケティングと営業が互いに提供する内容と水準を約束として明文化した取り決めです。一般にマーケ側のSLAは「どれだけの量・質のリードを供給するか」を、営業側のSLAは「渡されたリードをどれだけ速く、深く追うか」を定めます。双方向の約束にすることで、片務的なすれ違いを防ぎます。

マーケ側のSLAでは、供給するMQLの件数目標と質の基準を定めます。たとえば月あたりのMQL供給数や、SQLへの転換率の目安を約束として置きます。件数だけを追うと質が下がるため、量と質の両方を指標に含めることが重要です。質の基準は、前段で合意したMQLの定義そのものと整合させておきます。

営業側のSLAでは、渡されたMQLへの対応速度と対応量を定めます。代表的なのは、通知から初回接触までの時間と、追跡する回数です。関心の高いリードほど即応が効くため、「MQL発生から一定時間以内に初回接触する」といった対応期限を約束に含めます。ここを定めないと、せっかくのMQLが放置され、定義やフローの努力が無駄になります。

SLAは数値で守られているかを確認できる形にします。供給したMQL数、初回接触までの平均時間、対応率、SQL転換率、最終的な受注貢献といった指標を定点観測し、約束との差を見ます。守れていない項目があれば、それが量の問題か質の問題か対応の問題かを切り分け、定義やフローのどこを直すべきかを特定します。

SLAは一度結んで終わりではなく、定期的に見直す前提で運用します。市場や商材、組織体制は変わるため、当初の数値はやがて実態と合わなくなります。月次など決まった周期で両部門が結果を持ち寄り、指標の達成状況と現場の手応えを照らし合わせ、目標値や対応期限を更新していくことで、SLAが現実的な約束であり続けます。

受け渡し品質を測る指標と検証

定義とSLAが機能しているかは、いくつかの指標を継続的に見ることで判断します。中心になるのは、MQLからSQLへの転換率と、SQLからの商談化率・受注率です。MQLが大量に出ても転換率が低ければ、MQLの定義が緩いか質が伴っていない可能性があり、転換率は高いのに件数が少なければ、定義が厳しすぎて取りこぼしている可能性があります。

対応速度の指標も欠かせません。MQL発生から初回接触までの平均時間を測り、SLAで定めた期限を守れているかを確認します。対応が遅れたMQLと迅速に対応したMQLで商談化率を比べると、即応の効果が数値で見えます。速度が商談化に効くと示せれば、営業側の運用改善を促す根拠になります。

指標を見る際は、単月の値ではなく傾向で判断します。リードの質や量は施策やシーズンで変動するため、一時的な数値の上下に反応しすぎると、本来不要な調整を繰り返すことになります。複数月の推移や、施策ごとの内訳で見ることで、定義やSLAのどこに構造的な課題があるかを落ち着いて見極められます。

検証の場として、両部門が定期的に同じデータを見る会議を設けます。マーケはMQLの供給状況を、営業は対応状況と失注理由を持ち寄り、約束との差を一緒に確認します。「高スコアなのに商談化しないMQL」が続くなら定義の見直し、「対応が間に合っていない」なら体制やSLAの見直し、というように原因に応じて打ち手を切り分けます。

検証結果は、定義書とSLAへのフィードバックに必ずつなげます。会議で課題を共有しても、定義や約束の文書に反映しなければ運用は変わりません。商談化率や失注理由から得た学びを、MQL・SQLの条件や対応期限の更新として書き戻すことで、定義とSLAが実態に追従し続け、受け渡しの精度が回を重ねるごとに高まります。

よくある失敗と回避策

最も多い失敗は、定義の合意を省いてマーケが独自にMQLを決めてしまうケースです。営業の基準と食い違ったまま受け渡しが続き、互いの不信が積み上がります。回避策は、立ち上げ時にリード・MQL・SQLの定義を両部門で合意し、観測可能な条件まで具体化して文書化することです。合意の質が、その後の運用全体を左右します。

二つ目は、量だけを追ってMQLの質を犠牲にする失敗です。供給数の目標を達成しようとカウント基準を緩めると、転換率の低いMQLが営業に流れ、現場の信頼を失います。回避策は、SLAに量と質の両方の指標を含め、MQL供給数だけでなくSQL転換率もあわせて評価することです。質を伴わない量は成果につながりません。

三つ目は、SLAで対応速度を定めない、あるいは定めても測らない失敗です。MQLが発生しても初回接触が遅れれば、関心が高い時期を逃します。回避策は、通知から初回接触までの期限を約束として明記し、平均時間を継続的に計測することです。速度が商談化に与える影響を数値で示せば、改善の優先度が共有しやすくなります。

四つ目は、定義やSLAを作ったまま放置する失敗です。市場や商材が変われば当初の基準は実態とずれ、形だけの取り決めになります。回避策は、月次などの周期で両部門が結果を持ち寄り、商談化率や失注理由をもとに定義と約束を更新することです。受け渡しの仕組みは、協働プロセスとして継続的に手入れすることで初めて機能します。