sales-lead-score

リードスコアリングモデルを設計する

ユーザーがリードスコアリングモデルを設計し、重み付けして調整できるよう支援します。スコアリングの軸の定義やポイント値の割り当てから、MQL／SQL のしきい値の設定、使用ツールへの実装までを扱います。このスキルは特定のツールに依存せず、あらゆる CRM（Salesforce、HubSpot）、MAP（Marketo、Pardot）、エンリッチメントプロバイダー（Apollo、ZoomInfo、Clearbit）に適用できます。

ステップ 1 — 背景情報を収集する

references/learnings.md が存在する場合は、蓄積された知識を確認するため、最初に読みます。

ユーザーに以下を質問します。

1. 何を販売していますか？

   • 製品／サービスのカテゴリ
   • おおよその ACV（スコアリングの複雑さに影響します。ACV が 5,000 ドルの場合、ACV が 10 万ドルの場合よりシンプルなスコアリングが必要です）

2. どのような営業モデルですか？

   • A）インバウンド主導 — ほとんどのリードがマーケティング（コンテンツ、広告、イベント）経由で獲得される
   • B）アウトバウンド主導 — ほとんどのリードを SDR／BDR が開拓する
   • C）プロダクト主導型成長（PLG）— ユーザーが登録してセルフサービスで利用し、利用状況がしきい値に達すると営業が対応する
   • D）ハイブリッド — インバウンド、アウトバウンド、PLG を組み合わせる
   • E）チャネル／パートナー — パートナー経由でリードを獲得する

3. どのツールを使っていますか？

   • CRM：Salesforce、HubSpot、Pipedrive、その他
   • MAP：Marketo、HubSpot、Pardot、ActiveCampaign、その他
   • エンリッチメント：Apollo、ZoomInfo、Clearbit、その他
   • プロダクト分析（PLG の場合）：Amplitude、Mixpanel、Heap、Segment、その他

4. 現在のスコアリングの状況はどうですか？

   • A）一から開始 — スコアリングモデルがまだない
   • B）モデルはあるが機能していない（症状を説明してください）
   • C）基本的なモデルがあり、改善したい
   • D）ICP の変更または新製品のローンチを受けて再構築する

5. 現在のファネルはどのようになっていますか？

   • 月間のリード数（概算）
   • 現在の MQL → SQL 転換率（わかる場合）
   • 現在の SQL → 受注転換率（わかる場合）

ユーザーの依頼ですでに背景情報の大半が示されている場合は、該当するステップに進んでください。 妥当な前提を明示したうえで、最善を尽くした回答をまず提示し、最後に最も重要な確認事項を 1〜2 件だけ質問します。必要な情報がすべて集まるまで回答を保留しないでください。

ステップ 2 — スコアリングの軸を定義する

4 つの軸でスコアリングモデルを構築します。デフォルトの重み付けは出発点とし、営業モデルに合わせて調整してください。

軸 1：属性の適合度（デフォルト 25％）

個人が自社のバイヤーペルソナにどの程度合致するかをスコア化します。

属性	高スコア	中スコア	低スコア／マイナススコア
役職	ICP の役職と完全に一致（例：VP of Engineering）	隣接する役職（Director of Engineering、Head of Platform）	関連のない役職（Engineering 向けに販売する場合の HR Manager）
役職レベル	製品の意思決定者レベル	影響を与える立場	購入や影響を与えるには役職が低すぎる
部門	主な購買部門	隣接する部門	関連のない部門
職務機能	解決する課題に直接合致	関連する職務機能	関連性なし

ポイント値の例（最大 25 ポイント）：

• 役職が完全一致：10 ポイント | 隣接：5 ポイント | 一致なし：0 ポイント
• 役職レベルが一致：8 ポイント | 隣接：4 ポイント | 役職が低すぎる：0 ポイント
• 部門が一致：7 ポイント | 隣接：3 ポイント | 関連なし：0 ポイント

