lead-scoring

リードスコアリング

リードが収益につながる可能性に基づいて順位付けするモデルを設計、検証、維持します。実務の標準では、スコアリングを次の2つの軸に分けます。

• 適合度（購入できるか）：企業属性、人口統計属性、技術属性。
• エンゲージメント（購入が近いか）：行動、製品内の行動。

この2軸モデルには、MarketoのA-D x 1-4のグレードとスコアのグリッド、MadKuduのCustomer Fit x Likelihood to Buy、PLGにおけるOpenViewのプロダクト適格リード（PQL）など、いくつかの呼び名があります。

スコアリングの失敗は、計算式の問題よりも、営業チームの承認がない、再調整が行われない、MQL数が目標として扱われるといった組織的な放置が原因であることがはるかに多いため、検証とガバナンスも後付けではなく、ここで設計に含めます。完成したスコアは割り当ての入力情報です。ルーティング、テリトリー、担当者とのマッチングについては、mbfinotti/revops-skills@lead-routing を参照してください。このスキルの適合度軸で重み付けするアカウント適合基準（企業属性および技術属性に基づくICPティア）の定義については、mbfinotti/sales-skills@sales-icp-definition を参照してください。このスキルでは、その定義に行動エンゲージメントを加え、機能するスコアに落とし込みます。

獲得・スコアリング・ルーティング・ナーチャリングの仕組みは、B2BとB2C/PLGで構造的に同じです。B2C/PLGとB2Bで実際に異なる点は次のとおりです。

• 主なシグナル源はフォームやコンテンツではなく、製品内の行動です。
• 購買委員会が存在せず、1人のユーザーの行動だけで適格と判断できる場合があります。
• 購買サイクルは四半期単位ではなく、日単位で進みます。

こうした違いにより、B2C/PLGでは減衰、しきい値、再スコアリングの頻度、再調整のすべてをより速いペースで行います。

インタビュー

設計を始める前に質問してください。1回のメッセージにつき質問は1つにし、できるだけ選択肢を提示してください。ユーザーがすでに回答している質問は省略してください。

• どの販売形態ですか？ (a) 営業主導のB2B、(b) PLG／セルフサービスに営業支援を組み合わせる形、(c) B2Cのトランザクション型。
• 毎月およそ何件の新規リードがあり、過去12～24か月で受注と失注の結果がそれぞれ何件ありますか？（ルールベースにするか予測型にするか、どの程度バックテストが可能かを判断します。）
• リード作成時、リードレコードには実際に何が記録されていますか？適合性を示す各フィールドのエンリッチメントカバー率、フォームのフィールド、製品イベントなどです。（スコアはデータ品質に左右されます。）
• すでにモデルはありますか？ある場合、再設計しますか、それともまず診断しますか？（診断の手順については「壊れたモデルの診断」を参照してください。）
• 営業チームは実際に週何件のリードに対応できますか？（現実的な閾値の制約です。）
• 誰が承認しますか？どの営業責任者が承認し、モデルに対してどの最低受入率を求めますか？
• EUまたは同意に関する制約はありますか？行動スコアリングはGDPR上のプロファイリングにあたるため、適法な根拠を文書化する必要があります。
• モデルの本番スコアリング開始日はいつで、それを待っているものは何ですか？（2週間以内の日付では、エンリッチメントの調達もコンバージョン帯域の閾値方式も選択肢から外れます。四半期分の準備期間があれば、どちらも実施可能です。）
• 1回限りの成果ですか、それとも継続的に価値が積み上がる資産ですか？（1回のキャンペーンリスト作成が目的なら、v1の重み付けと対応可能件数の閾値で十分です。継続的な取り組みであれば、エンリッチメント、完全なバックテスト、そしてモデルの本番稼働後も妥当性を保つ再調整の頻度が必要です。）
• 工数の上限はどの程度ですか？アナリストの作業時間、CRM／マーケティングオートメーションの管理者アクセス、データ契約に必要な調達・法務の手順、営業チームの時間をどの程度使えるかを教えてください。（アナリストがいなければ、受注／失注データから重みを再導出する方法とコンバージョン帯域方式は選択肢から外れます。調達の手順がなければ、エンリッチメントの段階は最後の候補にするのではなく、完全に除外します。）

