prospect-scoring について
prospect-scoringは、営業連絡前に公開されている企業プロフィールから未接触アカウントを評価するスキルです。適合度のスコアと購買シグナルのタイミングを分け、欠損データや判定ゲートの扱いを定めています。
主な機能
- 01ICPとサービス適合度の2軸評価
- 02シグナルに基づく別々の営業キュー
- 03欠損データのフラグと信頼度
- 04空の評価軸を考慮した正規化合計
- 05従業員数の確認指針
- 06アカウントごとのスコアとゲート結果
活用シーン
- 01連絡前の未接触アカウントの優先付け
- 02適合度と購買タイミングの切り分け
- 03情報補完が必要なレコードの特定
- 04ゲート未通過のアカウントを後日確認
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/prospect-scoringを入力して読み込まれたか確認します。
詳細
見込み顧客のスコアリング
まだ誰も接触していない段階で、コールドアカウントが対象となるプロフィールかどうかという問いに答えます。
ここにある情報はすべて、会話なしで確認できます。相手が何をしているのか、誰にサービスを提供しているのか、どんな体制なのか。
通話でしか確認できない情報は、このスコアの対象ではありません。それは lead-scoring の対象です。
ほとんどの不適切な評価基準を正すルール
除外フィルターですでに使っている項目を、スコアリングしてはいけません。
地域や従業員数をフィルタリング段階で必須条件としているなら、それらに点数を付けてはいけません。 条件を通過したアカウントは定義上すでに条件を満たしているため、その点数は全員に同じように加算され、しきい値が何も判別できなくなるまで合計を膨らませます。4つの項目に100点を配分し、そのうち2つがすでに必須条件だった評価基準は、まさにこの理由で見直す必要がありました。 数字は差を見分けているように見えても、実際にはそうではなかったのです。
必須条件を除くと、残る項目はたいてい少数です。それで正しいのです。接触前のスコアでは、信頼できる2つの項目に基づく評価のほうが、6つはノイズである8項目に基づく評価より優れています。
スコアの構成
プロフィール情報のみを使います。以下は、ICPごとに調整するための実用的な初期設定です。
| 項目 | 最大点 | 確認元 |
|---|---|---|
| ICPとの適合性 — 対象とする企業のタイプか | 15 | 相手自身による説明：ウェブサイト、企業ページ、専門分野 |
| サービスとの適合性 — 販売する特定のサービスを必要としているか | 15 | 掲載サービス、公開されている実績、明らかに不足している、または社内で提供している機能 |
各項目は4段階で評価するため、同じアカウントを評価する2人が同じ点数になります。
| 点数 | ICPとの適合性 | サービスとの適合性 |
|---|---|---|
| 15 | 相手自身の説明に、対象のニッチ市場とサブ業界が明記されている | このサービスを提供しておらず、その需要があることが明らかに分かる |
| 10 | 対象業界、または隣接するサブ業界 | 社内で提供しているが、担当者は1～2人 |
| 5 | 説明が曖昧で、ニッチ市場を推測する必要がある | 自社チームがあり、自社サービスはそれを補完するにとどまる |
| 0 | データなし → data-gap フラグ | データなし → data-gap フラグ |
必須条件： 合計点の下限（例：30点中20点）。これを下回るアカウントは、ほかの条件にかかわらずアウトリーチの対象になりません。
| 例 | 合計点 | 判定 |
|---|---|---|
| 15 + 10 | 25 | アウトリーチ |
| 10 + 10 | 20 | アウトリーチ |
| 15 + 0 | 15 | データ不足を解消してから再評価 |
| 5 + 5 | 10 | アウトリーチしない |
項目を追加するのは、（a）接触前に確認でき、（b）すでに必須条件として使われておらず、（c）母集団内で実際に差がある場合に限ります。案件のポテンシャルが条件を満たすのは、母集団に実際にその差がある場合のみです。通常はそうではありません。以下の正規化を参照してください。
シグナルが決めるのはポイントではなくルートです
評価基準でよくあるもう1つの誤りです。購買シグナルは、アカウントの適合性を高めるのではなく、より適切なタイミングを示します。適合性とタイミングは異なる軸なので、1つの数値に合算してはいけません。そうすると、プロフィールが完璧でもきっかけのないアカウントが、たまたま採用活動をしている適合性の低いアカウントより低く評価されてしまいます。
そのため、シグナルが決めるのはスコアではなく、キューです。
| キュー | 条件 | 冒頭の一文の根拠 |
|---|---|---|
| A | 強い、現在有効なシグナル | 日付とリンクを添えたイベント |
| B | 弱い、または古いシグナル | 控えめな表現にしたイベント |
| D | 現在有効なシグナルなし | 相手自身のウェブサイトから得た情報 |
シグナルがないからといって、スコアが低いわけではありません。キューDに振り分け、モニタリング期間を設定するということです。何もないと結論づける前に、約30日後に再確認します。
募集開始から45日以上経過しても募集が続いている求人は、募集を始めたばかりの求人より強いシグナルです。採用できずにいるためです。募集が継続している間は、その求人シグナルを減衰させないでください。
欠損データ
- 欠損値 → 0 とし、
data-gapフラグを付けます。推測値や中間値は使いません。 推測した企業属性が、誰かに頼りにされる予測値になってしまいます。 - あるディメンション全体が構造的に空の場合は正規化します。 対象企業のすべてで取引規模が欠損している場合、そのディメンションは全社で 0 となり、上限値が下がり、ゲートを通過するアカウントはなくなります。数値は 2 つ保持します。生の合計値と、実際にデータがあったディメンションに対する同じ合計値の割合です。ゲート判定には後者を使います。ただし、データ信頼度が M または H の場合に限ります。L の場合は生の合計値を使い、2 項目しか埋まっていない行が満点のように見えないようにします。
- ティアを設定するのは、検証済みの数値に限ります。 従業員数が未確認の場合、ティアのセルには「手動で確認」と記入します。空欄にも、推測した値にもしてはいけません。
双方向に陥る従業員数の罠
明らかに見える修正案は逆のケースで問題を引き起こすため、ここで説明しておきます。
企業のウェブサイトは、組織の規模を体系的に誇張します。何十人ものエンジニアがいると記載されたサイトでも、実態は 3 人の会社ということがあります。入手できる数値のうち小さい方を採用したくなりますが、すると今度は大企業で問題が起きます。大手のエージェンシーはスタッフを名前付きで掲載しないため、名前付きの人数を数えると実態を大幅に下回ってしまいます。
どちらのケースにも対応できる方法は、従業員数の情報源は企業ページとし、サイト上の名前付き人数は照合用にのみ使い、情報源にはしないことです。 名前付き人数が企業ページの数値を大幅に下回り、ページの数値自体も小さい場合は、その行にフラグを付け、最上位の帯より低く設定します。人の確認が必要ですが、除外はしません。
数値は別々の列に保持します。ひとたび 1 つの「従業員数」フィールドに統合してしまうと、検証済みの数値と推定値を区別できなくなります。
出力
アカウントごとに 1 行とします。Company · Tier · per-dimension points · Raw total · Normalised total · Data confidence (H/M/L) · Gate (pass/fail) · Queue (A/B/D) · Missing fields。
さらに data-gap リストを作成します。スコアに意味を持たせる前に、情報の補完が必要なアカウントを記載します。ゲートを通過しなかった行も理由とともにファイルに残します。削除すると、四半期後に再購入・再調査することになります。
してはいけないこと
- ストップフィルターで判定済みのものを採点しないでください。
- 適合度とタイミングを 1 つの数値に合算しないでください。
- 不確かなときに切り上げないでください。低い方の帯を採用します。
- 誰も承認していない重み付けで実際の対象企業群を実行しないでください。承認されていない場合は、その旨を明記し、実行結果にドラフトプレビューのラベルを付けます。
引き継ぎ
ゲート通過 → キュー割り当て → 連絡先に対して waterfall-enrichment を実行し、その後、キャンペーンごとに sequence-writer を実行します。返信が届いたら、アカウントを lead-scoring に移します。この処理では、このプロファイルを出発点として、会話でのみ確認できる情報を追加します。