MQL/SQLの定義と引き渡し基準｜マーケ・セールス間でのリード基準とSLA合意

マーケティングが獲得したリードをセールスが追わない。この状況に悩む組織の多くで、MQLとSQLの定義があいまいなまま引き渡しが行われています。「この数値以上なら渡す」「渡されたら何日以内に動く」という基準が言語化されていないと、マーケティングは量を追い、セールスは質に不満を持ち、両部門の信頼関係が損なわれます。

この記事では、MQLとSQLの定義の整理から始め、属性スコアと行動スコアによる判定基準の設計、閾値を受注データから逆算する手順、引き渡しSLAの設計と社内合意の進め方、そして月次で回す改善サイクルまでを順に解説します。読後に担当者が自社の設計に着手できる状態を目指しています。

連携設計の全体像はマーケティングとセールスの連携で整理しています。本記事ではMQL/SQLの引き渡し基準という一点に絞って深掘りします。

MQLとSQLの定義｜「誰が認定するか」が分岐点

MQLとSQLは「見込み顧客の熱量の高低」ではなく、「誰が認定するか」によって区別される概念です。MQLはマーケティング部門が一定の基準を満たしたと判断したリードを指し、SQLはセールス部門が商談に値すると判断したリードを指します。この認定主体の違いを最初に押さえておかないと、引き渡し基準を設計する前提が揺らぎます。定義のズレが引き渡し摩擦の出発点になるため、まず両概念を正確に整理します。

MQLの意味と役割

MQL（Marketing Qualified Lead）は、マーケティング部門が「育成・選別を経て一定の基準を満たした」と判断したリードです。受け取ったすべてのリードがMQLになるわけではなく、スコアリングや属性条件のフィルタリングを通過したリードだけがMQLとして認定されます。

日本企業、とりわけ新規開拓をセールスが独自に担ってきた組織では、MQLという概念が希薄になりやすい傾向があります。セールスが自力でリードを発掘する文化が根付いている場合、マーケティングからのリード供給の仕組みが整備されにくく、MQL/SQLの分類そのものが「外来の概念」として扱われることがあります。そのような組織でも、インサイドセールス機能を設けたり、デジタルマーケティングに投資したりするタイミングで、MQLの設計が急務になります。

SQLの意味と役割

SQL（Sales Qualified Lead）は、セールス部門が「商談に値する」と判断したリードです。実務上は、MQLを受け取ったセールスが内容を確認して「この案件はアプローチする価値がある」と受け入れた段階（SAL：Sales Accepted Lead）と、さらに具体的に商談できると判断した段階（SQL）の2段階に分けることがあります。

SQL認定の判断材料としてよく参照されるのがBANT条件です。

• Budget（予算）：自社製品・サービスを導入できる予算があるか
• Authority（決裁権）：商談相手が決裁権を持つか、または決裁者にアクセスできるか
• Need（必要性）：自社の提案が解決できる課題を抱えているか
• Timeline（導入時期）：具体的な検討時期・導入スケジュールがあるか

ただし、リード段階でBANTの全件を確認することは実務上難しいケースが多く、「NとTが確認できればSQL認定」のように、自社の商材・商談スタイルに合わせて運用する形が現実的です。

MQLとSQLの比較：定義・認定主体・基準の違い

MQLとSQLの核心的な違いは以下の3点です。

• 認定主体：MQLはマーケティング部門、SQLはセールス部門が認定します。
• 判断材料：MQLはスコアリング（属性×行動）、SQLはBANT条件または具体的なアクション（問い合わせ・デモ申込など）が判断材料になります。
• 次のアクション：MQLはセールスへの引き渡しと初回コンタクトの開始、SQLは具体的な商談設定が次のアクションになります。

「MQL数の最大化」と「SQL転換率の最大化」がトレードオフになりやすい理由も、この構造から説明できます。MQL認定の閾値を下げれば数は増えますが、セールスから見ると「商談にならないリードが増えた」と映ります。閾値を上げれば転換率は上がりますが、マーケティングが渡せるリード数は絞られます。この張力を認識した上で設計に入ることが重要です。

MQL判定基準の設計｜属性スコアと行動スコアの2軸

MQL判定基準の核心は、「属性（誰か）」と「行動（何をしたか）」の掛け合わせにあります。属性だけでは検討意欲が見えず、質の高そうな会社からのリードでも温度が低ければセールスは動けません。行動だけでは、ターゲット外の顧客や競合調査目的のアクセスを拾いすぎます。2軸のスコアリングを組み合わせることで、「自社に合う見込みが高く、かつ今検討している」リードを客観的に絞り込めます。以下では、属性・行動それぞれの設計手順と、閾値を感覚ではなく受注データから逆算する方法を示します。

属性スコアの設計（ファームグラフィック）

属性スコアは、そのリードが自社のICP（Ideal Customer Profile：理想顧客像）に合致しているかを数値化したものです。配点の対象となる属性項目の例を以下に示します。

• 役職・職位（例：部長以上に高配点、現場担当者には低配点）
• 決裁権限（予算権限の有無）
• 従業員規模（自社のターゲット規模帯に合致しているか）
• 業種（優先ターゲット業種かどうか）
• 地域（営業対応可能エリアか）
• 予算保有（ヒアリング済みの場合）

属性スコアには、ポジティブスコアとネガティブスコアの両方を設定する必要があります。ポジティブスコアはICP合致度を加算するもので、ネガティブスコアは「競合企業のドメイン」「学生・個人での登録」「ターゲット外の業種」などに対してスコアを減算します。ネガティブスコアを設けないと、属性情報が不完全なリードが高得点になる歪みが生じます。

行動スコアの設計（インテントシグナル）

行動スコアは、リードがどのような行動を取ったかを数値化し、検討意欲（インテント）を推定するものです。

高配点アクションの例は以下のとおりです。

• 料金ページ・プランページの閲覧
• 導入事例ページの閲覧
• 資料・ホワイトペーパーのダウンロード
• 問い合わせフォームの送信
• ウェビナー・セミナーへの参加
• デモ申込ページへのアクセス

低配点アクションの例は以下のとおりです。

• ブログ記事の閲覧（1回）
• メールの開封（クリックなし）
• トップページへのアクセス

ネガティブスコアを適用するケースの例は以下のとおりです。

• 90日以上の無反応（スコアの減衰処理）
• 退会申請・配信停止
• キャリア採用ページの複数回閲覧（採用目的の可能性が高い）

行動スコアの配点は、後述する閾値の設定と一体で設計します。高配点アクションに配点を集中させすぎると、1回の問い合わせだけでMQL認定されてしまうケースが生じるため、複数のインテントシグナルの組み合わせでMQL閾値を超える設計が望ましいです。

閾値（MQLライン）の決め方：感覚ではなく受注データから逆算する

多くの組織でスコアリングの閾値が「なんとなく50点」「100点満点で70点」のように感覚で設定されています。この設計では、MQL認定されたリードが受注に至るかどうかとの相関が検証されておらず、閾値の妥当性を判断する根拠がありません。受注データから逆算する方法を取ることで、「実際に受注したリードが持っていた特徴」を閾値に反映できます。

逆算の手順は以下のとおりです。

• 過去6〜12ヶ月の受注案件から、商談化前のリード行動ログを抽出します。SFAやMAに蓄積されたアクセスログ・メール反応データが素材になります。
• 受注に至ったリードに共通する行動パターンを上位3〜5アクション特定します。例えば「料金ページを2回以上閲覧」「資料DLあり」「問い合わせ以外のアクションが3回以上」といったパターンが浮かび上がることが多いです。
• その行動パターンを現在のスコアリング配点に照合し、受注リードのスコア分布を確認します。受注リードが平均的に何点の状態で商談化していたかを可視化します。
• 受注リードのスコア分布において50〜75パーセンタイルの値を、閾値の仮設定とします。受注リードの過半数がこの閾値を超えている水準が目安です。
• 3ヶ月間運用後にMQL→SQL転換率と受注率を確認し、閾値を調整します。転換率が想定より低ければ閾値を引き上げ、MQL数が少なすぎればやや引き下げる判断をします。

この手順を踏むことで、「なぜこの閾値なのか」という根拠をセールスに説明できるようになります。スコアリングに対するセールスの納得感が、引き渡し後のアクション率に直接影響します。

SQLの判定基準｜セールスが「商談に値する」と判断する条件

MQLを受け取ったセールスが「この案件は商談できる」と判断する基準がSQLです。BANT条件は広く参照されていますが、リード段階では全条件を満たせないことが多く、実務的には「具体的なアクション（問い合わせ・デモ申込など）を伴うMQL」がSQLの起点として機能するケースが多いです。SQL基準を明確にしておくことは、マーケティングへのフィードバック品質を高める前提にもなります。マーケティングが「なぜこのリードがSQLにならなかったのか」を学ぶためには、セールスのSQL判断基準が言語化されている必要があるからです。

BANT条件とその限界

BANTはSQL認定の代表的なフレームワークですが、リード段階での適用には限界があります。

BtoBのリードでは、初回の問い合わせや資料ダウンロードの段階でBudget（予算）やTimeline（導入時期）が明確になっていないことが大半です。予算がある程度確保されていても、担当者がそれを開示しないケースも多くあります。

実務的な対応としては、「NとTが確認できればSQL」「NとAが確認できればSQL」のように、4条件から2〜3条件に絞った版を自社の商材・商談スタイルに合わせて定義することが有効です。重要なのは、「BANT条件を何件確認できたか」という量ではなく、「商談を進めることで受注できる可能性があるか」という判断の質です。

具体的なアクションをSQL基準に加える

「問い合わせフォーム経由のMQL」と「メールナーチャリングを経て資料ダウンロードしたMQL」では、SQLへの移行期待値が異なります。前者はすでにコンタクトの意思を示しており、初回の返答から商談設定に移行しやすいです。後者は興味はあるものの、まだ自発的な接触段階ではありません。

この違いを反映させるために、「特定の行動を伴うMQLを優先SQL候補とする」設計が有効です。例えば以下のような条件が実務で使われます。

• デモ申込ページへのアクセスがあるMQL
• 料金ページを3回以上閲覧しているMQL
• 問い合わせフォームから直接送信されたMQL
• ウェビナーに参加し、終了後のフォローアップメールをクリックしたMQL

こうした行動を伴うMQLに対しては対応期限を短く設定し（例：受領後1営業日以内）、行動を伴わないMQLとは優先度を分けて扱う運用が、セールスの工数対効果を高めます。

MQL→SAL→SQLの3段階運用が有効なケース

SAL（Sales Accepted Lead）は、セールスがMQLを受け取り「確認する価値がある」と受け入れた状態を指します。MQLを受け取ったがまだSQL判定には至っていない中間段階です。

この3段階が機能するのは、インサイドセールス（IS）とフィールドセールス（FS）の役割が分かれている組織です。ISがMQLを受け取ってSAL認定し、初回コンタクトとBANT確認を行い、商談価値があると判断したものをSQLとしてFSに引き渡す流れが典型的です。

一方、営業効率化の観点から営業規模が小さく、ISとFSの分業が確立されていない組織では、MQL→SQL直結の2段階運用のほうがシンプルで機能することが多いです。段階を増やすことで管理コストが上がり、かえって引き渡しが停滞するリスクがあります。自社の営業組織の構造に合わせてどの段階設計を採用するかを判断してください。

引き渡し基準とSLAの設計｜マーケ・セールス間の合意を数値と期限で結ぶ

スコアリング設計だけでは引き渡し摩擦は解消しません。「何点以上がMQL」という基準が決まっても、「渡された後にセールスがいつ・どう動くか」「セールスがMQLを使わなかった理由をどうマーケティングに返すか」が決まっていなければ、機能しない設計になります。「どのタイミングで・誰が・どう対応するか」を数値と期限で明文化したSLAがあってはじめて、両部門の期待値がそろいます。以下では、引き渡しSLAに盛り込むべき項目と、社内合意の進め方を具体的に示します。

マーケとセールスのSLA設計では引き渡しSLAの詳細な全体設計を扱っています。本節ではMQL/SQLの引き渡しに直結する項目に絞って整理します。

SLAに盛り込む6つの必須項目

MQL/SQL引き渡しSLAに盛り込む必須項目は以下の6つです。

• MQLの定義 スコアリングの閾値（例：属性スコア＋行動スコアの合計が70点以上）と属性条件（例：従業員規模100名以上・特定業種）を数値で記載します。「ある程度温まったリード」のような表現は使わず、誰が見ても同じ判定ができる言語化が必要です。
• 引き渡し方法 SFAやCRMの案件レコードまたはコンタクトレコードへの登録方法、担当セールスへの通知トリガーを明記します。自動通知が組める場合は通知経路（Slackチャンネル、メールアドレスなど）も合わせて記載します。
• 引き渡しタイミング MQL認定後〇時間以内に担当セールスへ通知する、という時間基準を定めます。リードへの初回コンタクトが早いほど商談化率が上がることが多く、「翌営業日以内の通知」を目安にしている組織が多いです。
• セールスの対応期限 MQLを受領後〇営業日以内に最初のアクション（電話・メール）を行うという期限を定めます。高優先度MQL（具体的アクション伴う）と通常MQLで期限を分けることも有効です。
• フィードバックの方法 SQL非採用（セールスがMQLを追わないと判断した）場合に、理由をどの項目で・いつまでに返すかを定めます。理由の選択肢（例：ターゲット外・時期が合わない・予算なし・すでに競合選定済み）を事前に決めておくと、フィードバックの品質が安定します。
• 基準の見直し頻度 四半期ごとにMQL→SQL転換率をマーケ・セールスで合同レビューし、基準を更新する機会を制度化します。一度決めた基準を変えないことが形骸化の最大の原因です。

SLAを社内合意させる進め方

SLAの設計で最も避けるべき失敗は、マーケティング部門だけでMQLの定義と引き渡しルールを作ってしまうことです。セールスが設計に参加していないSLAは、形式上の文書にとどまり、現場で守られません。

合意プロセスとして実務的なのは以下の順序です。

まず、マーケとセールスの両責任者が過去データを持ち寄ります。マーケティング側は「渡したMQLの数・スコア分布・その後の転換率」、セールス側は「受け取ったリードの中で実際に商談になった割合・ならなかった理由の感覚値」を共有します。

次に、数値から課題を合意します。「転換率が低い」「渡したのに追ってもらえない」という互いの不満を、感情論ではなくデータで可視化することで、「何を変えれば改善するか」という共通認識を作ります。

その上で草案を作成し、1ヶ月のパイロット運用を行います。設計通りに動けるかどうか、運用上の障害がないかを短期間で検証します。

パイロット後に転換率と対応率のデータをレビューし、数値の変化を確認してから正式合意に移行します。

合意後は、Notionやスプレッドシートなど誰でも参照できる場所にSLAの内容を残します。口頭での合意は「言った・言わない」の齟齬を生みます。文書として残しておくことで、担当者が変わった際の引き継ぎにもなります。

ツールが整備されていない場合の最小設計

MAや高度なSFAが整備されていない組織でも、MQL/SQLの基準設計と運用は可能です。「ツールが揃ってから始める」を待つ間にも、リードは毎月発生しています。スコアリングの自動計算とMQL認定通知の自動化は難しくなりますが、基準そのものはツールなしでも合意・運用できます。

スプレッドシートでMQLリストを管理する場合の最小フォーマット例として、以下の項目が基本になります。

• コンタクト名・会社名
• スコア合計（属性スコア＋行動スコアを手動集計）
• 認定日
• 担当セールス
• 対応期限
• フィードバック日
• SQL可否（○／×）
• 不採用理由（選択肢から選ぶ形式）

通知の自動化が難しい場合は、MQL認定のタイミングでマーケティング担当者がSlackや社内メールで担当セールスに直接連絡する運用でもかまいません。ツールの整備と並行して、まず「誰が認定し・誰に・何を・いつまでに渡すか」という基準の合意を先行させることが重要です。基準が明確になってから初めて、自動化の設計に移れます。

よくある失敗パターンと対策

MQL/SQL基準を設計しても「機能しなくなる」ケースには共通したパターンがあります。設計の品質よりも、運用定着を阻む構造的な問題が原因になっていることがほとんどです。特に、マーケ単独でのMQL定義・MQL数だけのKPI設定・フィードバックの形骸化という3つは、多くの組織で繰り返されるパターンです。

マーケティング部門だけでMQLを定義している

原因は、スコアリング設計がマーケティングの内部作業として完結してしまうことです。属性条件や行動配点をマーケティング側だけで決めると、「マーケティングが『良いリード』と思う定義」と「セールスが実際に商談にしたリードの特徴」が乖離します。

結果として、渡されたリードをセールスが「見込みなし」と判断して追わない状況が生まれます。セールスからすると「スコアが高くても商談にならないリードが来る」経験が積み重なり、スコアリング自体への不信感につながります。

対策は、設計段階からセールスを巻き込み、「過去受注リードがスコアリング上どのような値を持っていたか」を一緒に検証することです。特に「受注につながったMQLの共通行動」をセールスと合意することで、スコアリングの配点根拠を両部門で共有できます。

MQL数だけをKPIにしている

