inbound-lead-qualification

Name: inbound-lead-qualification
Author: nikiandr

github.com/nikiandrマーケティング・グロース194 回インストール31 週間前に更新

リポジトリ

inbound-lead-qualification について

inbound-lead-qualificationは、営業・マーケティングチーム向けのリード評価スキルです。企業と購買担当者の条件を照合し、案件状況を確認して適合度を採点し、判定付きCSVを作成します。

主な機能

01さまざまな形式のリード一覧を解析
02CRM、案件、接触履歴との重複確認
03企業と担当者の適合度評価
04意向と製品適合度の評価
05スコアと評価判定の算出
06結果をCSVに出力

活用シーン

01ICPに基づくインバウンドリードの一括評価
02初期選別後のリードを詳しく審査
03既存顧客や進行中の商談を特定
04境界線上のリードを人手で確認

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/nikiandr/goose-skills --skill inbound-lead-qualification

インストール後、Claude Code で/inbound-lead-qualificationを入力して読み込まれたか確認します。

同梱ファイルskill.meta.json

詳細

インバウンドリードの適格性評価

インバウンドリードをまとめて受け取り、それぞれをICPの全条件に照らして検証します。迅速な一次選別（それはinbound-lead-triageの役割です）ではなく、リードが本当に追求する価値があるかを判断し、チーム向けにスコア付きCSVを作成する、徹底した適格性評価のステップです。

自動ロードするタイミング

次の場合に、この複合機能をロードします：

ユーザーが「このインバウンドリードを評価して」「これらのリードがICPに合致するか確認して」「インバウンドリードをスコアリングして」と言った場合
上流の一次選別が完了し、リードをさらに詳しく評価する必要がある場合
ユーザーがリードのリストを持っており、それぞれについて適格／不適格の判定を求めている場合

アーキテクチャ

[Inbound Leads] → Step 1: Load ICP & Config → Step 2: CRM/Pipeline Check → Step 3: Company Qualification → Step 4: Person Qualification → Step 5: Use Case Fit → Step 6: Score & Verdict → Step 7: Output CSV

ステップ0：設定（クライアントごとに1回）

初回実行時に、ICPの定義とCRMへのアクセスを設定します。clients/<client-name>/config/lead-qualification.jsonに保存します。

{
  "icp_definition": {
    "company_size": {
      "min_employees": null,
      "max_employees": null,
      "sweet_spot": "",
      "notes": ""
    },
    "industry": {
      "target_industries": [],
      "excluded_industries": [],
      "notes": ""
    },
    "use_case": {
      "primary_use_cases": [],
      "secondary_use_cases": [],
      "anti_use_cases": [],
      "notes": ""
    },
    "company_stage": {
      "target_stages": [],
      "excluded_stages": [],
      "notes": ""
    },
    "geography": {
      "target_regions": [],
      "excluded_regions": [],
      "notes": ""
    }
  },
  "buyer_personas": [
    {
      "name": "",
      "titles": [],
      "seniority_levels": [],
      "departments": [],
      "is_economic_buyer": false,
      "is_champion": false,
      "is_user": false
    }
  ],
  "hard_disqualifiers": [],
  "hard_qualifiers": [],
  "crm_access": {
    "tool": "Supabase | HubSpot | Salesforce | CSV export | none",
    "access_method": "",
    "tables_or_objects": []
  },
  "existing_customer_source": {
    "tool": "Supabase | CRM | CSV | none",
    "access_method": ""
  },
  "qualification_prompt_path": "path/to/lead-qualification/prompt.md or null"
}

lead-qualification機能に適格性評価プロンプトがすでに保存されている場合： それを直接参照し、ICP条件を最初から作り直さないでください。

2回目以降の実行時： 設定を通知せずに読み込みます。

ステップ1：ICP条件の読み込みとリードの解析

プロセス

