リードスコアリングとは？属性×行動の設計、MQL判定、営業引き渡しの実務手順
リードスコアリングを導入しても、営業から「高スコアなのに商談にならない」と言われることがあります。原因は、閲覧やメール反応を一つの合計点へ足し、顧客としての適合度、行動の強さ、営業へ渡す条件を分けていないことです。
結論：リードスコアリングとは、顧客適合度と行動の強さを別軸で評価し、「誰を、なぜ、いつ営業へ渡すか」を決める仕組みです。MQLは合計点だけで決めず、必須の適合条件、行動の閾値、除外条件、高意向行動の例外を組み合わせます。引き渡し後の営業受け入れ率と商談化率まで確認して、配点と閾値を更新するところまでが運用です。
本記事のポイント
- リードスコアリングは、顧客適合度と行動の強さを別軸で評価し、営業接触の優先順位を決める仕組みです。
- MQLは合計点だけで決めず、適合条件・高意向行動・除外条件を組み合わせ、営業と引き渡し基準を合意します。
- 加点上限・減点・時間減衰・差し戻し理由を運用し、営業受け入れ率と商談化率で重みと閾値を更新します。
リードスコアリングは「適合度×行動の強さ」で判断する
リードスコアリングは、見込み客の価値や成約を断定する点数ではありません。限られた営業時間をどこへ使うか、育成を続けるか、対象外として扱うかを一貫して判断するための優先順位です。点数そのものより、判定に使った情報と次のアクションが説明できることが重要です。
評価軸は、顧客適合度（Fit）と行動の強さ（Engagement）に分けます。適合度は「自社が支援したい相手か」、行動の強さは「相手がいま検討しているか」を示します。Adobe Marketo Engageの人物スコアリングモデルの公式ガイドも、行動スコアとデモグラフィックスコアを分け、営業と引き渡し条件を決める手順を示しています。
| 評価軸 | 答える問い | データ例 | 設計上の注意 |
|---|---|---|---|
| 顧客適合度（Fit） | 支援対象として適しているか | 業種、企業規模、地域、部門、役割、対象アカウント | 取得できない属性を想像で補わず、不明として扱う |
| 行動の強さ（Engagement） | いま検討が進んでいるか | 料金・事例の閲覧、資料取得、イベント参加、相談・デモ依頼 | 反復しやすい弱い行動に上限と有効期間を設ける |
| 除外・減点 | 営業へ渡さない理由があるか | 採用目的、競合、対象外地域、配信停止、長期無活動 | 減点と完全除外を混ぜず、理由コードを残す |
| 明示的な高意向行動 | 点数を待たず対応すべきか | 相談、見積、デモ、商談予約 | 通常の閾値を迂回する条件と担当者を決める |
同じ資料を取得した人でも、対象業種の責任者と、学生や競合調査では次の対応が違います。反対に、適合度が高くても、過去に記事を一度読んだだけなら営業連絡より育成が適します。HubSpotのリードスコアリング公式仕様でも、FitとEngagementを個別に保持し、組み合わせた区分で評価できます。
| 顧客適合度 | 行動の強さ | 基本判断 | 次のアクション |
|---|---|---|---|
| 高い | 高い | 営業への優先引き渡し候補 | 判定理由を添えて担当者へ通知する |
| 高い | 低い | 将来性はあるが時期尚早 | 関心テーマ別に育成し、情報を補完する |
| 低い・不明 | 高い | 行動だけでは判断できない | 対象可否と利用目的を確認する |
| 低い | 低い | 低優先または対象外 | 営業通知から除外し、必要なら配信も整理する |
リードスコアリングを5ステップで設計する
ステップ1：営業へ渡す目的と条件を先に決める
最初に決めるのは配点ではなく、何を増やしたいかです。営業が受け入れるリード、初回接触できるリード、SQLへ進むリード、商談になるリードでは、最適な判定条件が異なります。「MQL数を増やす」だけを目標にすると、閾値を下げるほど達成できてしまい、営業負荷と差し戻しが増えます。
マーケティングと営業で、必須条件、除外条件、即時引き渡し条件、通常の閾値を一枚にします。定義がまだ曖昧な場合は、先にMQLとSQLの定義を営業と合意する項目を整理すると、点数表が部門ごとに違う状態を避けられます。
- 必須条件：対象地域、対象事業、連絡可能性など、満たさないとMQLにしない条件
- 除外条件：従業員、競合、採用目的、明確な対象外など、営業通知を止める条件
- 即時条件：相談、見積、デモなど、通常の累積点を待たずに対応する行動
- 通常条件：適合度と行動の両方が一定水準を超えたときに引き渡す条件
ステップ2：使えるデータだけで項目を定義する
点数表へ入れる前に、各項目の取得元、更新責任者、欠損時の扱いを決めます。会社規模を複数のフォーム、名寄せサービス、営業入力から別々に更新すると、同じ企業に異なる点数が付きます。項目ごとに正本を一つ決め、空欄を最低点とみなすのか「判定保留」とするのかを分けます。
行動データは、発生日時、対象コンテンツ、製品・課題テーマ、発生回数を保持します。単に「ページを見た」だけでは、昨日の料金ページ閲覧と半年前の用語記事閲覧を区別できません。Cookie同意、計測制限、別端末の利用で観測できない行動もあるため、スコアを完全な購買意向として扱わないことが必要です。
ステップ3：重み、加点上限、減点をセットで作る
重みは、行動の派手さではなく営業成果との近さで決めます。相談・デモは明示的な意向、料金や導入条件の確認は比較検討、一般記事やメール開封は弱い関心として分けます。同じ人が短時間に何度も発生させられる行動は、回数をそのまま加算せず、期間内の上限を設けます。
次は初期設計の例であり、どの会社にも通用する推奨点ではありません。自社の販売サイクル、営業対応可能数、成約・失注履歴に合わせて変更します。
| 項目例 | 初期の扱い例 | 上限・有効期間 | 理由 |
|---|---|---|---|
| 対象業種・企業規模 | 適合度へ加点 | 属性変更時だけ再評価 | 行動ではなく支援対象との一致を見る |
| 料金・導入条件ページ | 行動へ中程度の加点 | 一定期間に1回まで | 比較検討の可能性はあるが、閲覧だけで確定しない |
| 資料取得・イベント参加 | テーマ別に加点 | 同一施策の反復加点を制限 | 関心テーマは分かるが、購買目的とは限らない |
| 相談・見積・デモ依頼 | 即時引き渡し条件 | 重複通知を抑止 | 累積点より明示的な依頼を優先する |
| 長期無活動 | 行動点を減衰 | 販売サイクルに合わせる | 古い関心で高スコアが残ることを防ぐ |
| 競合・採用目的・対象外 | 減点または除外 | 理由を記録して再判定可能にする | 高い閲覧回数を営業意向と誤認しない |
ステップ4：MQL閾値を過去実績とテストケースで決める
「50点ならMQL」のような普遍的な正解はありません。過去の受注、商談、差し戻しをスコア項目へ当て直し、どの行動と属性が営業受け入れや商談化に結び付いたかを確認します。履歴が少ない場合は、営業が対応できる件数から暫定閾値を置き、一つの販売サイクルを通して検証します。
合計点だけでなく、次のように条件を組み合わせると、低適合・高行動のリードが自動的に営業へ流れる問題を減らせます。
MQL = 必須の適合条件を満たす AND 行動スコアが閾値以上 AND 除外条件なし
別に、相談・デモ依頼などの即時条件を設けます。公開前のテストでは、高適合・低行動、低適合・高行動、長期無活動、同一行動の連続発生、属性欠損、既存顧客、競合などのケースを流し、期待する担当者と状態になるかを確認します。
ステップ5：MAとCRMへ判定理由を実装する
MAには、加点・減点、上限、減衰、閾値到達時の通知を実装します。ただし、合計点だけを営業へ送ると、担当者は再調査から始めることになります。適合度、行動点、直近の高意向行動、関心テーマ、除外確認、判定日時を一緒に渡します。
実装範囲は、マーケティングオートメーションの機能と導入手順で確認できます。ツールを選ぶ前に、スコア項目、通知先、再計算条件、営業が返す結果までデータ項目として決めておくと、製品固有の初期設定に運用を引っ張られにくくなります。
MQL判定から営業引き渡しまでを運用する
MQL判定はゴールではなく、営業が次の行動を取る起点です。引き渡し時刻、担当者、対応期限、受け入れ・差し戻し・保留の状態を決めます。期限は「速いほどよい」と一律にせず、相談やデモのような明示的依頼と、閲覧行動から推定した候補を分けます。
CRMには、合計点だけでなく判定の内訳と営業結果を残します。営業が受け入れなかった理由を「質が悪い」で終わらせず、対象外、時期尚早、情報不足、重複、既存案件、連絡不能などの理由コードにすると、配点とデータ品質のどちらを直すべきか分かります。
| 引き渡し項目 | 営業へ渡す内容 | 運用で残す結果 |
|---|---|---|
| 判定根拠 | 適合度、行動点、直近の高意向行動、関心テーマ | 根拠が妥当だったか |
| 担当・期限 | 担当者、優先度、対応期限、通知時刻 | 初回対応時刻、未対応理由 |
| 営業判断 | 受け入れ、確認待ち、保留、差し戻し、対象外 | 判断理由と次の状態 |
| 次の行動 | 連絡、日程調整、情報補完、育成へ戻す | SQL、商談、失注、再育成への遷移 |
受け入れ条件と差し戻し条件を具体化するときは、MQLからSQLへの営業受け入れ基準を合わせて整理できます。スコア設計と営業引き渡しを別プロジェクトにせず、同じ判定表と理由コードで管理することが重要です。
同じ合計点でも次の対応は変わる
| ケース | 適合度 | 行動の強さ | 判断と次の行動 |
|---|---|---|---|
| A：対象業種の責任者が料金・導入事例を確認 | 高い | 高い | MQL候補。閲覧テーマと判定理由を添えて優先引き渡し |
| B：対象業種だが用語記事を一度閲覧 | 高い | 低い | 営業通知をせず、関心テーマの育成と情報補完 |
| C：対象外属性だが資料を繰り返し取得 | 低い | 高い | 利用目的と所属を確認し、自動引き渡しを保留 |
BtoBでは、同じ会社の複数担当者が別々に接点を持つことがあります。個人スコアを残したうえで、会社単位に製品テーマ、関与人数、直近行動を集約すると、購買グループの動きを捉えやすくなります。AdobeのAccount Score公式資料も、同一アカウントに属する複数人のスコアを会社単位で扱う考え方を示しています。ただし、人数が多い会社ほど点が上がる単純合算にせず、期間とテーマをそろえて評価します。
AIスコアリングはルールを置き換えるのではなく補完する
ルールベースは、どの項目が何点かを説明しやすく、履歴が少ない段階でも始められます。一方で、項目間の組み合わせや変化を人手で調整し続ける負荷があります。AIスコアリングは、過去の成約・失注やステージ遷移から共通パターンを探せますが、正しい成果ラベルと十分な履歴がなければ、過去の入力漏れや古い営業方針まで学習します。
SalesforceのEinstein Lead Scoring公式資料では、過去に変換したリードとの類似性から優先度を予測し、スコアへ正または負に影響した主要項目を営業画面に表示します。AIを使う場合も、スコアだけでなく影響要因を営業が確認できることが重要です。
| 方式 | 向く状態 | 主な利点 | 注意点 |
|---|---|---|---|
| ルールベース | 履歴が少ない、条件を明示したい | 説明・修正・監査がしやすい | 複雑化と属人的な重み付けを避ける |
| AI | 成果ラベルと十分な履歴がある | 多変量の組み合わせを探索できる | データ漏れ、過去方針の偏り、モデル変化を監視する |
| ハイブリッド | 事業上の必須・除外条件がある | ルールで境界を守り、AIで優先順位を補う | 最終条件と責任者を曖昧にしない |
AI導入前には、①何を正解とするか、②学習に使える期間、③判定前には存在しなかった項目が混ざっていないか、④セグメントごとの件数、⑤営業が確認できる影響要因、⑥誤判定時の停止・切り戻しを確認します。必要なデータ件数は製品ごとに異なるため、一律の業界基準として扱わず、利用製品の最新要件を確認してください。
加点上限・減衰・営業結果で運用を見直す
スコアは一度作って終わりではありません。古い行動が残り続ける、同じ行動を繰り返すだけで閾値を超える、営業が差し戻しても高スコアのまま再通知される、といった状態を防ぐ必要があります。
HubSpotの公式仕様は、イベントごとの加点・減点、グループ上限、期間、スコア減衰を設定できることを示しています。Adobeの公式ガイドも、無活動への減点と継続的な閾値調整を扱っています。減衰期間や減点幅は固定値を流用せず、自社の販売サイクルと再検討までの期間から決めます。
| 見る指標 | 分かること | 悪化したときの確認先 |
|---|---|---|
| スコア対象率・属性欠損率 | そもそも判定できるデータがあるか | フォーム、名寄せ、CRM入力、連携エラー |
| スコア帯別の人数分布 | 特定帯への偏りや閾値の形骸化 | 上限、重複加点、減衰、項目の相関 |
| 営業受け入れ率 | MQLが営業条件と合っているか | 適合条件、除外条件、差し戻し理由 |
| 期限内の初回対応率 | 引き渡し後に放置されていないか | 担当割当、通知、優先度、営業キャパシティ |
| SQL化率・商談化率 | 高スコアが事業成果へ進んだか | 閾値、重み、成果ラベル、チャネル別の差 |
| 差し戻し・再育成理由 | モデルと運用のどちらがずれたか | 理由コード、情報不足、接触時期、データ品質 |
立ち上げ期は月次を目安に、スコア分布、営業受け入れ、SQL化、商談化、差し戻し理由を同じ期間で見ます。配点を変えるときは、一度に複数項目を動かさず、変更日、対象、理由、期待する変化を残します。過去分を再計算するか、新規行動から適用するかも事前に決めます。
- 適合度と行動の内訳を別々に確認できる
- 弱い反復行動に加点上限がある
- 古い行動に減衰または失効条件がある
- 除外、失格、再育成、リセットの条件がある
- 営業の受け入れ・差し戻し理由を記録できる
- スコア帯別のSQL化率と商談化率を比較できる
よくある質問
MQLの閾値は何点に設定すべきですか？
すべての会社に共通する正解はありません。過去の受注・商談・差し戻しを候補項目へ当て直し、営業が対応できる件数も踏まえて暫定値を置きます。合計点だけでなく、必須の適合条件、行動の閾値、除外条件、高意向行動の例外を組み合わせてください。
メール開封やページ閲覧は何点にすべきですか？
単独では弱いシグナルとして扱います。計測精度や閲覧目的が一定せず、短時間に反復しやすいためです。料金・導入条件の閲覧、相談、デモ依頼など、購買判断に近い行動との差を付け、同一行動には期間内の加点上限を設けます。
複数担当者の行動は会社単位でまとめるべきですか？
BtoBでは会社単位の集約が役立ちますが、個人の役割と行動明細も残します。関与人数だけを単純合算せず、同じ製品・課題テーマへの行動か、直近の一定期間に起きたかをそろえて評価します。
データが少なくてもAIスコアリングを導入できますか？
最初は説明できるルールベースで必須条件、除外条件、成果ラベルを整える方が安全です。AIに必要な件数や期間は製品ごとに異なり、履歴が少ないと安定した比較ができません。AIを使う場合も、影響要因を確認し、事業上の境界条件はルールとして残します。
関連ページと関連記事
MQL判定と営業引き渡しを整理する
点数表だけでなく、適合条件、行動の閾値、除外、営業への通知、差し戻し理由まで一つの運用にすると、営業が使える優先順位になります。現状のデータと営業プロセスを確認し、どこから整えるべきかを具体化できます。