ディメンション 2：企業属性の適合度（デフォルト 25%）

企業が ICP にどの程度適合するかをスコアリングします。

属性	高スコア	中スコア	低／マイナススコア
企業規模	最適な範囲（例：従業員 100～500 人）	隣接する範囲（50～100 人、または 500～1,000 人）	範囲から大きく外れている
業界	主なターゲット業界	隣接する業界	対象としていない業界
収益	価格設定に合った収益範囲	隣接する範囲	製品を購入できない
地域	主な市場	サービス提供可能な市場	サポート対象外の地域
技術スタック	補完的な技術を使用している	中立的な技術スタック	競合製品を使用している（乗り換えを促せる場合はプラスになる可能性があります）

ポイントの例（最大 25 ポイント）：

• 企業規模が最適な範囲：8 ポイント | 隣接：4 ポイント | 範囲外：0 ポイント
• 業界が一致：7 ポイント | 隣接：3 ポイント | 一致なし：0 ポイント
• 収益が適合：5 ポイント | 隣接：2 ポイント | 範囲外：0 ポイント
• 地域：3 ポイント | サービス提供可能：1 ポイント | サポート対象外：0 ポイント
• 技術スタックが適合：2 ポイント

ディメンション 3：行動シグナル（デフォルト 30%）

見込み客の行動をスコアリングします。ほとんどのチームにとって、最も予測力の高いディメンションです。

シグナル	ポイント	減衰
デモ／トライアルの申し込み	15 ポイント	なし — これは明確なコンバージョンイベントです
価格ページの閲覧	10 ポイント	14 日後に 5 まで減衰
複数回のウェブサイト訪問（7 日間で 3 回以上）	8 ポイント	14 日後に 4 まで減衰
コンテンツのダウンロード（電子書籍、ホワイトペーパー）	5 ポイント	30 日後に 2 まで減衰
メールへの反応（開封＋クリック）	反応ごとに 3 ポイント	30 日後に 0 まで減衰
ウェビナー／イベントへの参加	8 ポイント	30 日後に 4 まで減衰
インテントデータ — 自社のカテゴリを調査中	10 ポイント	14 日後に 5 まで減衰（インテントは変化しやすいため）
G2／レビューサイトでの比較ページ閲覧	8 ポイント	14 日後に 4 まで減衰

PLG／プロダクト主導型の取り組みでは、製品利用のシグナルを追加します。

シグナル	ポイント	減衰
無料プラン／トライアルに登録	10 ポイント	なし
オンボーディングを完了	8 ポイント	なし
利用のしきい値に到達（例：API 呼び出し 100 回、チームメンバー 5 人）	15 ポイント	なし
チームメンバーを招待	10 ポイント	なし
プレミアム機能を利用（ペイウォールに到達）	12 ポイント	30 日後に 6 まで減衰
毎日のアクティブ利用（直近 14 日間で 5 日以上）	10 ポイント	ローリング方式 — 毎週再計算

ディメンション 4：タイミングシグナル（デフォルト 20%）

新しさと緊急性のシグナルをスコアリングします。

シグナル	ポイント	減衰
新たに役職に就いた（90 日未満）	10 ポイント	90 日後に 5、180 日後に 0 まで減衰
最近の資金調達	8 ポイント	90 日後に 4 まで減衰
製品で支援できる職種の採用	6 ポイント	30 日後に 3 まで減衰（求人情報には期限があります）
企業の成長（6 か月間で従業員数が 20% 以上増加）	5 ポイント	90 日後に 2 まで減衰
競合他社との契約更新時期	10 ポイント	更新時期を過ぎると 0 まで減衰

営業の取り組みに応じた重みの調整

取り組み	人口統計	企業属性	行動	タイミング
インバウンド主導	20%	20%	40%	20%
アウトバウンド主導	25%	30%	20%	25%
PLG	15%	15%	50%	20%
エンタープライズ／ABM	25%	25%	25%	25%

ステップ 3 — しきい値とステージを設定する

