リードクオリフィケーションとは？MQL/SAL/SQLの決め方とSLA設計【2026年版】

この記事でわかること:

• リードクオリフィケーションの定義と、獲得・育成・スコアリングとの位置関係
• 受注実績から逆算してMQL / SAL / SQLを自社で定義する4ステップ（テンプレの配布ではなく、自社の数字から作る手順）
• インサイドセールスと営業の受け渡し合意（SLA）の作り方と、そのまま使える合意書の雛形
• 「商談化したが失注」から判定基準を引き締める逆算の手順
• 判定基準の見直しサイクル（頻度・トリガー・担当・見る指標）
• MAツールなしで今日から回す最小構成と、MAが必要になる分岐条件
• DSR（デジタルセールスルーム）の資料閲覧シグナルを判定材料に足す方法

「マーケが渡してくるリードは質が低い」「営業がリードを放置している」「商談は増えたのに受注が増えない」——リードクオリフィケーションをめぐる問題の多くは、判定の方法ではなく、判定基準が言語化されていないことに起因します。

「スコアリングで確度の高いリードを選びましょう」という説明は数多く見つかりますが、実務でつまずくのはその手前です。本記事は、個々のフレームワークの中身やスコアの配点には立ち入らず、MQL / SAL / SQLをそれぞれどう定義するのか、その定義を自社の何のデータから導くのか、営業に渡したあと誰がいつまでに何をするのか——つまり**「リードを商談に上げるか否かを判定するプロセスそのもの」**の設計に絞って解説します。特定のツール導入を前提としない、ベンダー中立の内容です。

---

リードクオリフィケーションとは

リードクオリフィケーションとは、獲得・育成したリードのなかから受注確度の高い相手を判定し、営業部門へ引き渡す活動です。日本語では「リード選別」と訳されることもあります。マーケティング部門が集めたリードを、営業部門が時間を投じるに値する案件へと絞り込む「関門」の役割を担います。

言葉の意味と英語表記

英語表記は lead qualification です。qualification は「適性・資格」を意味し、動詞の qualify は「資格を満たす」「適格と認める」を表します。つまりリードクオリフィケーションは、リードを優劣で並べる作業ではなく、「営業が動く条件を満たしているか否か」を判定する作業だと捉えると設計を誤りません。

この違いは実務上とても重要です。「選別」という訳語からは上位何%かを抜き出す作業を連想しがちですが、本質は合否の判定です。合否である以上、判定には基準が必要で、基準がある以上は誰が・何を見て・いつ判定するかを決めなければ運用できません。本記事が「商談化基準の作り方」に紙幅を割くのはこのためです。

獲得・育成・選別のどこに位置するか

リードクオリフィケーションは、デマンドジェネレーションの全体像のなかで最終工程にあたります。前工程との関係を整理すると次のとおりです。

重要なのは、この4工程が一方向のベルトコンベアではないことです。判定で「まだ早い」となったリードは育成に戻り、商談化したが失注した案件も条件次第で育成に戻ります。判定はリードを捨てる工程ではなく、行き先を振り分ける工程です。

リードスコアリングとの違い — 「順番」と「合否」

リードクオリフィケーションとリードスコアリングは混同されがちですが、役割が異なります。

• リードスコアリングは、属性と行動を点数化してアプローチする順番を決める仕組み
• リードクオリフィケーションは、その順番のついたリードに対して営業に渡すか否かの合否を判定するプロセス

スコアリングは判定を助ける有力な道具ですが、判定そのものではありません。「スコア80点以上を営業に渡す」と決めた瞬間、80点という閾値が判定基準になります。つまりスコアリングを導入しても、判定基準を決める作業からは逃れられません。

配点の作り方・閾値の置き方・業種別の配点例といったスコアリングの設計論はリードスコアリングの配点モデルで詳しく扱っています。本記事では配点には立ち入らず、判定プロセスの設計に集中します。

---

なぜ判定プロセスを設計しないと壊れるのか

判定基準が言語化されていない組織では、リードクオリフィケーションは高い確率で機能不全に陥ります。原因は担当者の能力ではなく、構造にあります。

マーケと営業の相互不信はこうして生まれる

判定基準がないと、マーケティング部門は「渡せるものは渡す」方向に、営業部門は「渡されたものを疑う」方向に、それぞれ合理的に振る舞います。

マーケティング部門のKPIがリード数やMQL数であれば、判定を緩めるほど数字は良くなります。一方、営業部門のKPIが受注数であれば、確度の低いリードに時間を使うほど数字は悪くなります。両部門のKPIは、判定基準が曖昧なときに正面から衝突する設計になっているわけです。