クライアントのICP設定（またはlead-qualification機能の適格性評価プロンプト）を読み込みます
インバウンドリードのリストを解析します。形式は問いません：
- inbound-lead-triageの出力（正規化済み）
- 列構成を問わない未加工のCSV
- 名前／メールアドレス／会社名を貼り付けたリスト
- CRMのエクスポート
リードごとに、利用可能なデータと不足しているデータを特定します：
- あり： 入力に含まれているフィールド
- 必要： 適格性評価に必要だが不足しているフィールド
- 不足状況のレポート： 「会社名があるリードはX件、役職があるリードはY件、メールアドレスしかないリードはZ件です」

出力

利用可能／不足フィールドの一覧を付けた、解析済みのリードリスト
ユーザー向けの不足状況レポート

人間による確認ポイント

リードの50％を超える件数で重要なフィールド（会社名または担当者の役職）が不足している場合は、先にinbound-lead-enrichmentを実行するよう提案します。次のように尋ねます：「会社名や役職の情報が不足しているリードが多くあります。先に情報を補完しますか？それとも、現在利用できる情報で適格性を評価しますか？」

ステップ2：CRMとパイプラインの確認

プロセス

重複を特定するため、各リードについて既存のデータソースを確認します。

確認1 — 既存顧客か？

会社のドメイン名／社名で顧客データベースを検索します
一致するものが見つかった場合は、顧客情報（プラン、アカウント担当者、契約状況）とともにexisting_customerのフラグを付けます
これは不適格の判定ではありません。振り分け用のフラグです（アップセルか新規ビジネスか）

確認2 — すでにパイプラインにあるか？

CRM／Supabaseで、進行中の商談に該当する会社を検索します
一致するものが見つかった場合は、商談情報（ステージ、担当者、最終アクティビティ）とともにin_pipelineのフラグを付けます
重要：営業担当者が連絡する前に、同僚がすでにそのアカウントを担当していることを把握できるようにします

確認3 — 過去に接触したことがあるか？

メールアドレス／会社名でアウトリーチのログを検索します
一致するものが見つかった場合は、履歴の概要（時期、チャネル、結果）とともにpreviously_contactedのフラグを付けます

確認4 — シグナル複合機能で把握済みか？

Supabaseのシグナルテーブルで会社を検索します
一致するものが見つかった場合は、シグナルの種類と日付とともにsignal_flaggedのフラグを付けます

出力

各リードに次のタグを付けます：

pipeline_status：new | existing_customer | in_pipeline | previously_contacted
pipeline_detail：重複について説明する一文（またはnull）
signal_flags：シグナル複合機能との一致があればその内容

重複の取り扱い

既存顧客： 不適格と判定しないでください。別途記録します。契約拡大／アップセルの可能性があります。
パイプラインに存在： 不適格と判定しないでください。営業担当者間の連携が必要であることを示すフラグを付けます。既存商談の担当者を記録してください。
過去に接触したが返答がない： 引き続き適格性を評価します。インバウンドのシグナルがあるため、以前より関心が高まっている可能性があります。
過去に接触し、断られた： インバウンドリードは引き続き適格性を評価します。人の考えは変わるものです。以前の状況を記録してください。

ステップ3：会社の適格性評価

プロセス

各リードの会社について、すべてのICP企業ディメンションに照らして評価します。

ディメンション 1 — 会社規模

従業員数がICPの範囲内か確認します
情報源：エンリッチメントデータ、LinkedInの会社ページ、ウェブ検索
スコア：match | borderline | mismatch | unknown
注：リードが子会社または事業部門に所属している場合は、親会社ではなく該当する組織単位を評価します

ディメンション 2 — 業種

対象業種および除外業種のリストに照らして確認します
分類は柔軟に行います。「AI-powered HR platform」は「AI/ML」と「HR Tech」の両方に該当します
スコア：match | adjacent（関連はあるものの、主要な対象ではない）| mismatch | unknown

ディメンション 3 — 会社のステージ

シード、Series A、Series B 以降、グロース、上場、ブートストラップ
情報源：Crunchbase、ニュース、エンリッチメントデータ
スコア：match | borderline | mismatch | unknown

ディメンション 4 — 地理