MQL／SQL のしきい値調整

まずは次のデフォルト値を使用し、コンバージョンデータに基づいて調整します。

しきい値	デフォルト	発生するアクション
MQL（マーケティング適格リード）	スコア上位 20% のリード	マーケティングのナーチャリングを強化し、SDR に通知
SQL（営業適格リード）	スコア上位 5% のリード	SDR によるアプローチ、AE への引き継ぎ、または営業フォローアップ
PQL（プロダクト適格リード、PLG のみ）	利用のしきい値＋企業属性の適合度	アクティブな無料ユーザーへの営業アプローチ

初期のしきい値の設定方法：

1. 直近の受注済み案件 100 件を遡ってスコアリングします
2. スコアの中央値を調べます — これがおおよその SQL しきい値です
3. MQL は SQL しきい値の 60～70% に設定します
4. 実データを 30 日間取得した後に調整します

スコア減衰ルール

行動シグナルは時間の経過とともに関連性が低下します。スコアの過剰な増加を防ぐため、減衰を実装してください。

• 速い減衰（7～14日）：インテントデータ、料金ページの訪問、比較検討
• 中程度の減衰（30日）：コンテンツのダウンロード、メールへの反応、ウェビナーへの参加
• 遅い減衰（90日）：転職、資金調達イベント、採用シグナル
• 減衰なし：デモのリクエスト、トライアルへの登録、企業属性／人口統計上の適合性

マイナススコア

不適格となるシグナルにはポイントを差し引きます。

シグナル	ポイント
メールの配信を停止	-20 pts
競合他社の従業員	-50 pts（または自動的に不適格と判定）
学生／教育機関のメール（.edu）	-30 pts
B2B 製品に対する個人用メール（gmail、yahoo）	-10 pts
職種に「intern」または「student」が含まれる	-20 pts
会社規模が最小要件を大きく下回る	-15 pts
メールがバウンス	-10 pts
「連絡禁止」とマークされている	自動的に不適格と判定

ステップ 4 — 実装ガイド

HubSpot

1. Properties > Create a custom "Lead Score" number property
2. Workflows > トリガーに基づいてポイントを加算／減算するスコアリングワークフローを作成
3. 行動スコアリングでは、「Contact activity」トリガー（ページビュー、フォーム入力、メールのクリック）を使用
4. 減衰には、X 日後にスコアを減らす時間ベースのワークフローを作成
5. スコアがしきい値を超えたときに、ライフサイクルステージを MQL に変更するよう設定

Salesforce

1. Setup > Lead Scoring（Einstein Lead Scoring を使用する場合）、またはカスタムフィールドと Process Builder／Flow
2. Lead オブジェクトと Contact オブジェクトに「Lead Score」の数値フィールドを作成
3. Flow Builder を使用して、フィールドの変更やアクティビティに応じてスコアを増減
4. 行動スコアリングでは、エンゲージメントを追跡する MAP（Marketo、Pardot）と連携
5. SQL を適切な担当者に割り当てる割り当てルールを作成

Marketo

1. Admin > Scoring > New Scoring Model
2. 人口統計スコア（人物属性）と行動スコア（アクティビティ）を個別に定義
3. 各トリガーに応じてポイントを加算／減算するスマートキャンペーンを設定
4. スケジュールされたバッチキャンペーンでスコア減衰を設定
5. ルーティングと可視化のため、スコアを Salesforce に同期

Apollo

1. 基本的な ICP 適合性スコアリングには、Apollo の組み込みリードスコアリング（Settings > Scoring）を使用
2. 行動スコアリングは MAP で補完します。Apollo のネイティブスコアリングは主に人口統計／企業属性に基づきます
3. Apollo のインテントデータを、MAP での行動スコアリングの入力として使用
4. スコアリング済みのリードを CRM にエクスポートしてルーティング

プラットフォーム別のスコアリング設定（GetResponse、Kit、Clearbit、Clay、RB2B、6sense、ActiveCampaign、Swan、SweepLift）については、references/platforms.md を参照してください。