この状態が続くと、営業は渡されたリードへの対応を後回しにし、マーケは「営業が動かないから成果が出ない」と考えます。どちらも自分のKPIに忠実なだけなので、話し合っても解決しません。解くべきは人間関係ではなく、両部門が同じ基準を見ている状態をつくることです。

量と質のトレードオフは「営業のキャパ」から解く

判定基準を厳しくすればリードの質は上がりますが量は減り、緩くすれば量は増えるが質は下がります。「バランスが重要」という結論だけでは運用できないので、本記事ではバランスの取りどころを数で決める方法を示します。

出発点として有効なのは、営業部門が1ヶ月に処理できる商談数から逆算する方法です。

【判定基準の厳しさを決める逆算】

① 営業1人が月に対応できる新規商談数を出す
   例）既存案件のフォローを踏まえ、月に対応可能な新規商談は N 件

② 営業人数を掛けて、組織として受け入れ可能な月間商談数を出す
   受け入れ可能商談数 = N × 営業人数

③ 現在の「引き渡し → 商談化」の実績率で割り戻し、
   月に引き渡してよいリード数の上限を出す
   引き渡し上限 = 受け入れ可能商談数 ÷ 商談化率

④ 現在の判定基準で引き渡されている件数と③を比べる
   ・実績 > 上限 → 基準が緩い。引き締める
   ・実績 < 上限 → 基準が厳しいか、母数が足りない

この逆算をすると、「基準が厳しすぎるのではないか」という感覚的な議論が、「営業のキャパに対して引き渡しが何件多いか」という数の議論に変わります。なお③で使う商談化率は、分母の取り方によって数字が大きく変わります。定義のずれを避けるため、商談化率の計算式と分母の取り方を先に部門間で揃えておくことをおすすめします。

---

【独自】MQL / SAL / SQLを自社で定義する4ステップ

判定プロセスの中核は、リードがどの状態になったら次の段階に進むのかを定義することです。ここで使われるのがMQL / SAL / SQLという3段階の呼び名ですが、他社の定義をそのまま持ち込んでも機能しません。定義は自社の受注実績から導く必要があります。

3段階はそれぞれ「誰の判断」か

まず、3つの用語が誰の判断を表すのかを押さえます。ここを取り違えると、以降の設計がすべてずれます。

MQLとSQLの2段階だけで語られることもありますが、実務で効くのは真ん中のSALです。SALがないと、「渡した／渡していない」の水掛け論が起きます。SALは品質を測る段階ではなく、受領の責任境界を作る段階だと理解してください。マーケの責任はSALまでで一度切れ、そこから先は受領側の責任になります。

Step 1: 受注実績からSQL条件を先に確定する

定義づくりはファネルの下流から始めます。MQLから決めると「マーケが渡しやすい条件」になり、営業の実感とずれるためです。

過去に受注した案件を10〜30件と、**同数程度の失注案件（商談化はしたが受注に至らなかったもの）**を並べ、商談化した時点で何が確認できていたかを洗い出します。商談化に至らなかったリードはこの時点が存在しないため、ここでは対象にしません（Step 2 のMQL時点の比較で使います）。受注側だけを見ると、次のステップで必要になる「受注と失注を分けた条件」が取り出せません。見るべきは次のような項目です。

• 解決したい課題が、担当者の言葉で具体的に語られていたか
• 導入を検討する時期に言及があったか
• 予算の有無、または予算化のプロセスに言及があったか
• 検討に関与する部署・役職が把握できていたか
• 自社のターゲット条件（業種・規模・利用環境）に合致していたか

これらのうち、受注案件のほとんどに存在し、かつ失注案件にはあまり存在しなかった項目がSQL条件です。逆に、受注案件でも半々にしか存在しなかった項目や、失注案件にも同じくらい存在した項目は、SQL条件から外します。後者は「確認はできるが、勝敗を分けていない」項目であり、条件に入れても判定は良くなりません。SQL条件を増やしすぎると、SQLに上がる案件がほぼゼロになり基準として機能しません。

Step 2: SQLに到達した案件がMQL時点で満たしていた条件を抜き出す

次に、Step 1 で並べた受注案件のほうについて、引き渡された時点（＝MQL時点）で何が分かっていたかを遡ります。比較のため、失注案件（商談化はしたが受注に至らなかったもの）に加え、Step 1 では対象外とした「引き渡したが商談化に至らなかったリード」も同数程度（以下、第3群）並べます。MQL時点であればこれらにも引き渡し時のデータが残っており、「そもそも商談にならない条件」を切り分けられるためです。ここで見るのは、営業と話す前にマーケ側のデータだけで観測できた情報です。

