本記事のポイント
「マーケが渡したリードを営業が追わない」「営業が『これは違う』と突き返す」。humbulls が BtoB の営業とマーケの間に入るとき、最もよく聞く対立で、原因は担当者の熱意でもリードの質でもありません。
MQL と SQL の定義を、口頭合意のまま運用していることにあります。
本記事では、営業とマーケが同じ言葉で線引きできるよう、MQL / SQL の定義と SLA を文章に落とす型を解説します。型と巻末のキットがあれば、特別なスキルなしで今日中にたたき台が作れます。
「毎月 MQL を 100 件渡しているのに、営業からは『商談になるのが 1 割もない』と言われる」。マーケ担当からよく届く相談です。
BtoB のファネルで最も売上が漏れるのは、MQL から SQL へ渡す接続点だと言われます。理由はシンプルで、多くの組織が「MQL とは何か」を文章で決めていないからです。
原因はリードの質ではなく、営業とマーケが別々の MQL 像を頭の中に持っていることにあります。
マーケは「資料をダウンロードした人」を MQL と呼び、営業は「予算と決裁権がある人」を MQL だと思っている。同じ言葉で別のものを指していれば、渡した・受け取っていないの水掛け論になるのは当然です。
よくある失敗は、この定義合意を飛ばして先にスコアリングやワークフローを組んでしまうことです。定義があいまいなまま自動化すると、間違った基準で大量のリードが流れ、対立がむしろ加速します。順番は、定義の文章化が先、自動化は後です。
→ 自社の MQL 定義のたたき台づくりは、巻末の 実行キット① (所要 30 分) でそのまま実行できます。
「行動データはたくさんあるのに、どこからを MQL と呼べばいいか決められない」。定義づくりで必ず止まるポイントです。
MQL の判断は、1 つの行動だけでは決められません。Fit (属性) と Behavior (行動) の 2 軸を掛け合わせて初めて、営業に渡す価値のあるリードになります。
2 軸はそれぞれこう分解します。
大事なのは、どちらか一方が高いだけでは MQL にしないことです。属性は合致するが無反応の人はナーチャリング対象、反応は熱いが ICP から外れる人は保留、という切り分けになります。
閾値は「Fit が中以上 かつ Behavior が特定のしきい値を超えた」の形で置きます。たとえば「従業員 50 名以上 かつ 14 日以内に料金ページと事例ページの両方を見た」のように、属性条件と行動条件を AND でつなぐと運用しやすくなります。
よくある失敗は、Behavior だけで MQL を定義してしまうことです。資料 DL 1 回で MQL にすると、学生や競合調査も混ざり、営業の信頼を一度で失います。必ず Fit 条件を AND で噛ませてください。
→ Fit × Behavior の草案づくりも、巻末の 実行キット① に含めています。
「MQL の次が SQL なのはわかる。でも何が変わったら SQL なのかが曖昧」。ステージ設計でつまずく典型です。
MQL と SQL を分ける決め手は、行動データの多さではありません。SQL は、営業がそのリードを『追う』と受け取りに合意した状態を指します。
つまり SQL への昇格条件は、マーケの自動化ではなく営業のアクションで定義します。営業がリードを確認し、商談化を目指して着手すると決めた——このアクションが起きて初めて SQL です。
ここで、間に SAL (Sales Accepted Lead) を挟む考え方もあります。渡す・受理する・有望と判断する、を 3 段に分ける発想です。
組織が小さいうちは MQL → SQL の 2 段で十分です。「受理」と「有望判断」を分けたくなったら SAL を足す、と覚えておくと拡張しやすくなります。
健全な組織なら、MQL から SQL への転換率は 20〜40% が一般的な目安です (2026-07 時点の業界水準)。これを大きく下回るなら MQL の閾値が甘く、大きく上回るなら閾値が厳しすぎて営業に渡すべきリードを止めている、という診断ができます。
よくある失敗は、SQL の昇格をマーケのスコアだけで自動化してしまうことです。営業の受け取り合意を挟まないと、SQL が「営業が同意していないリードの山」になり、ステージの意味が消えます。
「SQL にはなるが、営業が動くまで 1 週間空いて、その間にリードが冷える」。定義を決めた後に必ず出てくる次の問題です。
定義を文章にしても、運用ルールがなければ形骸化します。定義とセットで、反応時間とリジェクト理由を SLA (合意された約束) として決めておく必要があります。
SLA に最低限入れるのは次の 3 つです。
特に効くのがリジェクト理由の分類です。理由をタグで残せば、「ICP 外」が多ければ Fit 条件を厳しく、「時期尚早」が多ければナーチャリングを厚く、と定義を数字で改善できます。
よくある失敗は、リジェクトを口頭やチャットで済ませて記録しないことです。理由が残らないと、MQL 定義は永遠に勘で調整することになり、同じ対立が半年ごとに再発します。
→ SQL 昇格条件と SLA のたたき台は、巻末の 実行キット② で作れます。
「定義は決まった。これを HubSpot のどこに設定すればいいのか」。合意ができたら次に来る実装の問いです。
文章で合意した定義は、HubSpot のライフサイクルステージにそのまま対応づきます。標準ステージの Marketing Qualified Lead と Sales Qualified Lead が、本記事の MQL / SQL です。
対応づけの原則はこうです。
Fit と Behavior のスコアは HubSpot のスコアプロパティで持たせ、MQL の閾値をワークフローの条件に落とします。SQL は営業が触れる場所 (リードステータスやタスク) を起点にステージを進めるのが、定義と実装をズレさせないコツです。
具体的な設定は、次の記事が続きになります。
よくある失敗は、定義より先に HubSpot の設定画面を開くことです。ツールの設定は 30 分で終わりますが、定義の合意は数日かかります。合意なき実装は、きれいな箱に間違った基準を詰めるだけになります。
MQL / SQL の線引きで売上が漏れるのは、担当者の能力ではなく、定義を文章で合意していないからです。
型はシンプルです。
この 3 点を書き起こしてから HubSpot に実装する。順番を守るだけで、営業とマーケの「渡した・受け取ってない」は大きく減ります。まずは巻末のキット①で、自社の MQL 定義のたたき台から作ってみてください。
MQL の前段にあたるリード獲得とナーチャリングの設計は リードナーチャリング完全ガイド にまとめています。定義合意から HubSpot 実装まで伴走が必要な場合は、humbulls の Growth Partner サービス でご相談いただけます。
本文の判断を、そのまま AI で実行するためのキット集です。プロンプトは Claude (ブラウザ版で可) にコピペすれば動きます。
種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: 直近の受注顧客 5〜10 社の属性 (業種・規模・役職) と、その人たちが購入前にとった行動のメモ。営業へのヒアリングメモの貼り付けでも動きます。
プロンプト:
BtoB マーケティングの MQL 定義づくりを手伝ってください。
【自社の情報】
- 商材: (記入例) BtoB 向け SaaS・月額 5 万円〜
- 理想顧客像 ICP の仮説: (記入例) 従業員 50〜500 名の製造業、部長以上
- 受注顧客が購入前にとった行動: (思い出せる範囲で列挙。粒度バラバラで OK)
- 料金ページを複数回見ていた
- 導入事例を読んでいた
- (以下、自社のメモを貼り付け)
【定義のルール(必ずこの基準に従うこと)】
- MQL は Fit(属性)と Behavior(行動)の 2 軸を AND でつなぐ
- Fit だけ高く行動が無い人は「ナーチャリング対象」、行動だけ高く ICP 外は「保留」に分類し、MQL には含めない
- Behavior は「14 日以内に」等の期間を必ず付ける
【出力】
1. Fit 条件の案(属性の項目と、満たすべき水準)
2. Behavior 条件の案(行動の種類と、期間つきのしきい値)
3. 上記を AND でつないだ MQL 定義の文章(営業に見せて合意を取れる 3〜5 行)
4. 定義から外れる「ナーチャリング対象」「保留」の線引きも 1 行ずつ
出力の確認ポイント:
うまくいかないとき:
種別: 判断キット 使うもの: Claude (ブラウザ版で可) 事前に用意するもの: キット①で作った MQL 定義。営業チームの人数と、1 日に対応できるおおよそのリード件数。
プロンプト:
MQL の次の SQL 昇格条件と、営業との SLA のたたき台を作ってください。
【前提】
- MQL の定義: (キット①の出力を貼り付け)
- 営業体制: (記入例) 営業 3 名、1 人が 1 日に着手できる新規リードは 5 件まで
【設計ルール(必ずこの基準に従うこと)】
- SQL への昇格は「営業がリードに着手すると決めたアクション」を起点にする(マーケの自動更新で SQL にしない)
- SLA には「反応時間」「リジェクト理由の選択肢」「月次フィードバック」の 3 つを必ず入れる
- 反応時間は通常 24 時間以内、デモ申込など高インテントは 1 時間以内を基準にする
【出力】
1. SQL 昇格の条件文(何が起きたら SQL とみなすか、営業のアクションで定義)
2. SLA 表(反応時間 / 対象 / 担当)
3. リジェクト理由の選択肢リスト(5〜7 個。時期尚早・予算なし・ICP 外 など)
4. 月次でリジェクト理由を MQL 定義に反映する運用の 3 ステップ
出力の確認ポイント:
うまくいかないとき: