営業に聞いたMQLは「会いたい人リスト」だった
「MQLの決め方」を調べると、ほぼ必ずこう書いてあります。
「営業部門とすり合わせて、MQLの定義を明確にしましょう」
正論です。私も素直にそうしました。そして、うまくいきませんでした。
営業にMQLの基準を聞きに行くと、返ってくるのは"売れる人"の条件ではなく、"会いたい人"の条件であることが、往々にしてあるからです。
これ、特定の会社の話ではなくて、BtoBの現場を10年見てきた中で何度も出会ってきた"あるある"です。今日はその構造と、じゃあ基準はどう作ればいいのかを、実務の順序に落として書きます。
前回の記事で「MQLやSQLの線引きは、誰が決めるべきか」に触れました。今回はその続き、「どう決めるか」の話です。
他記事：「お問い合わせ数」だけでみるのをやめた話
先に結論:MQLは「会いたい人」ではなく「売れる人」で決める
結論はシンプルです。
営業にMQLの基準を聞くと、営業の目標から逆算された「会いたい人リスト」が出てきがちです。でも、マーケと営業が本当に共有すべきは「売れる人リスト」——実際に受注までたどり着ける相手の条件です。
そして売れる人リストを作るには、基準の前にやることがあります。自社の商品が「誰に・どこが刺さるのか」の精査です。MQLとSQLの設定は、その営みの"先"にある。順序を逆にすると、勝てない領域を追い続けることになります。
なぜそう言い切れるのか。よくある光景から話します。
「MQLはエンプラ企業です」
こんな場面、見覚えないでしょうか。
あるBtoBメーカーの支援で、MQLの基準を作ろうと営業サイド（それも本部長クラス）にヒアリングしたときのことです。返ってきた答えは一言。
「エンプラ企業ですね」
……エンプラって、そもそも概念でしかないんですよ。なので具体を聞きます。「従業員数千人規模、ということですか？」—
—「いや、そういう明確なのはない。希望しているのは大手企業だ」。なぜ大手なんですか？—
—「1件あたりの単価が大きいから」。
なるほど、わかりました。とうなずきました。うなずいたんですが、なんだか嫌な予感がしました。
社長に聞いたら「エンプラ？なんで？」だった
後日、別件の確認で社長と話す機会があったので、ついでに聞いてみたんです。「MQLはエンプラ企業という方針で進んでいますが……」
返ってきたのは、
「エンプラ？ なんで？」
でした。経営は、その方針を把握していなかった。
よくよく整理すると、こういう構図でした。営業サイドだけがエンプラを狙いに行っていた。理由は、その年に達成しなければいけない受注数値から逆算すると、単価が大きい案件でないと間に合わなかったから。
ここ、大事なポイントなんですが——この判断自体は、間違いじゃないんです。目標数字を背負う現場としては、むしろ合理的な思考です。
問題は2つありました。
ひとつは、その方針が経営と握れていなかったこと。もうひとつは、もっと深刻で——仮にめちゃくちゃ努力したとしても、大手にはすでに入り込んでいる競合がいて、機能面で追いついていなかった。差別化を頑張っても勝てない領域だったんです。
つまり、「会いたい人」には会えても、「売れる人」ではなかった。
なぜ営業に聞くと「会いたい人リスト」になるのか
誤解してほしくないのは、これは営業が悪いという話ではないことです。
営業は自分が背負う目標から逆算して条件を挙げます。だからその条件は、自然と「目標を達成しやすい相手」＝会いたい人の条件になる。誰が担当してもそうなる、構造の問題です。
逆に、マーケが単独で基準を決めると何が起きるか。今度は営業が動かない基準ができあがります。「マーケがMQLと呼んでも営業が対応しないなら、その定義が間違っている」とはよく言われる通りです。
会いたい人リストと売れる人リストは、重なる部分もあります。でもズレたまま運用すると、商談は増えるのに受注が伴わない、リードは渡るのに営業が触らない——前回書いた「数字は動いているのに成果が出ない」状態が、ここでも再生産されます。
一般的な「決め方」と、その限界
念のため、世の中で知られている決め方も整理しておきます。
フィット×エンゲージメントの2軸。 相手が自社のターゲット像に合っているか（属性）と、買う気配があるか（行動）の両方で判定する。どちらか片方では不十分、という原則です。
BANT。 Budget（予算）・Authority（決裁権）・Need（必要性）・Timeline（導入時期）の4条件で商談の確度を見極める、IBMが1960年代に開発した古典的フレームワークです。
スコアリング。 属性と行動に点数をつけ、閾値を超えたらMQLとする方法。
どれも有用です。ただ、これらはすべて「何を基準にするか」の枠組みであって、「その基準値を、どこから持ってくるか」には答えていません。
エンプラの話に戻ると、「企業規模」という軸自体は間違っていない。問題は「大手」という値の根拠が、売れる実態ではなく営業の目標側にあったことでした。実務が詰まるのは、いつもここです。
MQLを決める前にやること:商品の"刺しポイント"を精査する
では基準値はどこから持ってくるのか。売れた実態と、売れる見込みの精査からです。
自社のユーザーや見込みリードには、いろいろな企業規模・業種が混ざっています。その中で、
どの規模帯・どのセグメントなら勝てるのか(勝てないのか)
どの機能・どの訴求が、どの相手に刺さるのか
実際に受注できた顧客には、どんな共通項があるのか
——つまり「どのように営業したら、誰に売れるのか」という、商品の刺しポイントの精査です。
さきほどのメーカーの例なら、大手は競合の機能優位で勝てない。では中堅ならどうか、特定業種ならどの機能が決め手になっているのか。ここを見ずに基準だけ先に決めると、勝てない土俵を全力で走ることになります。
MQLとSQLの設定は、この営みの"先"にあります。 基準づくりとは、突き詰めると「自社はどこでなら勝てるのか」を言語化する作業なんです。
基準は「変数」で決まる——絶対的な正解はない
もうひとつ、実務で大事な視点があります。MQL/SQLの基準は固定の正解があるものではなく、自社の変数の組み合わせで決まるということです。
大きくは「プロダクトの力」による影響と、「企業体制」による影響の2系統があります。
プロダクトの力に関する変数
競合に対する機能の優位性(勝てる規模帯・業種が決まる)
単価・価格帯(狙うべき企業規模が決まる)
導入実績のある業種・規模(刺しやすいセグメントが決まる)
企業体制に関する変数
営業の人数・稼働リソース
年間の受注・売上目標
インサイドセールスの有無
経営と営業の、目標の握り度合い
リード側の変数
獲得できるリードの母数
リードの確度の分布
たとえば、営業リソースがかなり限られていて「確度の高い商談が月1件あれば十分」というケース。この場合、MQLの基準は思い切って上げていい。逆にリソースが潤沢で母数を捌けるなら、基準を下げて機会損失を防ぐほうが合理的です。
同じ業界でも、会社が違えば正解は違う。他社のMQL基準をコピーしても機能しないのは、この変数が違うからです。
最後に線を引くのは、経営・事業統括
ここまでの変数を眺めると、あることに気づきます。「年間目標」「リソース配分」「どの領域で戦うか」——基準を決める主要な変数は、事業全体を見ている人にしか動かせないものばかりです。
だから前回も書いた結論に戻ります。MQL/SQLの線引きは、営業単独でもマーケ単独でもなく、経営者・事業統括がジャッジする。あのメーカーの件も、営業の判断そのものより「経営と握れないまま走っていた」ことが本質的な問題でした。
マーケと営業の合意を文書にする考え方は、SLA（Service Level Agreement）として広く知られています。海外ではHubSpotがマーケと営業のSLAの作り方を公開していますが、あれも要するに「口約束にせず、上位の合意として文書で握れ」という話です。
そして一度線を引いたら終わりではなく、営業がリードを却下した理由を貯めていくと、基準は運用の中で勝手に育っていきます。このあたりは前回の記事のSALの話とつながります。
他記事：「お問い合わせ数」だけでみるのをやめた話
明日からできる、最小の一歩
いきなりスコアリング設計をしなくて大丈夫です。私ならこうします。
STEP1:営業に「基準」ではなく「直近で受注できた商談の話」を聞く。 聞き方を変えるのがコツです。「MQLの条件は？」と聞けば会いたい人が返ってきますが、「最近決まったあの案件、何が決め手でした？」と聞けば売れた実態が返ってきます。
STEP2:受注できた顧客5社の共通項を書き出す。 データが整っていなくても、記憶ベースで構いません。
STEP3:規模帯ごとに「勝てる/勝てない」を仕分ける。 これが刺しポイントの精査の第一歩です。
STEP4:自社の変数を書き出す。 営業リソース、年間目標、リードの母数。基準を高くすべきか低くすべきかは、ここで決まります。
STEP5:たたき台を、経営・事業責任者に持っていく。 完成度は6割でいい。線を引く場に、事業全体を見ている人を巻き込むことが目的です。
まとめ:基準は「正解」ではなく「合意」
MQLの定義に、唯一の正解はありません。プロダクトの力で変わり、体制で変わり、事業フェーズでも変わります。
大事なのは、会いたい人ではなく売れる人で考えること。そして、その線を経営と握り、定期的に見直せる状態を作ることです。
「売れる人リスト」を突き詰めていくと、最初から売れる相手を狙い撃ちする考え方——ABM（アカウントベースドマーケティング）に行き着きます。このあたりは、また別の記事で書こうと思います。
