KIZUNA KIZUNA SalesFlow
インサイドセールス

MQLとSQLの違い｜マーケと営業の引き継ぎ設計

「マーケから渡されたリード、ぜんぜん受注にならないんだけど」「いや、営業が放置してるから商談化しないんでしょ」——この応酬、どこの会社でも一度は聞いたことがあるはずだ。資料ダウンロードやウェビナー参加で集めたリードが、マーケと営業のどちらの責任とも言えないグレーゾーンに落ちて、気づけば数百件が放置されている。

その根っこにあるのが、MQLとSQLの定義が曖昧なまま運用が走り出している状態だ。どこまでがマーケの仕事で、どこからが営業の仕事なのか。その線引きが言葉だけで共有されていないと、リードは必ず宙に浮く。今回は、MQLとSQLの違いをきちんと整理したうえで、現場で実際に機能する引き継ぎルールの組み立て方を見ていこう。

MQLとSQLの違いをまず言葉で固める

MQL（Marketing Qualified Lead）は、マーケティング活動を通じて「自社に興味を持っていそうだ」と判断されたリードのこと。資料請求、ウェビナー申込、メルマガ内のリンク複数クリックなど、行動の蓄積で「そろそろ営業が接触してもいい温度」に達した状態を指す。

一方のSQL（Sales Qualified Lead）は、営業（またはインサイドセールス）が実際にコンタクトを取り、「これは商談に進められる」と判断したリードだ。予算・決裁権・ニーズ・導入時期、いわゆるBANTのような条件をある程度満たしていることが前提になる。

ざっくり言えば、MQLは「マーケが見込みありと判定した段階」、SQLは「営業がイケると確認した段階」。この2つを混同したまま「ホットリード」とひとくくりにすると、温度感の認識が部署ごとにズレて、引き継ぎが必ず破綻する。

MQLとSQLの間にもう一段あると考える

実務では、この2つの間に「MQLは渡したけど、まだ営業が会話できていない」段階が必ず生まれる。ここをSAL（Sales Accepted Lead）と呼ぶ会社もある。要するに「営業がそのリードを受け取って、対応する責任を負った」状態だ。

なぜこの中間を意識するかというと、責任の所在を明確にするためだ。MQLを渡しただけでは、営業が見ているか放置しているか分からない。「受け取りました」というSALのステップを挟むと、「マーケは渡した」「営業は受けた」という事実が記録に残る。ここが抜けると、冒頭の責任なすりつけ合戦が始まる。

自社のMQL/SQL定義は数字とセットで決める

定義の話で一番やりがちな失敗は、「興味が高そうなリード」みたいな曖昧な言葉で止めてしまうことだ。これだとマーケと営業で解釈が割れる。定義は必ず「誰が見ても同じ判定になる」レベルまで数字に落とす。

たとえばMQLの基準をこう決める。

  • 資料ダウンロードを1回以上、かつ従業員50名以上の企業
  • ウェビナー参加後、3日以内に料金ページを閲覧
  • スコアリングの合計が30点以上（行動・属性の加点ルールはあらかじめ定義）

スコアリングの設計そのものについてはリードスコアリングの始め方で詳しく扱っているが、ポイントは「行動」と「属性」の両面で点をつけることだ。役職や企業規模といった属性だけだと温度を見誤るし、行動だけだと冷やかしを拾ってしまう。

SQLの基準も同じく数字とセットにする。

  • インサイドセールスが電話で接続し、導入検討時期が「3ヶ月以内」
  • 決裁に関わる人物と会話ができている
  • 現状の課題が具体的にヒアリングできている

この3つのうち2つ以上を満たしたらSQL、といった形で「いくつ満たせばOKか」まで決めておくと、判定のブレが一気に減る。

リード受け渡しルール（SLA）を両部署で握る

定義が固まったら、次は受け渡しのルールだ。ここで効いてくるのがSLA（Service Level Agreement）という考え方。部署間で「お互いに何をいつまでにやるか」を約束として明文化する。

営業とマーケの間でよく握るSLAは、こんな感じだ。

  • マーケはMQLを月◯件、営業に供給する（量のコミット）
  • 営業はMQLを受け取ってから24時間以内に初回アプローチする（速度のコミット）
  • 5回コンタクトして接続できなければ、ナーチャリングへ差し戻す（戻しのルール）