• 企業属性（業種・従業員規模・所在地など、ターゲット条件との一致）
• 個人属性（部署・役職）
• 行動（どのコンテンツを見たか、資料請求・問い合わせの有無、セミナー参加）

ここで見つけたい共通項は「よく見られたページ」ではなく、群を分けた条件です。3群すべてに等しく現れる行動（例: トップページの閲覧）は、判定基準としての価値がありません。

見るべきは次の2方向です。

• 受注案件にだけ多く現れた条件 → MQLの属性条件・行動条件にする（＝引き渡す条件）
• 商談化に至らなかったリードにだけ多く現れた条件 → MQLの除外条件にする（＝引き渡さない条件）

第3群を並べたのはこの除外条件を取り出すためです。除外条件の例としては、競合・個人利用・採用目的といったターゲット外の属性が典型です。除外条件はStep 3 の検算で「条件が緩い」と出たときに足す材料になります。

Step 3: MQLの条件を仮置きし、母数で検算する

Step 2 で抽出した条件を組み合わせてMQLの定義を仮置きし、その条件で過去のリードを再判定したら何件がMQLになるかを数えます。

【MQL定義の検算】

仮の定義でフィルタした件数 = A 件／月

A が「なぜ判定プロセスを設計しないと壊れるのか」で
算出した引き渡し上限を大きく超える   → 条件が緩い。属性条件を足すか、
                                        除外条件（競合・個人利用・採用目的等）を足す
A が上限を大きく下回る               → 条件が厳しい。行動条件を1つ外す
                                        もしくは母数（獲得）自体が不足

この検算を飛ばすと、**「定義は美しいが、該当するリードが月に2件しかない」**という状態になりがちです。定義は運用可能な件数に着地して初めて基準として成立します。

なお、母数そのものが足りない場合は判定基準をいじっても解決しません。獲得施策の見直しが先です。手法の選択肢はBtoBリード獲得の方法にまとめています。

Step 4: SALを挟んで「受け取ったか」の責任境界を作る

最後に、MQLとSQLのあいだにSALを挟みます。SALで決めるのは品質ではなく、受領のルールです。

• 受領側は、引き渡しから何営業日以内に「受け取る／差し戻す」を返すか
• 差し戻す場合、どの理由コードを付けるか
• 差し戻されたリードは、どこへ戻るか（育成へ／保留へ／対象外へ／マーケへ差し戻し）

SALを置くと、引き渡し件数・受領件数・差し戻し件数という3つの数字が取れるようになります。この差し戻し率こそが、判定基準が緩いか厳しいかを測るもっとも早いシグナルです（詳しくは「判定基準の見直しサイクル」で扱います）。

【補足】判定の単位を「個人リード」から「買い手グループ」へ

もう1つ、定義づくりで見落とされがちな論点があります。判定の単位を個人リードのままにしてよいのかという問題です。

調査会社の Forrester は2021年5月4日、B2Bの需要管理モデルである B2B Revenue Waterfall を発表しました。これは Forrester 自身が「旧称 SiriusDecisions Demand Unit Waterfall®」と述べているとおり、同 Waterfall を更新したもので、リード単位ではなくバイインググループ（購買に関与する集団）とオポチュニティを単位に据え直したものです。モデルの原型をつくったのは調査会社 SiriusDecisions で、Forrester は同社の買収を2019年1月3日に完了しています（出典: Forrester プレスリリース「Forrester Completes Acquisition Of SiriusDecisions」 2019年1月3日、2026年8月29日確認）。本記事では2019年1月3日より前に発表された資料を引く際、発表主体を SiriusDecisions と表記します。

同発表のなかで Forrester は、自社の B2B Buying Study の結果として「80%を超える購買が複雑な購買シナリオを伴う」と述べています。Forrester はこの複雑な購買シナリオを合議型（consensus）と委員会型（committee）に分けており、このうち合議型は原文で「consensus scenarios where 95% of current purchases involve three or more people across two or more departments」と説明されています。この95%という数字は合議型シナリオの説明として原文に記されたものであり、「B2B購買全体の95%が3人以上の関与を伴う」と読むのは原文の係り受けを超えた解釈になります。原文の構文が曖昧なため、孫引きの過程で数字の意味が変わりやすい箇所なので注意してください。