これら最後の3つの回答を、このスキルとその参照資料でのすべての順位付けに反映してください。このユーザー向けの既定の順位を入れ替えるのは、この3つの入力だけです。ここでの順位はすべて既定のものであり、絶対的なルールではありません。状況や実行する人によって変わります。段階を推奨する前に、たとえば次のように順位を見直してください。

• すでにエンリッチメント契約がある場合、その段階の工数はフィールドマッピングだけになり、最上位に繰り上がります。
• CRMの適合性フィールドがフォームで高いカバー率で自己申告入力される場合、カバー率に応じた選択肢はすべて不要になります。
• アナリストがいない場合、CRM管理者だけで実施できる段階はすべて繰り上げ、コホート分析が必要な段階はすべて繰り下げます。

ワークフロー

1. インタビューを実施し、設計を始める前にすべての回答を集めます。

2. まずデータを監査します。過去90日分のリードについて、適合性を示す各フィールドのエンリッチメントカバー率を測定してください。フィールドのカバー率が約70％を下回ると、データベースの大半が閾値に達しない可能性があります。これはエンリッチメント上限の問題です。解決策は3つあり、工数あたりの価値が高い順に並べると、工数はアナリストの作業時間、管理作業、調達、元に戻しやすさを指します。

   • 効率性：不明値を0としてスコアリングする > フィールドをエンリッチメントする > フィールドを削除する
   • 価値（モデルが実際に活用できる適合性シグナル）：フィールドをエンリッチメントする > 不明値を0としてスコアリングする > フィールドを削除する
   • 工数：フィールドをエンリッチメントする > フィールドを削除する > 不明値を0としてスコアリングする
   • コンプライアンスコスト：フィールドをエンリッチメントする > 不明値を0としてスコアリングする == フィールドを削除する

   工数の規模：

   • 不明値を0としてスコアリングする：ほぼゼロです。スコアリング設定を変更するだけで、クリック1つで元に戻せます。
   • フィールドを削除する：1時間かかり、この選択肢の中で最も元に戻しにくい方法です。シグナルの収集が停止し、履歴を再構築しないかぎり、次回の再調整でその重みを再導出できなくなります。
   • エンリッチメント：1件目のリードをスコアリングする前に調達と契約の手続きが必要です。その後も、レコードごとの依存関係が継続し、カバー率を恒久的に監視する必要があります。 デフォルトでは不明な項目に0点を付けます。すべての情報が薄いレコードをエンゲージメントで採点可能にし、今週中にリリースできるためです。コンプライアンス上の関係を明確に説明してください。0点ルールも削除も、新たなデータソースを導入しないため、いずれも同意や出所のレビューを必要としません。一方、エンリッチメントは異なります。サードパーティの適合性データはGDPR上のプロファイリング入力であり、誰かを採点する前に、適法な根拠と出所を文書化する必要があります。

   このデフォルトがもたらすバイアスを明示してください。不明な項目に0点を付けると、適合性以外の理由で情報が薄いレコード（中小企業、米国外、プライバシーを重視する買い手）が低く評価されます。そのため、別コホートとしてコンバージョンを追跡し、それでもコンバージョンした場合は重みを再算出します。この順序で後回しにされるのはエンリッチメントです。価値の面でも工数の面でも優先順位が最も低いため、比率がどれほど有利でも採用されず、しかも、迂回するのではなくシグナルを回復させる唯一の段階です。

   次の場合はエンリッチメントを優先してください。

   • そのフィールド自体がICPの判定条件である場合（エンタープライズのACVにおける従業員数など）。
   • 1つのセグメントに限らず、データベース全体でカバレッジが低い場合。
   • すでに契約がある場合。

   Interviewで調達経路が示されていない場合は、エンリッチメントの段階を完全に削除し、削除したことを明記してください。リストの最下位に置いただけの段階は、誰も承認していないベンダーとの電話が四半期に何度も発生する事態を招きます。

3. 直感ではなく、成果からシグナルを導き出します。

   • 直近12〜24か月の受注・失注レコードを抽出します。
   • 2つのグループ間でシグナルの頻度を比較します。
   • ベースラインに対して実際のコンバージョン差があるシグナルを採用します。

   直感によるリストと、証拠に基づくリストは、通常異なります。注意点：受注案件では、営業がクロージング直前に入力したためにフィールドが埋まっているように見えることがあります。各シグナルが採点時点ですでに存在していたことを確認してください。