本社の所在地、または担当者本人の所在地を確認します
リモートファーストの会社の場合は、チームの大半がどこにいるかを確認します
スコア：match | borderline | mismatch | unknown

ディメンション 5 — ユースケースとの適合性

会社の事業内容から見て、製品を利用する可能性があるかを評価します
最も慎重な評価を要するディメンションです。製品と会社の業務の両方を理解する必要があります
情報源：会社のウェブサイト、製品の説明、求人情報（社内ツールやプロセスの手がかりになります）
スコア：strong_fit | moderate_fit | weak_fit | no_fit | unknown

出力

各リードに company_qualification ブロックを付与します：

{
  "company_size": { "score": "", "value": "", "reasoning": "" },
  "industry": { "score": "", "value": "", "reasoning": "" },
  "stage": { "score": "", "value": "", "reasoning": "" },
  "geography": { "score": "", "value": "", "reasoning": "" },
  "use_case": { "score": "", "value": "", "reasoning": "" },
  "company_verdict": "qualified | borderline | disqualified | insufficient_data"
}

ステップ 4：担当者の適格性評価

プロセス

各リードの連絡先担当者について、バイヤーペルソナの基準に照らして評価します。

ディメンション 1 — 役職との一致

役職がバイヤーペルソナの役職リストに該当するか確認します
表記の違いを考慮します。「VP of Marketing」＝「Vice President, Marketing」＝「VP Marketing」
小規模企業における役職の誇張を考慮します（従業員10人のスタートアップの「Director」は、従業員1万人の大企業の「Director」とは異なります）
スコア：exact_match | close_match | adjacent | mismatch | unknown

ディメンション 2 — 職位レベル

次のいずれかに分類します：個人貢献者、マネージャー、ディレクター、VP、Cレベル、創業者
ICPの職位要件に照らして確認します
スコア：match | too_junior | too_senior | unknown

ディメンション 3 — 部門

エンジニアリング、プロダクト、マーケティング、営業、オペレーション、財務、人事など
ICPの対象部門に照らして確認します
スコア：match | adjacent | mismatch | unknown

ディメンション 4 — 権限の種類

役職と職位に基づいて分類します：
- economic_buyer — 購入を決定し、契約に署名できます
- champion — 製品を望んでおり、意思決定に影響を与えられます
- user — 日常的に製品を使用し、ニーズを検証できます
- evaluator — 調査を任されていますが、意思決定権は限られています
- gatekeeper — 導入を阻止できますが、承認はできません
- unknown

ディメンション 5 — 適切な会社だが担当者が不適切（またはその逆）

会社は条件を満たすものの、担当者が満たさない場合：right_company_wrong_person としてフラグを付けます。これは紹介につながる可能性があります
担当者は条件を満たすものの、会社が満たさない場合：right_person_wrong_company としてフラグを付けます。インバウンドではまれですが、転職者の場合はあり得ます

出力

各リードに person_qualification ブロックを付与します：

{
  "title_match": { "score": "", "value": "", "reasoning": "" },
  "seniority": { "score": "", "value": "", "reasoning": "" },
  "department": { "score": "", "value": "", "reasoning": "" },
  "authority_type": "",
  "person_verdict": "qualified | borderline | disqualified | insufficient_data",
  "mismatch_type": "null | right_company_wrong_person | right_person_wrong_company"
}

ステップ 5：ユースケース適合性の評価

プロセス

このステップでは、企業が必要としている可能性が高いことと、製品が実際に備えている機能を結び付けます。ステップ 3 の企業レベルでのユースケース確認より、さらに深く掘り下げます。