同社の Monica Behncke 氏（VP, Group Research Director）は、発表のなかで次のようにコメントしています。

"The new role of marketing and sales is to help buyers progress through their buying journey — not push leads through a funnel or pipeline."

（出典: Forrester プレスリリース「Forrester Debuts Next-Generation B2B Revenue Waterfall To Help Firms Accelerate Revenue Growth」 2021年5月4日、2026年8月29日確認）

ここから読み取るべき示唆は2つあります。

1つは、1人のリードのスコアだけで判定すると、購買の実像を取り逃すということです。同じ企業から3人が別々に資料請求している状態は、1人が3回請求している状態とは意味がまったく違います。判定基準に「同一企業からの複数名の関与」を条件として入れられないか検討する価値があります。

もう1つは、業界標準とされるモデルですら作り直されているという事実です。SiriusDecisions（当時。現在は Forrester のサイトで公開）のブログ「Meet the Newest SiriusDecisions Demand Waterfall!」（2017年5月17日、2026年8月29日確認）によれば、Demand Waterfall は2006年に登場し、2012年に再設計され、2017年に Demand Unit Waterfall となりました。さらに前掲のプレスリリースのとおり、2021年に B2B Revenue Waterfall へと更新されています。判定基準は一度作って終わりにするものではなく、見直す前提で作るものだという裏付けとして受け取るのが妥当でしょう。

---

誰が判定するのか — マーケ・インサイドセールス・営業の分界点

「リードクオリフィケーションは誰がやるのか」という問いに一つの正解はありませんが、判定を1部門に集約すると歪みやすいという点は共通しています。実務では、判定を3つに分けて分担するのが扱いやすい形です。3段階それぞれの定義は前章の表を参照してください。ここでは誰が・何を見て判定するかに絞ります。

一次判定はデータで機械的に行い、二次判定は会話で人が行う——この役割分担が基本形です。データで分かることを人が確認し直すのは無駄であり、会話でしか分からないことをデータで代替しようとするのも無理があります。

インサイドセールスを置いている組織では、インバウンド対応とアウトバウンド開拓で判定の設計が変わります。役割の切り分けはSDRとBDRの役割分担を、判定件数をKPIに落とし込む方法はインサイドセールスのKPI設計を参照してください。

---

判定手法の使い分け

判定手法はスコアリング一択ではありません。判定の段階によって、適した手法が変わります。

実務では3つを直列に組むのが安定します。まず属性フィルタでターゲット外を除外し、残りをスコアリングで順位づけし、上位から順にヒアリングで二次判定する、という流れです。属性フィルタを先に置くことで、行動だけが突出したターゲット外リード（競合他社の調査など）が上位に紛れ込む事故を防げます。行動シグナルの読み違いを避ける具体策はホットリードの行動シグナル判定で扱っています。

ヒアリングフレームにはBANTやMEDDICなどの選択肢があります。どれを使うかは商談の複雑さで選ぶのが実務的です。検討関与者が少なく検討期間が短い商材ならBANTの4要素と質問例で足り、関与者が多く決裁プロセスが長いエンタープライズ商材ならMEDDICの6要素やMEDDPICCの8要素が向きます。フレームワーク全体の使い分けは営業フレームワークの選び方にまとめています。本記事ではフレームの中身には立ち入りません。

---

【独自】インサイドセールスと営業の受け渡し合意（SLA）の作り方

判定基準を決めても、引き渡したあとの動きが決まっていなければ成果は出ません。ここで必要になるのがSLA（Service Level Agreement）——部門間で交わす、受け渡しに関する合意です。

SLAは「重要である」と理解した時点では運用できません。実際に必要なのは何を書くかと数値をどう決めるかです。

SLAに書くべき5項目

②の「引き継ぎ情報」で決めるべきは、項目そのものより誰が項目を決めるかです。渡す側が「これも役立つはず」と足していくと項目は増え続け、埋まらない欄だけが残ります。受領側に「これがないと初回接触ができない」項目だけを挙げてもらい、それを必須欄、残りを任意欄にしてください。 項目候補の標準セットはデマンドジェネレーションにおける引き継ぎ情報の標準化にまとめているので、そこから自社に必要なものだけを選ぶのが早道です。必須欄が埋まらないまま引き渡された件数は、④で定義する差し戻し理由コードのうち「情報不足」で計測できます。

各数値を自社の実績から決める手順

SLAでもっとも揉めるのが③の応答期限です。他社の数値を借りたままにすると形骸化するため、最終的には自社の実績から決めます。

【応答期限の決め方】