4. references/signal-taxonomy.mdを基にシグナルカタログを作成します。適合性とエンゲージメントは別々のスコアとし、ハードディスクオリファイアは除外条件（マイナス点にはしません）、ソフトな評価引き下げはマイナス点、減衰はエンゲージメントのみに適用します。

5. references/weighting-and-thresholds.mdに従って重みを設定します。営業主導型では適合性60／エンゲージメント40前後、ハイブリッド型では50／50、行動が主な指標となるPLGやB2Cでは適合性30〜40／エンゲージメント60〜70から始めます。どの単一カテゴリも、それだけでしきい値を超えられないよう、各シグナルカテゴリに上限を設けます。

6. しきい値は、まず営業キャパシティ、次にコンバージョン帯、最後に妥当性確認としてパーセンタイルを基準に設定します。これは単なる手順ではなく、3つの方法の効率性の順位です。同じリファレンスには、各方法の価値と工数が記載されているため、それを踏まえて選択します。各ティアを、それぞれ異なる施策に対応づけます。

7. references/validation-and-kpis.mdに従ってバックテストを行います。履歴を遡って採点し、スコア帯ごとのコンバージョンを算出し、最上位帯の未採点ベースラインに対するリフトを算出し、スポットチェック用のホールドアウトセットを実行します。以下の合格基準を満たすまで、シグナル、重み、しきい値を調整します。

8. シグナルリスト、しきい値、受け入れ基準について、営業の書面による承認を得ます。現場で最もよく挙げられる失敗は、承認なしにモデルを構築することです。マーケティングだけで構築し、営業がリードの半分を拒否し、双方が相手を非難します。

9. 仕様を出力し（次のセクションを参照）、段階的に展開します。バックログを一括採点する前に、まず稼働中のフローを採点し、リリースから60日後のv2レビューをリリース前に予定します。

10. ハーネスに永続メモリーがある場合は、承認済みの仕様（シグナル、重み、しきい値、バージョン、レビュー日）を記憶させ、後続の再調整や診断の実行時に、再度ヒアリングするのではなく、その内容を起点にします。

スコアリングモデルの仕様

すべてのエンゲージメントで、この成果物を納品します。マーケティングオペレーションや営業がそのまま活用できるドキュメントです。より詳細な作業版はreferences/examples.mdにあります。

SCORING MODEL SPEC - <company/product>, <date>, v<n>
Motion       : sales-led | PLG | B2C - fit/engagement weight split, scale (e.g. 100-pt)
Fit signals  : attribute -> points | data source | coverage % | evidence (won-vs-lost delta)
Engagement   : signal -> points | decay rule | per-category cap | evidence
Exclusions   : hard disqualifiers, excluded outright (competitors, students, customers...)
Negative pts : soft demotions -> points
Threshold    : MQL/PQL score + the capacity math behind it
Tiers        : band -> play (T1 fast human follow-up, T2 queue, T3 nurture...)
Backtest     : period, conversion by band, top-band lift vs baseline, false-negative %
Guardrails   : sales acceptance floor, score-distribution inflation alarm
Governance   : owner, sales sign-off (name, date), v2 review date, change-log location

仕様そのものに関する3つのルール：

• すべての点数に根拠を添えます。「料金ページを2回以上閲覧 +20：前年度の受注分析で、ベースラインの2.8倍のコンバージョン率を記録」は検証できますが、根拠のない数字は、いずれ悪用される迷信にすぎません。
• 仕様には合格基準を設けます。バックテストでは、上位スコア帯の商談化率が、スコアリングなしの全リードのベースラインの少なくとも2倍である必要があります（公開されているガイダンスが求めるのは「スコアリングなしを上回ること」だけですが、わずかな差は実運用のノイズに耐えられないため、2倍をこのスキルにおける実用上の最低ラインとします）。バックテストの偽陽性率も、合意した**営業受け入れ率の最低ライン（一般的な実務目標は60％ですが、これは慣例であり、調査に基づく定数ではありません）**を達成できる見込みがある水準でなければなりません。両方をクリアするまで反復し、スコアリングなしのベースラインを上回らないモデルは納品しないでください。
• **モデルにはバージョンを付けます。**v1は出発点です。v1のリリース前にv2のレビューを予定し、変更はすべて記録して営業に周知します。説明できないスコアは、誤ったスコアよりも早く営業担当者の利用を損ないます。

モデルの問題を診断する