見込み客の意図を推測するために、見込み客が起こしたアクションを確認します。
- デモのリクエストメッセージ → 何が必要だと言っていましたか？
- コンテンツのダウンロード → どのようなトピックを調べていましたか？
- ウェビナーへの参加 → どのような問題を解決しようとしていましたか？
- 無料トライアルへの登録 → 最初にどの機能を試しましたか？
- チャットボットとの会話 → どのような質問をしましたか？
意図を製品の機能に対応付けます。
- 製品は、見込み客が必要としていると思われるものを実際に解決できますか？
- 主要なユースケースですか、それとも適用範囲を広げたものですか？
- 期待外れにつながる可能性がある既知の制限はありますか？
導入の実現可能性を評価します。
- 企業の規模と成長段階を踏まえて、現実的に導入できますか？
- 導入に必要な技術リソースやチームがあると考えられますか？
- このような企業で、既知の阻害要因はありますか？（例：「銀行には SOC2 が必要だが、当社はまだ取得していない」）

出力

{
  "inferred_intent": "",
  "intent_source": "",
  "product_fit": "strong | moderate | weak | unknown",
  "product_fit_reasoning": "",
  "implementation_feasibility": "easy | moderate | complex | unlikely",
  "known_blockers": []
}

ステップ 6：スコアと判定

スコアリングロジック

すべての評価項目を組み合わせて、最終的な見込み客の適格性を判定します。

合成スコアの計算：

評価項目	重み	可能な値
企業規模	15%	match=100、borderline=50、mismatch=0、unknown=30
業界	20%	match=100、adjacent=60、mismatch=0、unknown=30
企業の成長段階	10%	match=100、borderline=50、mismatch=0、unknown=30
地域	10%	match=100、borderline=50、mismatch=0、unknown=30
ユースケースとの適合性	25%	strong=100、moderate=60、weak=20、no_fit=0、unknown=30
担当者の肩書き／役割	15%	exact=100、close=75、adjacent=40、mismatch=0、unknown=30
担当者の職位	5%	match=100、too_junior=20、too_senior=60、unknown=30

スコアを適用しない例外条件：

ハードな失格条件に該当するものがある → スコアにかかわらず disqualified
ハードな適格条件に該当するものがある → スコアにかかわらず qualified（ただし、内訳はすべて表示します）
既存顧客 → 別途振り分け、新規見込み客として採点しない

判定のしきい値：

スコア ≥ 75： qualified — 積極的にアプローチします
スコア 50-74： borderline — 条件付きで適格。人による確認が必要な場合があります
スコア 30-49： near_miss — 現時点では適格ではありませんが、検討の余地があります（紹介または育成）
スコア < 30： disqualified — ICP に適合しません

振り分け用のサブ判定：

qualified_hot — スコア ≥ 75 かつ、トリアージの緊急度が Tier 1/2
qualified_warm — スコア ≥ 75 かつ、トリアージの緊急度が Tier 3/4
borderline_review — スコア 50-74。人による判断が必要
near_miss_referral — スコア 30-49 かつ、right_company_wrong_person（紹介の機会）
near_miss_nurture — スコア 30-49。将来的に適合する可能性あり
disqualified_polite — スコア < 30。丁寧な辞退が必要
disqualified_competitor — 競合他社の従業員
existing_customer_upsell — 拡大の兆候がある既存顧客

出力

各見込み客について、次の情報を出力します。

{
  "composite_score": 0-100,
  "verdict": "",
  "sub_verdict": "",
  "top_qualification_reasons": [],
  "top_disqualification_reasons": [],
  "summary": "One sentence: why this lead is/isn't a fit"
}

ステップ 7：CSV を出力する

CSV の構造

すべての入力フィールドを保持し、次の判定列を追加した CSV を作成します。

基本の判定列：

qualification_verdict — qualified | borderline | near_miss | disqualified
qualification_sub_verdict — qualified_hot | qualified_warm | borderline_review | near_miss_referral | near_miss_nurture | disqualified_polite | disqualified_competitor | existing_customer_upsell
composite_score — 0～100
summary — 判定理由を示す 1 文

パイプライン確認列：

pipeline_status — new | existing_customer | in_pipeline | previously_contacted
pipeline_detail — 重複状況を示す 1 文
signal_flags — 該当するシグナルの組み合わせ

企業の適合性判定列：