1. 過去の受注案件と失注案件について、経過時間を2区間に分けて集計する
   区間A: 引き渡し   → 受領判断（受け取る／差し戻す）
   区間B: 受領       → 初回接触
   （区間をまたいだ合計値だけを見ると、待ち時間がどちらで
     発生しているのか切り分けられない）

2. 区間ごとに、受注案件と失注案件で分布に差があるかを見る
   → 差がある場合、受注案件の分布が収まっている範囲が
     その区間にとっての「間に合う時間」
   → 差がない場合、その区間は勝敗を分けていない。期限は
     体制側の実行可能性だけで決めてよい

3. 区間ごとに、2で得た範囲（差がない区間は体制側の実行可能水準）を
   現在の体制で守れる水準に丸めて期限とする
   （守れない期限を置くと、SLAごと無視されるようになる）
   → ここで決めた2つの数値が、そのまま合意書【3. 応答期限】の
     区間A・区間Bの欄に入る

4. 高意向経路（問い合わせ・資料請求）の例外値を決める
   区間A・区間Bを通算した「引き渡しから初回接触まで」で1つの期限を置く
   → この数値が合意書【3. 応答期限】の例外欄に入る

5. 3ヶ月運用し、区間A・区間Bそれぞれの遵守率を測る
   両方とも低い → 期限ではなく体制側に原因がある可能性を疑う
   片方だけ低い → 待ち時間の発生源がその区間にある

自社の実績がまだ取れていない立ち上げ期は、デマンドジェネレーションの対応スピードSLAで紹介している接続点ごとの応答期限を初期値として借り、3ヶ月分の実績が溜まった時点で上記の手順に沿って置き換えてください。他社の数値を初期値として使うこと自体は問題ありませんが、置き換えの期限を決めずに借りたままにすると形骸化します。

合意書ドラフト（そのまま使える雛形）

合意は口頭ではなく文書にします。以下は最小構成の雛形です。5項目の前段に、判定の終点（SQL定義）を転記する欄を置いています。数値は自社の実績で埋めてください。【1.】の条件の項目例が必要な場合は、リードジェネレーションのMQL/SQLの定義テンプレを参照してください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
リード受け渡しに関する合意（SLA）
締結日: ____  次回見直し: ____  当事者: マーケティング / インサイドセールス / 営業
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【前提. 判定の終点（SQL定義）】
Step 1 で導いた条件を転記する。失注分類AのうちSQL条件に関わる改訂は、以降この欄に追記していく
（MQLの属性・行動・除外条件に関わる改訂は【1.】へ、引き継ぎ情報に関わる改訂は【2.】へ）。
  □ SQL条件（受注に多く・失注に少なかった項目）: ____________________
  □ 直近の改訂（追加した条件と追加日）: ____________________

【1. 引き渡しの条件（MQL定義）】
Step 2〜3 で導いた条件をそのまま転記する（ここで新たに考え直さない）。
条件の項目例が必要な場合は /blog/what-is-lead-generation#mqlsqlの定義テンプレ-営業と合意してから運用する（MQL/SQLの定義テンプレ）を参照。
  □ 属性条件（Step 2 で抽出）: ____________________
  □ 行動条件（Step 2 で抽出）: ____________________
  □ 除外条件（Step 2 で抽出 / Step 3 で追加）: ____________________
  □ この定義での月間該当件数（Step 3 の検算値）: ____ 件／月
  □ 引き渡し上限（＝受け入れ可能商談数 ÷ 商談化率）: ____ 件／月
     ← 上の検算値がこれを超えないこと

【2. 引き継ぎ情報（必ず添える）】
  受領側が「これがないと初回接触ができない」と挙げた項目のみを必須欄にする。
  必須: ________________________________________________
  任意: ________________________________________________

【3. 応答期限】
  区間A 受領判断（受け取る／差し戻す）: 引き渡しから ___ 営業日以内
  区間B 初回接触:                           受領から ___ 営業日以内
  例外（問い合わせ・資料請求）: 区間A・区間Bを通算し、引き渡しから ___ 以内
  ※ 未応答・差し戻しの案件は初回接触が発生しないため、区間Bの母数に含めない

【4. 差し戻しのルール】
  差し戻し可能な理由コードと戻し先:
    R1 時期尚早      → 育成へ（___ヶ月後に再判定）
    R2 予算なし      → 育成へ（___ヶ月後に再判定）
    R3 ターゲット外  → 対象外
    R4 情報不足      → マーケへ差し戻し（項目を明記）
    R5 連絡不通      → 育成へ（___回試行後）
    R6 判断保留      → 保留リストへ（___ヶ月後に再判定）
  ※ 理由コードなしの差し戻しは受け付けない

