マーケティング責任者や営業責任者から、こういう相談を受けます。
「MQLの定義を決めたはずなのに、営業が『これはMQLじゃない』と言って動かない」
マーケティングは、定義どおりにMQLを渡しているつもりでいる。営業は、渡されたリードの質が低いと感じて後回しにする。インサイドセールスは、その間で板挟みになる。渡したリードが放置されているのを見て、マーケティングはさらに不満を募らせる。
筆者はHubSpot JapanのCSMとして200社以上を支援してきました。この記事では、MQL・SQLの定義を誰がどう決めるか、そしてこの記事の核である受け取ったリードを放置させない仕組みと、定義の見直し方を書きます。
1. MQL・SQLとは何か
まず、言葉を揃えます。
- MQL（Marketing Qualified Lead）：マーケティング活動を通じて、一定の関心や適合度が確認できたリード。インサイドセールスが接触すべき対象
- SQL（Sales Qualified Lead）：インサイドセールスが接触し、営業が商談として追うべきと判断したリード
リードがMQLになり、SQLになり、商談になる。この段階の区切りを決めるのが、MQL・SQLの定義です。区切りが曖昧だと、どこからがどの部署の責任なのかが曖昧になります。
HubSpotでは、この段階をコンタクトのライフサイクルステージで管理します。ライフサイクルステージ、リードステータス、取引ステージの3層の考え方は、インサイドセールスと外勤の分業｜CRMで揉めない設計にまとめています。
2. 定義は3部門の責任者がすり合わせて決める
定義で揉めるのは、各部門が別々の基準を頭の中に持っているからです。
- マーケティングは、関心を示したリードをできるだけ多く渡したい
- 営業は、すぐに商談になる確度の高いリードだけを受け取りたい
- インサイドセールスは、その間で、接触すべきリードと営業に渡すべきリードを見極めたい
どの立場も間違っていません。だからこそ、マーケティング、営業、インサイドセールスの各責任者がすり合わせて決める必要があります。どれか1つの部門が決めた定義を他の部門に渡すだけでは、受け取った側は納得しません。納得していない定義は、現場で守られません。
定義は言葉ではなく、CRM上の条件で決める
すり合わせの際に大事なのは、定義をCRM上で判定できる条件として決めることです。
「関心が高いリード」という言葉だけでは、人によって解釈が変わります。「問い合わせフォームを送信した」「料金ページを閲覧し、かつ資料をダウンロードした」「リードスコアが一定以上」など、CRM上のデータで判定できる条件にしておけば、誰が見ても同じ判断になります。
スコアを条件に使う場合のスコアリングの作り方は、リードスコアリングの設計｜作り込みすぎない始め方とAI活用にまとめています。
各段階の数と転換率をオープンにする
定義を決めたら、MQL数、SQL数、商談数、そして段階ごとのコンバージョンレートを、3部門が同じ画面で見られるようにします。数字が見えていれば、「リードの質が低い」という主張は、コンバージョンレートという事実で確かめられるものに変わります。
3. 受け取ったリードを放置させない仕組み
ここが、この記事で最も伝えたいことです。
定義で揉めるのと同じくらい問題になるのが、営業やインサイドセールスが受け取ったリードを放置することです。放置は避けるべきです。関心が高まったタイミングを逃せば、そのリードは他社の商談に進むか、関心そのものを失います。
放置を防ぐ仕組みは、2つです。
仕組み1：一定期間内に必ずワンアクションを挟む
受け取ったリードには、一定期間内に必ずワンアクションを挟むことをルールにします。電話、メール、どちらでも構いません。受け取ったまま何もしない状態を作らないことが目的です。
何日以内にするかは、リードの種類で変えて構いません。問い合わせのように温度の高いリードは短く、資料ダウンロードのようなリードは少し長く。いずれにしても、期限を決めておくことが重要です。
仕組み2：アクションがなければアラートを飛ばす
ルールを決めるだけでは、守られない日が出てきます。そこで、期限内にアクションがない場合は、アラートが飛ぶ仕組みを作ります。
HubSpotであれば、ワークフローで「担当者に割り当てられてから一定期間、アクティビティが記録されていない」ことを条件に、担当者やマネージャーに通知を送る設定ができます。人の記憶に頼らず、仕組みで放置に気づける状態を作ります。
基準を満たさないリードは、ナーチャリングに戻す
アプローチしても連絡がつかないリードや、接触した結果SQLの基準を満たさないリードもあります。
こうしたリードは、担当者の手元に抱えたままにしません。休眠・ナーチャリングのステージに戻して、全体のナーチャリングに回します。 メール配信などで関係を保ち、再び関心が高まったタイミングで、もう一度MQLとして浮上させます。
担当者の手元に「動かすつもりのないリード」が溜まっていくと、本当に追うべきリードが埋もれます。戻すルールがあることで、担当者は今動かすべきリードに集中できます。休眠リードを掘り起こす順番は、失注・休眠リードを資産に変える｜掘り起こしの順番と失注理由にまとめています。
| 状態 | 扱い |
|---|---|
| 受け取った直後 | 一定期間内に必ずワンアクション |
| 期限内にアクションなし | アラートで担当者・マネージャーに通知 |
| 連絡がつかない、SQLの基準を満たさない | 休眠・ナーチャリングのステージに戻す |
4. 定義の見直し：四半期に1回
定義は、一度決めて終わりではありません。四半期に1回程度は見直すのが望ましいです。
市場の状況、商材、マーケティング施策、営業体制は変わっていきます。半年前に決めた定義が、今の実態に合っているとは限りません。四半期ごとに、MQLからSQL、SQLから商談へのコンバージョンレートを確認し、定義が機能しているかを確かめます。
- MQLからSQLへのコンバージョンレートが低い → MQLの条件が緩すぎないか
- MQLの数が極端に少ない → 条件が厳しすぎないか
- SQLから商談へのコンバージョンレートが低い → SQLの基準、または引き渡しの判断に課題がないか
見直しの場にも、3部門の責任者が揃います。決めるときと同じメンバーで、数字を見ながら調整します。
5. 実際の事例
筆者がHubSpot Japan在籍時に支援した人材派遣会社には、マーケティング担当もインサイドセールス担当もいませんでした。ここでインサイドセールス担当者を1名採用し、約2万件のハウスリストに業界別の配信を行いました。
そして、メールの開封やクリックといった反応があったリードに、インサイドセールスがすぐに電話やメールでフォローする仕組みを作っています。反応があったリードを放置せず、関心が高まっているタイミングで必ず1アクションを入れる。結果として、放置されていたハウスリストから四半期に1件ペースで契約が生まれる状態になりました。
→ Marketing Hub再活用で契約が生まれる仕組みに【人材派遣会社】
6. やりすぎると壊れるケース：定義を細かく、厳しくしすぎる
定義で揉めた経験のある会社ほど、陥りやすいのが定義を細かくしすぎる、条件を厳しくしすぎることです。
営業が「質の低いリードは要らない」と言う。それを受けて、MQLの条件を1つ、また1つと追加していく。役職、規模、閲覧ページ、閲覧回数、ダウンロード数。条件が増えるほど、MQLになるリードは減ります。
条件が厳しすぎると、リードの供給が滞り、運用が破綻します。 インサイドセールスは接触するリードがなくなり、営業は商談が足りなくなります。質を求めたはずが、商談数そのものが足りなくなるのです。
定義は、厳しくするほど良いものではありません。四半期ごとに数字を見ながら、実態に合わせて調整していくものです。
7. やるべきケース・やりすぎると壊れるケース
定義を見直すべきケース
- MQLの定義が、部門ごとに違う解釈をされている
- 受け取ったリードが、何日も放置されている
- 連絡がつかないリードが、担当者の手元に溜まっている
やりすぎると壊れるケース
- 営業の要望に合わせて、MQLの条件を追加し続けている
- MQLの数が減り、インサイドセールスの接触対象が足りない
- 定義を決めてから、一度も見直していない
よくある質問（FAQ）
Q. MQLとSQLの定義は誰が決めるべきですか？
A. マーケティング、営業、インサイドセールスの各責任者がすり合わせて決めます。どれか1つの部門が決めた定義を渡すだけでは、受け取った側は納得せず、現場で守られません。定義は言葉ではなく、CRM上で判定できる条件として決めてください。
Q. 営業がリードを放置しないようにするにはどうすればいいですか？
A. 受け取ったリードには一定期間内に必ずワンアクションを挟むことをルールにし、アクションがない場合はアラートが飛ぶ仕組みを作ります。人の記憶に頼らず、仕組みで放置に気づける状態にしてください。
Q. 連絡がつかないリードや、SQLにならないリードはどう扱えばいいですか？
A. 休眠・ナーチャリングのステージに戻して、全体のナーチャリングに回します。担当者の手元に抱えたままにすると、本当に追うべきリードが埋もれます。再び関心が高まったタイミングで、もう一度MQLとして浮上させます。
Q. MQL・SQLの定義はどれくらいの頻度で見直すべきですか？
A. 四半期に1回程度が目安です。段階ごとのコンバージョンレートを見ながら、定義が実態に合っているかを確認します。定義を細かくしすぎたり、条件を厳しくしすぎたりすると、リードの供給が滞って運用が破綻するため注意してください。
まとめ：3部門で決め、放置させず、四半期で直す
判断軸は1行です。MQL・SQLの定義は3部門の責任者でCRM上の条件として決め、受け取ったリードは期限とアラートで放置させず、四半期ごとに実態に合わせて直すこと。
定義で揉めるのは、決め方と運用の仕組みがないからです。3部門で合意し、放置を仕組みで防ぎ、合わないリードはナーチャリングに戻す。そして条件を厳しくしすぎず、数字を見ながら調整し続ける。これで、リードは部門の間で止まらずに流れます。
リード管理の設計でお困りなら
「MQL・SQLの定義を部門間で揃えたい」「リードの放置をなくしたい」——判断に迷う場合は、Harekaにご相談ください。
HubSpot JapanのCSMとして200社以上を支援した代表が、初回のご相談から定着まで一貫して担当する体制で、マーケティングから営業までリードが止まらない仕組みを一緒に作ります。
既に入っているHubSpotを活かしたい場合は、HubSpot再活用・定着支援もご覧ください。お問い合わせはこちらからお気軽にどうぞ。