モデルのテスト

運用を開始する前に、以下を実施してください。

1. バックテスト：過去 6 か月分のリードを遡ってスコアリングします。受注案件は失注案件より高いスコアになっていますか？
2. しきい値の確認：提案する MQL しきい値では、リードの何％が適格になりますか？（目標：15～25％）
3. 誤検出の確認：MQL しきい値を超えたリードを 20 件抽出します。担当者は実際にそのリードへ電話したいと思うでしょうか？
4. 見逃しの確認：受注案件を 20 件抽出します。受注前に MQL しきい値を超えていましたか？

ステップ 5 — 調整とメンテナンス

月次レビューの頻度

毎月、以下を確認してください。

1. スコア帯別のコンバージョン率：高スコアのリードは、実際に高いコンバージョン率を示していますか？
2. MQL → SQL のコンバージョン率：30％を下回る場合、MQL しきい値が低すぎます（質の低い MQL が多すぎます）
3. SQL → 商談の発生率：50％を下回る場合、SQL しきい値が低すぎます
4. スコアの分布：分布は健全ですか、それともほとんどのリードが単一のスコアに集中していますか？
5. 営業チームからのフィードバック：担当者は MQL を無視していますか？その場合、モデルが質の高いリードを抽出できていません。

重みの調整方法

1. 過去 90 日分のリードを、スコアと結果（コンバージョンしたかどうか）とともにすべてエクスポート
2. スコアリングの各要素について、スコア帯別のコンバージョン率を計算
3. ある要素がコンバージョンと相関しない場合 → その重みを下げる
4. ある要素が強く相関する場合 → その重みを上げる
5. 合計の重みが 100％になるよう再調整

よくある失敗パターン

症状	原因	対処法
MQL が多すぎて、営業が対応しない	MQL のしきい値が低すぎる	しきい値を上げ、行動の重みを増やします
MQL が少なすぎて、パイプラインが不足する	しきい値が高すぎる、またはスコアリングの制約が厳しすぎる	しきい値を下げ、企業属性のフィルターが狭すぎないか確認します
スコアの高いリードが成約しない	属性の適合度を重視しすぎ、行動を軽視している	行動の重みを増やし、古くなったシグナルに減衰を設定します
スコアが時間とともに膨らむ	減衰ルールがなく、ポイントが増える一方になっている	すべての行動シグナルに減衰を実装します
インバウンドではモデルが機能するが、アウトバウンドでは機能しない	モデルに行動シグナルしか含まれていない	企業属性とタイミングの要素を追加します
営業とマーケティングで MQL の定義が一致しない	営業の意見を取り入れずにモデルを構築した	営業幹部としきい値を共同で作成し、毎月見直します

四半期ごとの再調整

四半期ごとに、次のことを行います。

1. 最新データでバックテストを再実行します
2. ICP が変化したか確認します（新しい業種、新しいペルソナ）
3. コンバージョンデータに基づいてポイント値を見直し、更新します
4. 新しいデータソースに基づいてスコアリングシグナルを追加または削除します
5. しきい値が引き続きファネルの対応能力に合っているか検証します

注意点

• 属性に重みをかけすぎないでください。 Claude は、照合が簡単なため、役職や職位に 50％以上の重みを与える傾向があります。しかし、行動シグナル（相手が何をしているか）は、属性（相手が誰か）よりも予測力があります。行動の重みは少なくとも 30％から始めてください。

• マイナススコアを省略しないでください。 完璧な会社で完璧な役職に就いているリードでも、学生、競合他社、またはすでに配信停止済みの人である可能性があります。マイナススコアを設けることで、営業の時間を無駄にし、営業チームからの信頼を損なう誤検出を防げます。

• 固定のしきい値を設定して、そのまま放置しないでください。 ICP の変化や市場環境の変化に伴い、スコアリングモデルはずれていきます。6 か月前に調整したモデルが、今日では不適切なリードを抽出している可能性があります。実際のコンバージョンデータを使って、四半期ごとに見直し、再調整してください。