【5. レビュー】
  定例: 四半期に1回 / 参加者: 3部門の責任者
  見る指標: 引き渡し件数・受領率・差し戻し率（理由別）・応答期限の遵守率（区間A・区間B）・
            商談化率・失注理由分布（分類A失注比率）
  臨時レビューのトリガー: ______________________
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

合意会議の回し方

SLAは「作る会議」より「見直す会議」のほうが重要です。初回の合意会議は、完璧な基準を決めようとせず、3ヶ月後に見直す前提で仮の数値を置くことをゴールにしてください。

初回で議論が紛糾しやすいのは①の引き渡し条件です。ここはStep 1〜3 でデータから導いた条件を叩き台として持ち込み、営業の言葉と突き合わせるのが進めやすい順序になります。まず「どんなリードなら喜んで受け取るか」を営業に列挙してもらい、叩き台と食い違った項目だけを議論の対象にしてください。データにも営業の実感にも現れた条件は無条件で採用、片方にしか現れなかった条件だけを検討すれば、論点は自然に絞られます。いきなりマーケが完成した条件を提案すると、営業がそれを否定する構図になり合意しづらくなります。

---

【独自】「商談化したが失注」を減らす逆算の判定基準

判定基準の改善で見落とされがちなのが、商談化した先に何が起きたかです。ここを見ないと、基準は緩む方向にしか動きません。

商談化率だけを追うと基準は緩む方向にしか動かない

判定の良し悪しを商談化率だけで測ると、構造的な問題が起きます。

商談化率は「引き渡したリードのうち、商談になった割合」です。この数字を上げるもっとも簡単な方法は、商談の定義を緩めることです。「一度打ち合わせをしたら商談」と数えれば商談化率は跳ね上がりますが、受注は1件も増えません。

そして重要なのは、判定基準を緩めても商談化率は必ずしも下がらないという点です。緩い基準で渡されたリードでも、インサイドセールスが頑張ってアポイントを取れば商談としてはカウントされます。結果として、「基準を緩めた→商談は増えた→商談化率は維持された→基準は正しかった」という誤った学習が成立してしまいます。

この罠を避けるには、商談化のさらに先、失注のデータまで見て判定を評価する必要があります。

失注理由コードを判定基準に接続できる粒度で設計する

失注理由を記録していても、判定基準の改訂に使える粒度になっていないことがあります。「価格が合わなかった」「タイミングが合わなかった」といった粒度では、判定基準のどこを直せばよいのか分かりません。

判定基準に接続するには、失注理由を**「判定時点で分かったはずか／分かりようがなかったか」**で分類できる形にします。

分類Aに該当する失注が積み上がっているなら、それは判定基準の穴です。分類Aの失注理由の分布こそが、次に追加すべき判定条件を教えてくれます。

失注理由 → 判定基準の改訂 対応表

分類Aの代表的な失注理由と、判定基準への反映の仕方を対応づけると次のようになります。

この対応表を四半期ごとに更新していくと、判定基準は実際に負けた理由に沿って引き締まっていきます。商談化率だけを見ていたときには決して得られない改善方向です。

なお、商談が進んで初めて分かった失注（分類B）が多い場合、直すべきは判定ではなく商談の進め方です。B2B商談の進め方や営業プロセス設計を参照してください。

---

【独自】判定基準の見直しサイクル

判定基準は運用しながら直し続けるものです。しかし「PDCAを回しましょう」では回りません。頻度・トリガー・担当・見る指標を固定して初めて運用に乗ります。

四半期の定例で見る4指標

定例レビューでは、議事の「1. 数字の確認」で読み上げる数字のうち、次の4つを順番に解釈します。順番が重要です。

1と2を先に見るのは、基準の議論に入る前に運用の問題を切り分けるためです。差し戻し率が高くても、原因が引き継ぎ情報の不足（SLAの②）であれば、判定基準をいじっても解決しません。応答期限が守れていないなら、判定の精度を上げても成果には結びつきません。

定例を待たずに見直すトリガー条件

四半期の定例だけでは、悪化に気づくのが遅れます。次の条件に触れたら、定例を待たずに臨時レビューを開きます。

【臨時レビューのトリガー（自社の実績で数値を埋める）】