原因は、マーケティングの成果指標としてMQL数が設定されることにあります。MQL数を達成するために最も手っ取り早い方法は、閾値を下げることです。

閾値を下げればMQL数は増えます。しかし、セールス側では「商談にならないリードが大量に来るようになった」という体験が蓄積され、MQLへの対応優先度が下がっていきます。この状態が続くと、マーケティングは数字を達成しているのにセールスとの関係が悪化するという逆説的な状況が生まれます。

対策は、MQL数ではなくMQL→SQL転換率とMQL起点の受注率をKPIの中心に置くことです。渡した数より、渡した後の結果を基準にすることで、「質の高いMQLを渡す」というインセンティブが設計に組み込まれます。マーケとセールスの共通KPIの設計に合わせてこの指標を位置づけることで、両部門の評価軸がそろいます。

フィードバックが仕組み化されていない

原因は、「SQL非採用」の理由がセールスの頭の中にとどまり、マーケティングに届かない構造です。セールスが「このリードはダメだった」と思っていても、それを記録・伝達する仕組みがなければ、マーケティングは次の改善に使えません。

結果として、スコアリング基準が実態と乖離し続けます。マーケティングは良いと思うリードを渡し続け、セールスはそれを追わない状態が固定化します。

対策は、SFAや案件管理ツールの案件レコード・コンタクトレコードに「MQL由来フラグ」と「不採用理由の選択肢」を設け、セールスが入力する運用を義務化することです。例えばMazrica Salesのような案件管理ツールでは、コンタクトや案件ごとに任意項目を追加して、MQL由来フラグや不採用理由の記録を運用できます。こうした仕組みを持つツールの一例として参考にしてください。フィードバックデータが蓄積されることで、マーケティングは「どの行動スコアが高くても商談にならないパターン」を特定し、スコアリングの精度を上げていけます。

引き渡し基準の運用と改善｜PDCAを月次で回す

MQL/SQL基準は一度作って終わりではなく、実績データを月次で確認しながら改善するものです。市場環境・製品ラインナップ・営業組織の変化によって、過去に有効だった基準が陳腐化することがあります。KPIの計算方法と改善の起点を押さえておくことで、基準の形骸化を防ぎ、実態に即したスコアリングを維持できます。

最重要指標：MQL→SQL転換率の計算と目安

MQL/SQL設計の健全性を測る最も重要な指標がMQL→SQL転換率です。

計算式はシンプルです。

SQL数 ÷ MQL数 × 100 ＝ MQL→SQL転換率（%）

業界全体のベンチマーク値は業種・商材・商談期間によって大きく異なります。「BtoBであれば〇%が標準」と断定できるデータはなく、自社の過去実績との比較を基準にするのが現実的です。前四半期・前年同期との比較を継続することで、基準が機能しているかどうかの変化を捉えられます。

転換率が低い場合に見直す3点は以下のとおりです。

• 閾値の適切さ：低品質なリードがMQL認定されていないか、閾値が低すぎないかを確認します。
• 引き渡し後のセールス対応速度：MQLを受領してから最初のアクションまでの時間が長くなっていないかを確認します。リードへの対応が遅れるほど商談化率が下がる傾向があります。
• MQL情報の充実度：マーケティングがセールスに渡す情報量（スコア内訳・行動履歴・関心ページ）が不足していないかを確認します。情報が少ないと、セールスはMQLへのアプローチ方針を立てにくくなります。

月次レビューで確認する指標セット

月次レビューで確認すべき指標は以下のとおりです。

• MQL数（当月・前月比）
• MQL→SQL転換率
• SQL→商談化率
• MQL起点の受注率・受注金額
• 不採用MQLの理由分布（フィードバックデータ）

このうち「不採用MQLの理由分布」は特に見落とされがちですが、スコアリング改善の最も直接的な材料になります。「ターゲット外」が多ければ属性スコアの精度の問題、「時期が合わない」が多ければ行動スコアの閾値設定の問題、「すでに競合選定済み」が多ければナーチャリングの速度の問題として切り分けられます。

共通KPIの全体設計についてはマーケとセールスの共通KPIで詳しく解説しています。

見直しのトリガーと更新頻度

定期レビューは四半期ごとを基本とします。その上で、MQL→SQL転換率が前四半期比で10ポイント以上変動した場合には臨時レビューを実施します。大きな変動が起きた際に「何が原因か」を素早く特定し、基準に反映させることが重要です。

変動の原因を切り分ける際には、次の3つの問いから確認します。