ユーザーが稼働中のモデルを持ち込んだら（「スコアがおかしい」「営業がスコアを無視している」など）、再構築を提案する前に、以下の症状をすべて確認してください。確認は簡単で、問題のある設定のほとんどには1つではなく2〜3つの症状があります。どこから修正するかが判断の分かれ目です。各項目は、作業量あたりの価値が高い順に並べているため、上から順に対応してください。

• 効率：見栄えだけのシグナルをゼロにする > 適切な数値を報告する > 減衰を加える > カバレッジのギャップを修正する > 不足している購買経路を加える > 過大な重みを再導出する > 全面的に再調整する
• 価値（修正後のモデルで獲得できる、または失わずに済む商談）：全面的な再調整 > 不足している購買経路を加える > 過大な重みを再導出する > 減衰を加える > 見栄えだけのシグナルをゼロにする > カバレッジのギャップを修正する > 適切な数値を報告する
• 作業量：全面的な再調整 > 過大な重みを再導出する > 不足している購買経路を加える > カバレッジのギャップを修正する > 減衰を加える > 適切な数値を報告する > 見栄えだけのシグナルをゼロにする | 症状 | 考えられる原因 | 対処 | 作業量 | | ---------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------- | | ニュースレターの熱心な読者が、実際の購入者より高く評価される | 虚栄のシグナルにポイントが付与されています（受信トレイのプライバシー機能により、メールの開封は構造的に信頼性が低いためです） | 購買意欲の低いシグナルのポイントをゼロにするか、最低値に抑えます。メールカテゴリに上限を設けます | ほぼゼロです。ポイント値はすでにマトリックスにあり、モデルのオーナーだけで編集できます | | パイプラインが停滞しているのに、MQL 数を祝う | グッドハートの法則が働いています。MQL 数が目標になったため、基準が徐々に下がっています | MQL 数そのものではなく、MQL から商談への転換率とパイプラインへの貢献を上位層に報告します | 数時間で済み、作業量はほぼゼロですが、MQL 目標を設定した人との政治的な駆け引きが必要です | | 古いコンタクトが、活動中のコンタクトと同じくらい有望に見える | 減衰がありません。ポイントが永久に蓄積します | エンゲージメントのみに減衰を追加します（仕組みの優先順位は signal-taxonomy を参照してください） | 設定に 1 時間かかり、データベースの再スコアリングが 1 回必要です | | データベースの大半がしきい値に到達できない | エンリッチメントの上限です。大半のレコードで適合性フィールドが空欄です | カバレッジを測定してから、Workflow のステップ 2 にある優先順位付きメニューを適用します。まず不明な値を 0 点にします | デフォルトの段階ならほぼゼロです。エンリッチメントを推進する場合は、四半期分の作業と継続的なジョブが必要です | | MQL にならなかった受注案件 | 偽陰性です。モデルが実際の購買経路（紹介、イベント、製品利用）を無視しています | 欠けている経路を追加し、偽陰性率を継続的な KPI として追跡します | 1～2 日です。受注レコードから経路を特定し、シグナルを追加して、バックテストをやり直します | | MQL 数は増えたが、MQL から商談への転換率が下がった | スコアのインフレです。重み付けが甘いか、虚栄のシグナルが含まれています | 受注／失注データから重みを再導出し、カテゴリ別の上限を追加して、しきい値を引き上げます | 受注／失注のコホートを分析するアナリストの作業が 1～2 日と、営業による再承認が必要です | | 高スコアが受注を予測しなくなった | モデルが古くなっています。キャリブレーション以降に ICP、製品、またはコンテンツが変化しています | 直近の複数四半期のコホートで再キャリブレーションし、ドリフトのトリガーを設定します | 再構築に数週間かかり、その後も継続的なジョブが必要です |

この順序では何が後回しになるか：全面的な再キャリブレーションです。価値と作業量を最優先するため、比率だけでは再キャリブレーションが予定に組み込まれません。前回のキャリブレーション以降に ICP、価格設定、または製品が変化した場合、あるいは上の 2 項目をすでに修正しても転換率がスコアに追随しない場合は、ほかのすべてより優先してください。

Interview でアナリストがいない場合は、コホート分析を必要とする 2 つの段階、すなわち重みの再導出と全面的な再キャリブレーションを削除し、誰も実行できない計画の最後に残すのではなく、削除したことを明記してください。インフレへの対策として残るのは、カテゴリ別の上限としきい値の引き上げです。CRM 管理者だけで実施でき、精度の大部分を取り戻せます。