inbound-lead-qualification

Name: inbound-lead-qualification
Author: gooseworks-ai

github.com/gooseworks-aiマーケティング・グロース1.3k48 回インストール3 日前に更新

リポジトリ

inbound-lead-qualification について

インバウンドリードを理想顧客像（ICP）に照らして詳しく評価するマーケティングスキルです。企業、担当者、用途、CRM上の重複を確認し、スコア付きの判定をCSVで出力します。

主な機能

01複数形式のリードを解析
02CRMや商談状況との重複確認
03企業と担当者の適合性評価
04用途と製品の適合性分析
05スコア算出とCSV出力

活用シーン

01インバウンドリードの一括評価
02ICPに基づくリード採点
03既存顧客や進行中の商談の識別
04営業向けの判定表作成

インストール

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

$npx skills add https://github.com/gooseworks-ai/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へのアクセスを設定します。現在の作業ディレクトリ、またはユーザーが希望する場所（例：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": "HubSpot | Salesforce | CSV export | none",
    "access_method": "",
    "tables_or_objects": []
  },
  "existing_customer_source": {
    "tool": "HubSpot | Salesforce | 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（HubSpot、Salesforce、CSV）で、進行中の商談に該当する会社があるか検索します
一致する項目が見つかった場合：商談の詳細（ステージ、担当者、最終アクティビティ）とともに in_pipeline としてフラグを付けます
重要：営業担当者が連絡する前に、同僚がすでにそのアカウントを担当していることを把握できるようにします

確認 3 — 過去にやり取りがありますか？

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

確認 4 — シグナル関連の複合機能で確認されていますか？

CRMまたはシグナル追跡システムで会社を検索します
一致する項目が見つかった場合：シグナルの種類と日付とともに signal_flagged としてフラグを付けます

出力

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

pipeline_status：new | existing_customer | in_pipeline | previously_contacted
pipeline_detail：重複について説明する 1 文（該当しない場合は null）
signal_flags：シグナル関連の複合機能との一致

重複への対応

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

ステップ 3：企業の適格性評価

プロセス

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

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

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

ディメンション2 — 業界

対象業界と除外業界のリストに照らして確認します
分類は柔軟に行います。「AIを活用したHRプラットフォーム」は「AI/ML」と「HR Tech」の両方に該当します
スコア：match | adjacent（関連はありますが、主要な対象ではありません） | mismatch | unknown

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

シード、シリーズA、シリーズB以降、グロース、上場、ブートストラップ
情報源：SixtyFour または Orthogonal、ニュース、エンリッチメントデータ
スコア：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」は、従業員10,000人の大企業の「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 — 適格性を判断した理由を示す一文

パイプライン確認列：

pipeline_status — new | existing_customer | in_pipeline | previously_contacted
pipeline_detail — 重複についての一文
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

保存場所

現在の作業ディレクトリ、またはユーザーが希望する場所（例：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 アクセス — パイプライン、既存顧客、アウトリーチ履歴を確認するため
ウェブ検索 — エンリッチメントデータが少ない場合に企業を調査するため
エンリッチメントツール — SixtyFour や Orthogonal、LinkedIn スクレイパーなど（任意。精度が向上します）
読み取り／書き込み — CSV の入出力と設定管理のため

Markdown 対応

ログインしてコメント

基本情報

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

問題を報告