特に「24時間以内」のスピードは軽視されがちだが、リードは時間が経つほど冷める。問い合わせから対応までの時間が延びるほど商談化率が落ちるのは、現場感覚としても納得できるはずだ。資料を落とした直後の「今まさに調べている」タイミングを逃すと、競合に先を越される。

差し戻しのルートを必ず作る

引き継ぎ設計で抜けがちなのが、「営業がアプローチしたけど、まだ早かった」リードの行き先だ。これを営業のCRM上で放置すると、リードは死蔵される。

そうではなく、「今は商談に至らないが見込みはある」リードはマーケのナーチャリングに戻す。メール配信やコンテンツ提供で温め直し、再び温度が上がったらまたMQLとして戻ってくる。この循環を作っておくことが大事だ。具体的な温め方はリードナーチャリングの設計を参照してほしい。一度冷めたリードを捨てずに回し続ける仕組みがあるかどうかで、リード全体の歩留まりは大きく変わる。

引き継ぎがうまくいかない3つの落とし穴

ルールを作っても運用が回らないケースには、だいたい共通したパターンがある。

ひとつ目は、定義をシステムに落とし込んでいないこと。MQLの判定を毎回人間が手作業でやっていると、運用が属人化して破綻する。スコアが基準を超えたら自動でステータスが変わる、くらいの仕組みは欲しい。

ふたつ目は、フィードバックの欠如だ。営業が「このMQL、全然ダメだった」という感触をマーケに返さないと、MQLの質はいつまでも上がらない。受注に至ったSQLがどんなMQLだったかを逆算して、定義をチューニングし続ける。この往復がないと、定義は一度決めたきりで陳腐化する。

3つ目は、ツールが分断されていること。マーケのツールと営業のツールが別々で、リードの状態がリアルタイムで見えないと、誰がどこまで対応したか分からなくなる。MQLからSQL、そして商談・受注まで、同じ画面で状態を追えることが理想だ。テレアポやインサイドセールスの現場では、架電履歴と温度管理が一元化されているだけで引き継ぎの精度はかなり上がる。インサイドセールスとテレアポの役割の違いについてはインサイドセールスとテレアポの違いも合わせて読むと整理しやすい。

まとめ

MQLとSQLの引き継ぎ設計は、難しい理論ではなく「定義」と「ルール」の地味な合意の積み重ねだ。要点を振り返っておく。

  • MQLは「マーケが見込みありと判定」、SQLは「営業がイケると確認」。間にSAL（受領）を挟むと責任が明確になる
  • 定義は曖昧な言葉で止めず、スコアや件数といった数字とセットで決める
  • SLAで「量・速度・差し戻し」を両部署が握る。特に初回アプローチのスピードは商談化率に直結する
  • 商談に至らないリードはナーチャリングへ戻し、循環させる
  • 定義はマーケと営業のフィードバックで継続的にチューニングする

リードが宙に浮くのは、現場の怠慢ではなく設計の不在が原因であることが多い。線引きと約束を言語化するだけで、放置されていたリードが動き出す。

あわせて読みたい

テレアポの管理をもっとシンプルに。 KIZUNA SalesFlowは、テレアポ／インサイドセールスチームのためのシンプルなSFAツールです。 詳しくはこちら →

KIZUNA SalesFlow

読んで終わり、にしない。
架電を成果に変えるSFA。

ブラウザのソフトフォンでワンクリック発信・自動録音。初期費用0円・契約期間の縛りなし、月額¥1,480〜（税抜）。営業リストは上位プラン（プロ・MAX）でご利用いただけます。

無料で資料請求 料金を見る 機能を見る

Related

関連記事

SFA

インサイドセールスとテレアポの違い【比較表付き】

インサイドセールスとテレアポの違いを目的・KPI・ツール・スキルの4軸で比較表に整理。SDR・BDR・ISRの役割の違い、メール返信率より電話接続率が高いというデータから見る「テレアポは古い」論への答え、テレアポ経験を武器にするステップを解説します。