• スコアリング配点の問題か：特定の行動スコアが過大・過小評価されていないか。
• 閾値の問題か：閾値が現在の市場環境・商材に合わなくなっていないか。
• 引き渡し後のオペレーション問題か：セールスの対応速度・対応率に変化がないか。

マーケ・セールスの定例会議設計では、このレビューを制度化する定例会議の進め方を詳しく解説しています。

まとめ：どの組織から設計に着手すべきか

リード引き渡し摩擦の根本は、MQL/SQLの定義があいまいなまま「渡した」「使わない」の循環が続くことにあります。スコアリング設計・閾値の受注データからの逆算・SLA合意という順序で着手することが、機能する設計への最短経路になります。

着手の優先度は自社の現状によって異なります。MAや案件管理ツールがある組織は、属性×行動の2軸スコアリングを先に設計し、閾値は3ヶ月の転換率データで検証する流れが有効です。ツール未整備の組織は、スプレッドシートでの最小設計から始め、基準の合意を先行させてからツールの整備に移ることをおすすめします。

次の一歩として現実的なのは、過去6ヶ月の受注案件を確認し、商談化前にそのリードが取った行動を3つ特定する作業です。受注に共通する行動パターンが見えてくることで、スコアリングの配点と閾値の設計に具体性が生まれます。全体の仕組みを一気に整備しようとするより、「受注リードの共通行動を起点に閾値を決める」という小さな作業から始めることが、両部門の合意形成においても現実的です。

MQL/SQL引き渡し基準はマーケとセールスの連携設計のひとつのパーツです。連携設計の全体像はマーケティングとセールスの連携で整理しています。

よくある質問

Q MQLとSQLの定義は誰が決めるべきですか？

A

マーケティングとセールスの両責任者が共同で決めることが前提です。どちらか一方が決めると、現場の運用で合意が得られにくくなります。特にスコアリングの配点と閾値は、「過去受注リードの行動パターン」をセールスと一緒に確認しながら設定することで、両部門が納得できる基準になります。

Q MQL判定基準に「正解の数値」はありますか？

A

正解の数値は存在しません。業種・商材・商談期間によって、MQLとして認定すべきリードの特徴は大きく異なります。自社の過去受注データから逆算した閾値を出発点にし、3ヶ月の運用後にMQL→SQL転換率で検証する方法が実務的です。他社のベンチマーク値は参考にとどめ、自社実績との比較で改善を続けることが重要です。

Q MAツールがなくてもMQL/SQLの運用はできますか？

A

できます。スコアリングの自動計算とMQL認定通知の自動化は難しくなりますが、スプレッドシートでのリスト管理と手動スコア集計でも、基準そのものは運用できます。「ツールが揃ってから始める」を待つ組織ほど、スコアリング基準の設計と両部門の合意を先行させることが重要です。ツールは基準が決まってから整備する順序が、定着率を高めます。

Q スコアリングを設定したのにセールスがMQLを使わない場合はどう対処しますか？

A

原因は「スコアの根拠が伝わっていない」か「対応しても受注しなかった経験が積み重なっている」のどちらかが多いです。前者への対応としては、SFAや案件管理ツールにスコア構成の内訳（属性スコア何点・行動スコア何点・どの行動で加算されたか）を表示させることが有効です。後者への対応としては、引き渡し初期の段階でマーケティングが1案件ずつスコアの根拠を説明するセッションを設けることで、セールスの納得感を作ることができます。

Q MQL数を増やすことと転換率を上げることは両立しますか？

A

短期的にはトレードオフが生じやすいです。閾値を下げればMQL数は増えますが、転換率は下がる傾向があります。「MQL数」と「転換率」を別々に管理するのではなく、「MQL起点の受注金額」を分母にした指標を持つことで、量と質のバランスを同時に評価できます。MQL起点の受注金額が増加しているかどうかを月次で確認することが、最終的な目的に沿った指標管理になります。

Q MQLとMALの違いは何ですか？

A

MAL（Marketing Accepted Lead）はマーケティング部門が「受け入れた」リードを指します。フォームからの流入やリスト取り込みによってデータとして存在するようになった状態であり、スコアリングを通過する前の全リードが対象になります。MQLはそのMALの中から、スコアリング基準を通過したリードです。MAL＞MQLという包含関係にあり、MALからMQLへの移行率を確認することで、リード全体の品質や獲得施策の傾向を把握できます。