□ 差し戻し率が ___% を超えた月が2ヶ月続いた
□ 特定の差し戻し理由コードが、差し戻し全体の ___% を超えた
□ 応答期限の遵守率（区間A 受領判断・区間B 初回接触のいずれか）が ___% を下回った
□ 分類A（判定時点で分かったはず）の失注が、四半期の失注の ___% を超えた
□ 引き渡し件数が、引き渡し上限（＝受け入れ可能商談数 ÷ 商談化率）を ___% 超えた
□ ターゲット定義・商材・価格・営業体制のいずれかが変わった

最後の1行は数値ではありませんが、実務ではもっとも見落とされます。商材や価格が変われば、受注する顧客像が変わり、判定基準も変わるはずです。にもかかわらず判定基準だけが旧仕様のまま残っている組織は珍しくありません。

見直し会議の議事フォーマット

会議の形式を固定すると、担当者が替わっても運用が継続します。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
判定基準レビュー  日付: ____  参加: マーケ / インサイドセールス / 営業
（オーナーはSLA⑤で決めたとおり3部門の責任者）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
1. 数字の確認（議論しない。読み上げのみ）
   引き渡し ___件 / 受領 ___件 / 差し戻し ___件（___%）
   応答期限の遵守率 区間A（受領判断）___% / 区間B（初回接触）___%
   商談化 ___件（___%） / 失注 ___件（うち分類A ___件）

2. 差し戻し理由の内訳と、上位2つの原因
   → 原因は「基準」「引き継ぎ情報」「体制」のどれか

3. 応答期限の遵守率（区間A・区間B）
   → 両方とも低い＝体制側の問題。片方だけ低い＝その区間が発生源
   → ここが低いうちは、判定基準の議論に進まない

4. 商談化率と、分類Aの失注理由の内訳
   → 商談化率は単独で読まない。分類Aとセットで判断する
   → 追加すべき判定条件の候補

5. 今期の変更（1つに絞る）
   変更する条件:   ____________________
   変更理由:       ____________________
   効果を測る指標: ____________________
   次回判定日:     ____________________

6. 変更しないと決めたこと（記録しておく）
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

5で変更を1つに絞るのは、複数を同時に変えると効果を切り分けられなくなるためです。6をあえて記録するのは、同じ論点が毎回蒸し返されるのを防ぐためです。

---

【独自】MAツールなしで今日から回す最小構成

リードクオリフィケーションはMA（マーケティングオートメーション）ツールの導入とセットで語られがちですが、判定プロセスの設計は、ツールがなくても始められます。むしろツールを入れる前に基準を固めたほうが、導入後の設定がぶれません。

スプレッドシート＋CRM標準機能の最小構成

必要なのは次の3つだけです。

• ※ 差し戻した場合も受領判断日を入れる。入れないと区間Aの遵守率の分子から落ちる。
• ※ 日付を3列に分けるのは、区間A・区間Bを別々に測るため。

この5列があるだけで、差し戻し率・応答期限の遵守率・商談化率・差し戻し理由の分布という引き渡しから商談化までの数字が取れます。受領件数はステータスがSALまたはSQLの件数、商談化件数はステータスがSQLになった件数を用います（商談の定義を部門間で揃えたうえで数えてください）。なお見直しサイクルの指標4（分類A失注比率）だけは、差し戻し理由ではなく商談後の失注理由が必要なため、この5列では算出できません。商談・受注の記録側に失注理由コードを持たせ、四半期のレビューで突き合わせてください。ツールの有無は、判定プロセスの成否を決める要因ではありません。

MAが必要になる分岐条件

とはいえ、手作業には限界があります。次のいずれかに当てはまったら、ツールの導入を検討する段階です。

• 一次判定の目視作業に週数時間を取られるようになった — 判定漏れや遅延が出はじめ、応答期限の遵守率が落ちる
• Web上の行動を判定条件に使いたくなった — どのページを何回見たかを自動で取得する必要が出てくる
• 差し戻し後の再判定を自動化したい — 「3ヶ月後に再判定」を手動のリマインドで管理しきれなくなる
• 判定と同時に通知・タスク生成を走らせたい — 応答期限の遵守率を仕組みで担保したくなる

重要なのは、この段階に来たときには判定基準がすでに固まっているということです。固まった基準をツールに移植するのは容易ですが、基準がないままツールを入れると、ツールの初期設定が事実上の基準になってしまいます。順序を逆にしないでください。

---

【独自】DSRの資料閲覧シグナルを判定材料に足す

判定の精度を上げるうえで、近年利用できるようになった材料が DSR（デジタルセールスルーム）の資料閲覧データです。

DSRは、提案書・見積書・導入事例といった資料を顧客と共有する専用のスペースです。メールに添付する代わりにDSRで共有すると、誰が・いつ・どの資料を・どのページまで見たかが記録されます。

判定の文脈でこのデータが有用なのは、次の2点です。

1つは、関与者の広がりが見えることです。共有したリンクが社内で転送され、当初の担当者以外が資料を開いていれば、それは検討が個人の情報収集から組織の検討へ移った兆候です。前述のとおり、複数部門・複数名の関与は判定条件として意味を持ちます。誰が見たかが分かるということは、「関与者を把握できているか」という判定条件を、会話に頼らず観測できるということです。

もう1つは、SLAの発火条件に使えることです。「見積書が開かれた」「同一企業の2人目が閲覧した」といったイベントを、初回接触や再接触の起点としてSLAに組み込めます。応答期限を「引き渡しから何営業日」ではなく「シグナル発生から何時間」で定義できるようになると、リードの鮮度を落とさずに動けます。

なお、閲覧データを点数に換算して行動スコアに組み込む方法は本記事の範囲外です。配点の設計はリードスコアリングの配点モデルで扱っています。本記事で扱うのはあくまで合否判定の材料とSLAの発火条件としての使い方です。

閲覧データは強力ですが、万能ではありません。長く見ている＝前向き、とは限らず、稟議のために内容を精査しているだけの場合も、逆に説明が分かりにくくて読み返している場合もあります。判定条件の一つとして加えるものであり、単独で合否を決める材料にはしないでください。

---

失敗パターン — どのステップで壊れるか

リードクオリフィケーションの失敗は、原因不明の不調としてではなく、設計のどのステップが欠けているかとして特定できます。本記事で扱ったステップに紐づけて整理します。

---

KPIと効果測定

リードクオリフィケーションの効果は、単一の指標では測れません。引き渡しの量・受領の質・その先の結果を組み合わせて見ます。

• ※ 受領件数＝ステータスがSALまたはSQLの件数。未応答・差し戻しは含まない。
• ※ 遵守率と商談化率の集計対象は、それぞれ応答期限・商談化の判定猶予がすでに到来した引き渡し分に限る（区間Bは受領日から期限が到来した分で数える）。期限が未到来の引き渡し（四半期末の直近分など）を分母に入れると、この2指標は構造的に下振れする。引き渡し件数・受領率・差し戻し率は早期シグナルとして当月分をそのまま用いる。分類A失注比率は失注コホート基準のため、この注記の対象外。

このうち、単独で目標値を持たせてよいのは応答期限の遵守率だけです。他の指標は互いにトレードオフの関係にあり、片方だけを目標にすると歪みが生じやすくなります。MQL数の目標を置くならば、必ず差し戻し率と分類A失注比率をセットで見てください。

---

よくある質問（FAQ）

---

まとめ

リードクオリフィケーション（リード選別）は、スコアリングの技法ではなく商談化基準の設計です。本記事で扱った要点を整理します。

• 定義は自社の受注実績から逆算する。 受注案件だけでなく同数程度の失注案件（商談化はしたが受注に至らなかったもの）も並べ、「受注に多く・失注に少ない」項目をSQL条件にする。ファネルの下流（SQL）から決め、MQLは検算して運用可能な件数に着地させる
• MQLとSQLのあいだにSALを置く。 受領の責任境界がないと、判定の良し悪しを測る数字（差し戻し率）が取れない
• SLAには5項目を書く。 引き渡しの条件・引き継ぎ情報・応答期限・差し戻しのルール・レビューの場。数値は他社から借りたままにせず、置き換えの期限を決めて自社実績に差し替える
• 商談化率だけで判定を評価しない。 失注理由を「判定時点で分かったはず（分類A）」「商談が進んで初めて分かった」「外部要因」に分け、分類Aから判定条件を補う
• 見直しは頻度・トリガー・担当・指標を固定する。 四半期定例に加え、商材・価格・体制の変更をトリガーに含める
• ツールは基準のあとに入れる。 基準を固める前に導入すると、ツールの初期設定が事実上の基準になる

判定基準は一度作って終わりにするものではありません。業界標準とされるモデル（SiriusDecisions の Demand Waterfall と、それを継いだ Forrester の B2B Revenue Waterfall）ですら、2006年の登場以降、2012年・2017年・2021年と作り直されてきました。自社の判定基準も同じです。完璧な基準を作ろうとするより、仮の基準を置いて、差し戻し率と失注理由から直し続けられる仕組みを先に作るほうが、結果として速く精度が上がります。