• モデルを単独で構築しないでください。 営業とマーケティングは、MQL／SQL の定義に合意する必要があります。営業の意見を取り入れずにマーケティングが構築したスコアリングモデルは、「MQL の質が低い」という不満を招き、信頼を損ないます。営業幹部と共同で作成し、毎月一緒に見直してください。

• 自己改善：ここで取り上げられていないことを見つけた場合は、今日の日付を付けて references/learnings.md に追記してください。

特定のプラットフォームスキルを推奨する前に

このスキルは、さまざまなプラットフォームにまたがる戦略領域を扱います。特定のプラットフォームスキル（## Related skills に記載されている /sales-{platform}。例：/sales-mailshake、/sales-klaviyo、/sales-apollo）をユーザーに紹介する前に、そのプラットフォームスキルの実際の SKILL.md を必ず読んでください。## Related skills の 1 行の説明は候補を特定するには十分ですが、そのスキルを推奨することや、それを適切に呼び出すプロンプトを作成するには不十分です。

読み方：

• ~/.claude/skills/{skill-name}/SKILL.md がローカルに存在する場合は、Read で読みます。
• sales-* スキルの場合は、このリポジトリから直接 WebFetch します：https://raw.githubusercontent.com/sales-skills/sales/main/skills/{skill-name}/SKILL.md。例として、sales-mailshake の場合は https://raw.githubusercontent.com/sales-skills/sales/main/skills/sales-mailshake/SKILL.md です。
• sales-* 以外のスキル（サードパーティ製）の場合は、インストール済みであれば ~/.claude/skills/sales-do/references/skill-sources.md で {org}/{repo} を調べ、そのリポジトリ内の同じ skills/{skill-name}/SKILL.md パスを取得します。

読んだ後は、 SKILL.md の具体的な内容（対象範囲、サブフロー、argument-hint の形式、または「Do NOT use for...」という否定的な適用条件）に基づいて推奨してください。生成する呼び出しは、プラットフォームスキルの argument-hint に合わせます。プラットフォームスキルがユーザーの状況に合わない場合は、別のスキルに切り替えるか、ここで直接質問に対応し、不適切なスキルを推奨しないでください。

関連スキル

• /sales-intent — スコアリングモデルに反映する購買シグナルを読み取ります
• /sales-prospect-list — スコアリング対象の見込み顧客リストを作成します
• /sales-enrich — スコアリングに必要な人口統計・企業属性データでリードを充実させます
• /revops — スコアリングモデルを軸に、マーケティングから営業への引き継ぎプロセス全体を設計します
• /sales-apollo — Apollo のネイティブスコアリング機能を設定します
• /sales-activecampaign — ActiveCampaign プラットフォームのヘルプ（コンタクトスコアリング、取引スコアリング、しきい値トリガーを使用した自動化ベースのスコアリング）
• /sales-clearbit — Clearbit プラットフォームのヘルプ（スコアリング用のデータ補完、行動シグナル用の Reveal、HubSpot の Breeze Intelligence）
• /sales-rb2b — RB2B プラットフォームのヘルプ（スコアリングトリガー、Hot Pages、リアルタイムの CRM 統合に利用する個人単位の訪問者特定）
• /sales-6sense — 6sense プラットフォームのヘルプ（AI 主導の予測スコアリング、6QA の適格性判定、行動スコアリング用の Signalverse インテント）
• /sales-getresponse — GetResponse プラットフォームのヘルプ（コンタクトスコアリング、自動化トリガー型スコアリング、エンゲージメントベースのスコアリング）
• /sales-clay — Clay プラットフォームのヘルプ（スコアリング用のデータ補完ウォーターフォール、カスタムシグナル用の Claygent、スコアリングロジック用の Sculptor）
• /sales-sweeplift — SweepLift プラットフォームのヘルプ（ネイティブの 0～10 スコアと、スコアリング入力として使用する自己申告式の適格性調査への回答を備えた、インセンティブ付きキャンペーンのリード）
• /sales-do — どのスキルを使えばよいかわかりませんか？ルーターが、あらゆる営業目標に適したスキルを選びます。インストール：npx skills add sales-skills/sales --skill sales-do