company_size_score — match | borderline | mismatch | unknown
industry_score — match | adjacent | mismatch | unknown
stage_score — match | borderline | mismatch | unknown
geography_score — match | borderline | mismatch | unknown
use_case_score — strong | moderate | weak | no_fit | unknown

担当者の適合性判定列：

title_match_score — exact_match | close_match | adjacent | mismatch | unknown
seniority_score — match | too_junior | too_senior | unknown
authority_type — economic_buyer | champion | user | evaluator | gatekeeper | unknown
mismatch_type — null | right_company_wrong_person | right_person_wrong_company

ユースケース列：

inferred_intent — 相手が必要としていると考えられるもの
product_fit — strong | moderate | weak | unknown
implementation_feasibility — easy | moderate | complex | unlikely

保存先

clients/<client-name>/leads/inbound-qualified-[date].csv

サマリーレポート

CSV を作成した後、次のサマリーを提示します。

## Inbound Lead Qualification: [Period]

**Total leads processed:** X
**Qualified:** X (Y%) — X hot, X warm
**Borderline (manual review):** X (Y%)
**Near miss:** X (Y%) — X referral opportunities, X nurture
**Disqualified:** X (Y%)

**Pipeline overlaps:**
- Existing customers: X (route to CS)
- Already in pipeline: X (coordinate with deal owner)
- Previously contacted: X (now warmer — re-engage)

**Top qualification reasons:**
1. [reason] — X leads
2. [reason] — X leads

**Top disqualification reasons:**
1. [reason] — X leads
2. [reason] — X leads

**Data quality:**
- Leads with full data: X
- Leads with partial data (some dimensions scored as 'unknown'): X
- Leads needing enrichment: X

**CSV saved to:** [path]

エッジケースの処理

メールアドレスしかないリード（名前も会社名もない場合）：

メールアドレスから会社のドメインを抽出します
法人ドメインの場合：会社を調査し、企業の適合性判定を進めます（担当者の適合性判定はほとんどが「unknown」になります）
個人用メールアドレス（gmail、yahoo）の場合：insufficient_data と判定し、情報の補完または手動レビューを推奨します

同じ会社から複数のリードがある場合：

会社の適合性は一度だけ判定し、その会社のすべてのリードに適用します
担当者の適合性は個別に判定します
複数の担当者がいる機会としてフラグを付けます：「[Company] から 3 人が問い合わせ — 購買委員会での検討の可能性」

矛盾するシグナル：

会社は非常に適合しているものの、担当者がまったく適していない場合（例：最適な会社に所属するインターン）
正直にスコアを付けます。サブ判定 right_company_wrong_person により、これは disqualification-handling で紹介対応に振り分けられます

ボーダーラインの判定：

スコアが 50～74 で、どちらとも判断し得る場合は、インバウンドリードでは適合とする方向に判断します
理由：相手はあなたに問い合わせています。この意図のシグナルにより、ボーダーラインのケースも「会話する価値がある」方向に傾きます
判断理由には、この傾向を記載します：「[dimension] はボーダーラインですが、インバウンドの意図を考慮してアプローチを推奨します」

データが不足している場合のスコア付け：

不明な項目は 30 点として扱います（0 点でも 50 点でもありません）。データがないことはややマイナスですが、失格とする理由にはなりません
3 項目を超えて「unknown」がある場合は、スコアにかかわらずリードを insufficient_data とし、まず情報を補完することを推奨します

必要なツール

CRM へのアクセス — パイプライン、既存顧客、過去のアウトリーチ履歴を確認するため
Supabase クライアント — パイプライン／シグナルを検索するため
ウェブ検索 — エンリッチメントデータが少ない場合に会社を調査するため
エンリッチメントツール — Apollo、LinkedIn スクレーパーなど（任意。精度が向上します）
読み取り／書き込み — CSV の入出力と設定管理のため

Markdown 対応

ログインしてコメント

基本情報

作者: nikiandr
リポジトリ: nikiandr/goose-skills
カテゴリ: マーケティング・グロース
インストール数: 94
GitHub スター: 1

問題を報告