MQLの定義を営業と合意する手順と判断基準

結論：MQLは「スコア」ではなく「営業が次に取る行動」で定義する

MQLの定義は、点数ではなく営業側の次アクションで合意してください。「70点以上」ではなく「今週中に電話する対象」と表現すると、営業とマーケの認識が揃います。合意の順序は、営業が実際に会えたリードの共通項を洗い出す→条件を文章化する→スコア項目に翻訳する、の3段階です。

定義づくりを先にスコア設計から始めると、必ず揉めます。点数は合意した定義を運用に落とすための道具であり、定義そのものではありません。

本記事では、定義の言語化から合意会議の運び方、見直しの周期までを手順として整理します。

※本記事は2026年9月時点の情報をもとに作成しています。

MQLとは：定義と、SQL・SALとの境界

MQLとは、マーケティング活動の結果として、営業がアプローチする価値があるとマーケティング部門が判断したリードを指します。Marketing Qualified Leadの略です。

重要なのは「判断したのはマーケティング部門である」という点です。営業が受け取って有効だと認めた時点で、呼び名は変わります。

この3段階を分けずに「MQL」とだけ呼ぶと、責任の所在が曖昧になります。マーケはMQLの量に責任を持ち、営業はSAL以降の処理に責任を持つ、という切り分けが出発点です。

なお、SALを置かずMQLから直接SQLへ進める組織もあります。段階の数より、各段階で誰が何を判断するかが明文化されているかが重要です。

手順1：営業が会えたリードの共通項を洗い出す

最初にやるのは、定義の議論ではなく事実の棚卸しです。直近半年で商談化したリードを一覧にし、営業に「なぜ会えたか」を聞いてください。

聞き方は具体的にします。「良いリードとは何か」と抽象的に尋ねると、「決裁者」「予算がある」といった当たり前の答えしか返りません。個別のリードを指して「この人はなぜ会えたのですか」と聞くと、実際の判断基準が出てきます。

出てきた要素は、次の4象限に分類すると整理しやすくなります。

多くの組織で不足するのは「課題・状況」です。ここが空欄のままスコアだけ精緻化しても、営業が求める情報は埋まりません。

逆に、商談にならなかったリードも同数程度抜き出し、何が欠けていたかを確認します。落ちた理由の共通項が、除外条件の原案になります。

手順2：定義を「文章1つ＋除外条件」で書く

MQLの定義は、1つの文章と除外条件のリストで書きます。箇条書きの条件を並べるより、読んだだけで判断できる形が運用に耐えます。

文章のひな形は次の通りです。「（企業条件）に該当する企業の（役職・部署条件）が、（行動・課題の条件）を示した状態」。ここに「営業は◯営業日以内に◯の方法で接触する」という処理の約束を添えます。

除外条件は、定義本文より重要になる場面が多くあります。既存顧客、競合、学生、取引対象外の規模、過去に明確に断られた先などを列挙してください。

定義文は営業の会議で読み上げてもらい、詰まらずに理解できるかを確認します。読み手が解釈を挟む余地があれば、まだ曖昧です。

手順3：合意会議の進め方と、決めるべき4項目

合意会議は1回で終わらせず、2回に分けます。1回目は事実の共有、2回目は決定です。間に営業側が現場に持ち帰る時間を挟むと、後からの蒸し返しが減ります。

会議で決めるのは次の4項目だけに絞ってください。

1. MQLの定義文と除外条件
2. 引き継ぎ時に必ず添える情報の項目
3. 営業の一次接触の期限と手段
4. 差し戻しのルールと、その記録先

差し戻しルールは特に重要です。営業が「これはMQLではない」と判断した場合に、どこへ、どんな理由コードで戻すかを決めます。理由コードがないと、差し戻しは口頭の不満として消えます。

接触期限や役割分担の合意は、MQLの引き継ぎとSLA設計の考え方と併せて設計すると整理しやすくなります。

決めた内容は1ページの文書にまとめ、双方の責任者が承認します。長い資料にすると誰も読み返しません。

手順4：見直しのサイクルを先に決めておく

定義は初回で正解にならない前提で、見直し周期を最初に決めます。決めていないと、ずれたまま半年が過ぎます。

推奨は、月次で差し戻し理由を確認し、四半期で定義文そのものを見直す運用です。月次は運用の微調整、四半期は条件の追加・削除を扱います。

見直し会議では、次の3つの数を確認します。MQLとして渡した件数、営業が受領した件数、差し戻しの理由内訳です。差し戻し理由が特定の1つに偏っていれば、その条件を定義に追加します。

定義を変えたら、変更日と変更理由を履歴として残してください。履歴がないと、過去の期間との比較ができなくなります。

また、製品ラインやターゲットセグメントが増えたときは、MQLを1本の定義で持たず、セグメントごとに分けることを検討します。1本の定義に無理に条件を詰め込むと、どの営業にとっても使いにくくなります。

よくある失敗のパターンと直し方

定義づくりでは、似た失敗が繰り返し起こります。代表的なものを挙げます。

スコアの閾値だけ決めて終わる。 「70点以上をMQL」と決めても、70点の内訳が人によって違えば営業は信用しません。直し方は、閾値の前に定義文を書き、スコアは定義を運用するための近似値として位置づけることです。

マーケだけで定義を作り、営業に通知する。 通知は合意ではありません。営業が自分の言葉で定義を説明できない限り、現場では使われません。直し方は、定義文の最終案を営業側に書いてもらうことです。

条件を増やしすぎて量が枯れる。 質を求めて条件を積み上げると、月に数件しか通らなくなります。直し方は、必須条件と加点条件を分け、必須条件は3つ以内に抑えることです。

除外条件を決めない。 既存顧客や競合が混ざると、定義そのものへの不信が生まれます。直し方は、初回の合意で除外条件を必ず明文化することです。

定義を変えたのに過去データを直さない。 期間比較ができなくなり、改善の議論が止まります。直し方は、変更履歴を残し、比較時は定義バージョンを併記することです。

LPやフォームの条件設計が原因で質がばらつく場合は、BtoB LPのCVRが頭打ちになるときの観点も合わせて確認してください。

この進め方が向いていないケース

MQL定義の精緻な合意は、すべての組織に適するわけではありません。次の条件では優先度を下げてください。

月間のリード件数が二桁に届かない場合。 母数が少ないと、共通項の抽出も差し戻しの傾向分析も成立しません。この段階では定義より、獲得経路の確保が先です。

営業組織が1〜2名で、全件を自分で見ている場合。 引き継ぎの摩擦自体が発生しないため、文書化の費用が便益を上回ります。

製品がPLG中心で、無料利用からの転換が主な流入経路の場合。 判断材料がプロダクト内の利用状況に偏るため、フォーム情報を前提としたMQL定義は噛み合いません。プロダクト利用のシグナル設計を別立てで検討します。

営業とマーケの責任者が異なる方針で評価されている場合。 定義の合意は、評価指標の不整合を解消できません。KPI設計の調整を先に行う必要があります。

組織変更や製品改廃が進行中の場合。 ターゲットが動いている最中に定義を固めると、すぐに作り直しになります。落ち着いてから着手してください。

よくある質問