例

例 1：インバウンド型 B2B SaaS のスコアリングモデル

ユーザーの発言：「B2B SaaS 製品のリードスコアリングモデルを作るのを手伝ってください。インバウンド中心で、ACV は 50,000 ドルです。」 スキルの動作：

1. インバウンド向けに重み付けした 4 次元モデルを設計します（行動 40％、人口統計 20％、企業属性 20％、タイミング 20％）
2. 各属性に具体的なしきい値を設けて点数を割り当てます
3. MQL を約 60 点、SQL を約 85 点に設定します
4. HubSpot／Salesforce での実装手順を提示します
5. テストと調整の計画を作成します 結果：しきい値を調整したスコアリングモデル一式、実装ガイド、月次レビューの実施計画

例 2：機能していないスコアリングモデルの修正

ユーザーの発言：「MQL から SQL へのコンバージョン率が 8％です。スコアリングモデルが機能していません。」 スキルの動作：

1. 考えられる原因を診断します（しきい値が低すぎる、人口統計の重みが大きすぎる、スコアの減衰がない）
2. スコアリング監査を推奨します。最近のリードを成果に照らしてバックテストします
3. 重みの調整案を提示します（行動の重みを増やし、人口統計の重みを減らす）
4. コンバージョンデータに基づくしきい値の再調整を提案します
5. 追跡する具体的な指標を定めた 30 日間の改善計画を作成します 結果：スコアリングモデルの問題の診断、具体的な修正案、再調整計画

例 3：PLG 製品の使用状況スコアリング

ユーザーの発言：「当社は PLG 企業です。製品の使用状況シグナルをリードスコアリングにどう反映すべきでしょうか？」 スキルの動作：

1. 行動を重視したモデルを設計します（製品シグナルを含む行動を 50％に設定）
2. 使用状況のしきい値（API 呼び出し、チームメンバー数、機能の利用状況）に基づいて PQL の基準を定義します
3. 製品分析イベントをスコアリングシグナルとして統合します
4. MQL／SQL とは別に PQL のしきい値を設定します
5. 製品の使用状況から営業アプローチへ引き継ぐトリガーを設計します 結果：製品イベントのスコアリング、PQL の定義、営業への引き継ぎトリガーを備えた、PLG に適したスコアリングモデル

トラブルシューティング

営業から「この MQL は使いものにならない」と言われる

原因：MQL のしきい値が低すぎるか、行動による検証を行わずに人口統計の適合度を重視しすぎています 解決策：営業が却下した直近 50 件の MQL を確認します。傾向を探します。ペルソナが違うのか、ペルソナは合っているもののエンゲージメントがないのかを見極めます。誤検出の原因となっている次元を調整します。多くの場合、全体のしきい値に加えて、行動スコアの最低要件を設けると解決します。

スコアのインフレ — 全員がMQLになってしまう

原因：減衰ルールがなく、ポイントが蓄積する一方で減少しません。 解決策：すべての行動シグナルに減衰を導入します（意図は14日、コンテンツは30日、タイミングは90日）。減衰の導入後、スコアを一度再計算します。

セグメントによってモデルのパフォーマンスが異なる

原因：画一的なモデルでは、セグメント固有の購買パターンが考慮されません。 解決策：異なるセグメント（エンタープライズとSMB、インバウンドとアウトバウンド）ごとに、別々のスコアリングモデルを検討します。最低限、企業属性の適合度スコアを調整し、エンタープライズのリードが異なるエンゲージメントパターン（訪問ページ数は少ない一方、取引規模は大きい）を理由に不利にならないようにします。