inbound-lead-enrichment

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

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

リポジトリ

inbound-lead-enrichment について

営業チーム向けに、不完全なインバウンドリードを調査するスキルです。企業・人物プロフィールの作成、関係者の特定、CRMや営業履歴の確認を行い、情報を補完したリードデータとCSVにまとめます。

主な機能

01リードの不足データを評価
02企業と人物のプロフィールを調査
03購買委員会の関係者を特定
04CRM、案件、営業履歴を確認
05補完済みデータとCSVを作成

活用シーン

01企業名や役職が不足したインバウンドリードの補完
02見込み企業内の他の関係者の特定
03リードや企業の過去の営業活動を確認

インストール

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

$npx skills add https://github.com/gooseworks-ai/goose-skills --skill inbound-lead-enrichment

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

同梱ファイルskill.meta.json

詳細

インバウンドリードの情報補完

データが不完全なインバウンドリードを受け取り、不足情報を補います。企業を調査し、担当者の役職を特定し、同じ企業のほかの関係者を見つけ、CRM に既存の関係があるかを確認します。メールアドレスだけの状態から、リードの詳細なプロフィールを作成します。

自動読み込みのタイミング

以下の場合に、この複合ワークフローを読み込みます。

ユーザーが「これらのリードの情報を補完して」「不足しているデータを埋めて」「これらのインバウンドリードを調査して」と言った場合
inbound-lead-qualification がリードを insufficient_data として分類した場合
inbound-lead-triage が企業名や役職のフィールドが不足しているリードを検出した場合
ユーザーがメールアドレスのリストや部分的なリード情報を持っており、完全なプロフィールを必要としている場合

アーキテクチャ

[Raw Leads] → Step 1: Assess Gaps → Step 2: Company Research → Step 3: Person Research → Step 4: Stakeholder Discovery → Step 5: Relationship Check → Step 6: Compile & Output
                   ↓                      ↓                         ↓                          ↓                             ↓                          ↓
            Gap inventory        Company profiles         Person profiles            Buying committee          CRM/pipeline matches       Enriched lead records

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

初回実行時に、情報補完ツールの設定を確立します。

{
  "enrichment_tools": {
    "company_research": {
      "primary": "SixtyFour | Orthogonal | web-search",
      "secondary": "web-search"
    },
    "person_research": {
      "primary": "SixtyFour | Orthogonal | web-search",
      "secondary": "web-search"
    },
    "stakeholder_finding": {
      "primary": "SixtyFour | Orthogonal | web-search",
      "secondary": "web-search"
    }
  },
  "crm_source": {
    "tool": "HubSpot | Salesforce | CSV | none",
    "access_method": ""
  },
  "buyer_personas": [],
  "enrichment_depth": {
    "tier_1_leads": "deep",
    "tier_2_leads": "deep",
    "tier_3_leads": "standard",
    "tier_4_leads": "minimal",
    "untiered_leads": "standard"
  }
}

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

ステップ 1：データの不足を評価

プロセス

リードごとに、既知の情報と不明な情報を一覧にします。

必須フィールド（必ず入力）：

company_name — 勤務先の企業名
company_domain — 企業ウェブサイトのドメイン
person_name — 氏名
person_title — 現在の役職
person_email — 連絡先メールアドレス（通常、インバウンド時にすでに取得済みです）

重要なフィールド（可能であれば入力）：

company_size — 従業員数または規模の範囲
company_industry — 業種分類
company_stage — 資金調達段階または成熟度
company_hq — 本社所在地
company_description — 事業内容を説明する 1 文
person_seniority — IC、マネージャー、ディレクター、VP、C レベル、創業者
person_department — エンジニアリング、営業、マーケティングなど
person_linkedin — LinkedIn プロフィールの URL
person_tenure — 現在の企業での在籍期間

追加フィールド（あれば便利）：

company_tech_stack — 使用が確認されている技術
company_recent_news — 最近の出来事（資金調達、製品リリース、採用など）
person_background — 過去の勤務先、学歴
person_social_activity — 最近の投稿や関心のあるトピック

不足レベルの分類

リードごとに、必要な情報補完の作業量を分類します。

不足レベル	不足内容	必要な情報補完	コスト
最小限	重要なフィールドが 1～2 件	ウェブで簡単に検索	無料
標準	企業情報または役職が不足	ウェブ検索＋必要に応じて API で照会	低
詳細	必須フィールドが複数不足	複数の情報源を使った調査	中
メールのみ	メールアドレスしかない	一から全項目を調査	高

出力

各リードと不足情報を示す不足状況一覧表
リードごとに推奨する情報補完の深さ（不足レベルと、利用可能な場合は緊急度の段階に基づく）
有料ツールを使用する場合の費用見積もり

人による確認

「リード全体の不足情報は以下のとおりです。詳細な情報補完が必要なのは [X] 件、標準的な情報補完が必要なのは [Y] 件、簡単な確認だけでよいのは [Z] 件です。推定費用：[amount]。進めてもよろしいですか？」

ステップ 2：企業調査

プロセス

リードリストに含まれる各企業について、重複を除外して調査します。複数のリードで同じ企業を重複して調査しないでください。

企業名がない場合：メールドメインから特定する

メールからドメインを抽出します（例：[email protected] → acme.com）
個人用メールドメイン（gmail、yahoo、hotmail、outlook など）はスキップします
ドメインを検索して、企業名と説明を調べます

企業プロフィールの調査：

項目	主な情報源	代替情報源
企業名	ドメイン検索	ウェブ検索
説明	企業ウェブサイト（ホームページ、概要ページ）	LinkedIn の企業ページ、ウェブ検索
従業員数	SixtyFour または Orthogonal、LinkedIn の企業ページ	ウェブ検索
業界	LinkedIn の企業ページ、SixtyFour または Orthogonal	ウェブサイトのコンテンツから推定
段階／資金調達	SixtyFour または Orthogonal、ニュース記事	ウェブ検索
本社所在地	LinkedIn の企業ページ、ウェブサイト	ウェブ検索
技術スタック	求人情報、BuiltWith	ウェブ検索
最近のニュース	ウェブ検索（過去90日間）	Twitter／ソーシャルメディアでの言及

設定に応じた調査の深さ：

Deep： すべての項目を複数の情報源で調べ、情報源間で照合します
Standard： 必須項目と有用な項目を主な情報源のみで調べます
Minimal： 企業名、説明、規模のみを調べます

出力

各企業に company_profile ブロックを作成します：

{
  "company_name": "",
  "company_domain": "",
  "company_description": "",
  "employee_count": "",
  "employee_range": "",
  "industry": "",
  "sub_industry": "",
  "stage": "",
  "last_funding": "",
  "hq_location": "",
  "tech_stack": [],
  "recent_news": [],
  "research_sources": [],
  "confidence": "high | medium | low"
}

個人用メールドメインの処理

リードが個人用メール（gmail など）を使用している場合：

名前と、利用可能なほかの情報から企業を特定できるか確認します（フォームの入力欄、チャットメッセージなど）
フォームの送信内容またはチャットで企業名が言及されている場合は、その企業を使用します
企業が本当に不明な場合は company_unidentified として記録します。名前がわかる場合は、その人物の調査を続けます

ステップ 3：人物調査

プロセス

各リードについて、人物プロフィールを作成します。

名前と企業名から特定する（役職がない場合）：

設定済みのツールまたはウェブ検索を使って、LinkedIn でその企業に所属する人物を検索します
SixtyFour または Orthogonal と照合します
複数の候補がある場合は、メールドメインを使って特定します

人物プロフィールの調査：

項目	主な情報源	代替情報源
氏名	入力データ	LinkedIn プロフィール
現在の役職	LinkedIn プロフィール、SixtyFour または Orthogonal	ウェブ検索
職位レベル	役職から推定	LinkedIn プロフィール
部門	役職から推定	LinkedIn プロフィール
現職の在籍期間	LinkedIn プロフィール	ウェブ検索
前職の企業	LinkedIn プロフィール	ウェブ検索
学歴	LinkedIn プロフィール	スキップ
LinkedIn URL	SixtyFour または Orthogonal、ウェブ検索	スキップ
LinkedIn の見出し	LinkedIn プロフィール	スキップ
最近の活動	LinkedIn の投稿（スクレイパーが設定されている場合）	スキップ

職位レベルの推定ルール：

役職に Intern、Associate、Coordinator、Specialist が含まれる場合 → IC_junior
役職に Analyst、Engineer、Designer、Developer が含まれ、「Senior／Lead／Staff」が含まれない場合 → IC_mid
役職に Senior、Lead、Staff、Principal が含まれる場合 → IC_senior
役職に Manager、Team Lead が含まれる場合 → Manager
役職に Director、Head of が含まれる場合 → Director
役職に VP、Vice President、SVP、EVP が含まれる場合 → VP
役職に Chief、Cレベルの略称（CTO、CMO、CRO、CFO）、President が含まれる場合 → C_Level
役職に Founder、Co-founder、Owner が含まれる場合 → Founder

企業規模に応じた調整：

従業員数が20人未満の企業では、職位レベルを1段階上げます（「Manager」の担当範囲は Director レベルです）
従業員数が5000人を超える企業では、職位レベルを1段階下げます（「Director」の裁量は Manager レベルの場合があります）

出力

各リードに person_profile ブロックを作成します：

{
  "full_name": "",
  "current_title": "",
  "seniority_level": "",
  "department": "",
  "tenure_months": null,
  "previous_companies": [],
  "education": "",
  "linkedin_url": "",
  "linkedin_headline": "",
  "recent_activity_summary": "",
  "research_sources": [],
  "confidence": "high | medium | low"
}

ステップ 4：ステークホルダーの特定

プロセス

リードリスト内の各企業について、ほかの関係者、つまり購買委員会のメンバーを特定します。

重要な理由：

インバウンドリードが唯一の意思決定者であることはほとんどありません
購買委員会のほかのメンバーを早期に見つけると、商談の進行が速まります
マルチスレッド化（同じ企業の複数の人と関係を築くこと）により、受注率が大幅に向上します

特定する対象（設定のバイヤーペルソナに基づく）：

経済的決裁者 — 決裁を行う人です。通常、該当部門の VP 以上または C レベルです。
推進者 — 社内で導入を推進する可能性が最も高い人です。通常、課題を抱えているシニア IC またはディレクターです。
技術評価者 — 製品の技術的な適合性を評価する人です。通常、エンジニアリングまたはオペレーション部門の担当者です。
エンドユーザー — 製品を日常的に使用する人です。本人の賛同を得ることで、販売後の解約を防げます。

企業ごとのプロセス：

バイヤーペルソナを使って、検索する役職を判断します
設定済みのツール（SixtyFour または Orthogonal、LinkedIn、company-contact-finder）で検索します
見つかった各ステークホルダーについて、名前、役職、職位、LinkedIn URL、メールアドレス（入手可能な場合）を記録します
インバウンドリードとの関係を記録します。同じチームか、同じ部門か、別の職能かを確認します

調査の深さ：

詳細なエンリッチメント（Tier 1～2 のリード）：4 種類すべてのステークホルダーを見つけ、それぞれを調査します。
標準的なエンリッチメント（Tier 3 のリード）：経済的決裁者と推進者のみを見つけます。
最小限のエンリッチメント（Tier 4／ティア未設定）：ステークホルダーの特定を省略します。

出力

各企業に stakeholder_map を設定します：

{
  "company": "",
  "inbound_lead": {
    "name": "",
    "title": "",
    "role_in_deal": "economic_buyer | champion | evaluator | user | unknown"
  },
  "stakeholders_found": [
    {
      "name": "",
      "title": "",
      "seniority": "",
      "linkedin_url": "",
      "email": "",
      "role_in_deal": "",
      "relationship_to_lead": "",
      "confidence": "high | medium | low"
    }
  ],
  "buying_committee_completeness": "full | partial | minimal",
  "recommended_multi_thread": ""
}

ステークホルダーの優先順位付け

インバウンドリードが経済的決裁者の場合 → ステークホルダーは補足情報として扱いますインバウンドリードがユーザー／評価者の場合 → 経済的決裁者を見つけることが重要ですインバウンドリードの役割が不明な場合 → その役割を特定することで、マルチスレッド化の戦略が決まります

ステップ 5：関係性の確認

プロセス

各リードと、特定した各ステークホルダーについて、既存のシステムを確認し、過去の関係性を調べます。

確認 1 — CRM（HubSpot、Salesforce、CSV）：

この人はすでに自社のシステムに登録されていますか？
登録されている場合、現在のステータスは何ですか？（対応中のリード、連絡済み、ナーチャリング中、顧客、解約済み）
登録されている場合、誰が関係を担当していますか？

確認 2 — アウトリーチ履歴（outreach_log）：

この人に以前、メールやメッセージを送ったことがありますか？
送っている場合、いつ、どのチャネルで、結果はどうでしたか？
重要：先週コールドメールを送り、無視された相手が、今度はインバウンドリードとして現れるという行き違いを防ぎます

確認 3 — 企業レベルのパイプライン（companies テーブルまたは CRM）：

この企業との進行中の商談はありますか？
ある場合、どの段階ですか？商談の担当者は誰ですか？
進行中の商談がある企業からインバウンドリードが来た場合は非常に重要なシグナルです。目立つようにフラグを付けます

確認 4 — シグナル履歴（signals テーブル）：

この企業は、シグナルスキャンで検出されたことがありますか？
ある場合、どのシグナルですか？対応済みですか？

確認 5 — 共通のつながり（データがある場合）：

自社チームの誰かが、この企業の人と知り合いですか？
該当する場合、紹介につなげられる経路を記録します

出力

各リードに relationship_context ブロックを設定します：

{
  "person_in_crm": true/false,
  "person_crm_status": "",
  "person_outreach_history": [
    {
      "date": "",
      "channel": "",
      "campaign": "",
      "outcome": ""
    }
  ],
  "company_in_pipeline": true/false,
  "company_deal_stage": "",
  "company_deal_owner": "",
  "company_signal_history": [],
  "mutual_connections": [],
  "relationship_summary": ""
}

ステップ 6：まとめて出力

エンリッチメント済みリードレコード

調査内容をリードごとに 1 つのエンリッチメント済みレコードにまとめます。

{
  "original_data": {},
  "company_profile": {},
  "person_profile": {},
  "stakeholder_map": {},
  "relationship_context": {},
  "enrichment_metadata": {
    "enrichment_depth": "deep | standard | minimal",
    "fields_filled": X,
    "fields_still_missing": [],
    "sources_used": [],
    "confidence_overall": "high | medium | low",
    "enrichment_date": "",
    "cost_incurred": ""
  }
}

出力形式

主な形式：エンリッチ済み CSV

エンリッチしたすべてのフィールドを元のリードデータに追加した CSV を作成します。

元のフィールド	+ 企業フィールド	+ 人物フィールド	+ ステークホルダーフィールド	+ 関係性フィールド	+ メタデータ
すべての入力列	company_description, employee_count, industry, stage, hq, tech_stack, recent_news	current_title, seniority, department, tenure, linkedin_url, headline	stakeholder_1_name, stakeholder_1_title, stakeholder_1_role, ...（最大 4 名）	in_crm, crm_status, in_pipeline, deal_stage, outreach_history_summary	enrichment_depth, confidence, fields_missing, sources_used

現在の作業ディレクトリ、またはユーザーが指定する場所（例：leads/inbound-enriched-[date].csv）に保存します。

副次的な形式：エンリッチメントレポート

## Lead Enrichment Report: [Date]

### Summary
- **Total leads enriched:** X
- **Deep enrichment:** X leads (Tier 1-2)
- **Standard enrichment:** X leads (Tier 3)
- **Minimal enrichment:** X leads (Tier 4)

### Data Quality
- **Fully enriched** (all required + valuable fields): X leads
- **Mostly enriched** (all required, some valuable): X leads
- **Partially enriched** (some required fields still missing): X leads
- **Could not enrich** (insufficient starting data): X leads

### Company Research
- **Unique companies researched:** X
- **Companies already in CRM:** X
- **Companies with active deals:** X (flag for deal owner)
- **Companies with signal history:** X

### Stakeholder Discovery
- **Total stakeholders found:** X across Y companies
- **Economic buyers identified:** X
- **Champions identified:** X
- **Full buying committees mapped:** X companies

### Relationship Flags
- **Leads already in CRM:** X (update status, don't create duplicates)
- **Previously contacted leads:** X (check outreach history before re-engaging)
- **Companies with active deals:** X (coordinate with deal owner)
- **Warm intro paths found:** X

### Cost
- **Enrichment tool credits used:** [breakdown by tool]
- **Cost per lead:** [average]

### CSV saved to: [path]

エッジケースへの対応

メールアドレスしかなく、ほかの情報がないリード：

ドメインを抽出 → 企業を検索
LinkedIn／ウェブで「[名前] [企業]」を検索
それでも特定できない場合：理由を添えて enrichment_failed としてフラグを立て、手動での検索を推奨
本当に特定できないリードに有料 API クレジットを浪費しないでください。まずウェブ検索を行います

同じ企業が複数回登場する場合（インバウンドリードが複数）：

企業の調査は一度だけ行い、すべてのリードに適用します
ステークホルダーの特定はリードごとではなく、企業ごとに一度だけ行います
複数リードのシグナルを記録します：「[Company] から 3 人がインバウンドで流入 — 購買委員会が形成されつつある？」

リードが申告した役職と LinkedIn の情報が一致しない場合：

自己申告のフォームデータより LinkedIn の情報を優先します（フォームで役職を誇張する人もいます）
相違点を記録します：「フォームには『VP of Engineering』、LinkedIn には『Senior Engineer』と記載」
適格性の判断には LinkedIn の役職を使用します

企業の社名変更、合併、買収が最近あった場合：

企業のドメインがリダイレクトされる場合は、リダイレクト先を確認します
企業の動きを記録します：「[Company] は [date] に [Parent] に買収されました」
過去の企業ではなく、現在の法人を基準に適格性を判断します

フォームの入力後に担当者が会社を辞めた場合：

LinkedIn にフォーム送信時とは異なる勤務先が記載されている場合は、フラグを立てます
次のように記録します：「[Company] 経由でリードを送信しましたが、[date] 時点では [New Company] に在籍しています」
両社が関連する可能性がある場合は、両社の適格性を判断します

エンリッチメントツールのレート制限または障害：

主要ツールが失敗した場合は、代替手段に切り替えます（ウェブ検索は常に利用可能です）
特定のリードについて両方とも失敗した場合は、enrichment_partial として記録し、次に進みます
1 件のリードの失敗を理由に、バッチ全体を止めないでください

非常に大量の場合（100 件以上のリード）：

まず企業調査をまとめて行います（企業の重複を排除）
Task エージェントを使って人物調査を並列化します（1 バッチあたり 15～20 件）
Tier 4 および未分類のリードについては、ステークホルダーの特定を省略します
有料エンリッチメントツールを実行する前に、費用の見積もりを提示します

個人用メールドメイン：

フォームに企業フィールドがある場合は、メールが個人用でもその情報を使用します
企業情報がない場合は、名前で LinkedIn 検索を試みます
最終手段として、company_unidentified のフラグを立て、人物情報のみをエンリッチします

更新プロトコル

エンリッチメントの完了後、元のシステムを更新します。

CRM が設定されている場合： エンリッチしたデータでリードレコードを作成／更新します。既存のデータを上書きせず、追加するか、不足している情報を補完するだけにします。
重複にフラグを立てる： エンリッチメントの結果、CRM に別のメールアドレスで同じリードがすでに存在すると判明した場合は、2 つ目のレコードを作成せず、重複としてフラグを立てます。

必要なツール

ウェブ検索 — すべての調査における主な代替手段
SixtyFour または Orthogonal — 企業と人物の検索（任意。調査の深度を高めます）
LinkedIn スクレイパー（Apify） — 人物プロフィールのエンリッチメント（任意）
Company-contact-finder — ステークホルダーの特定
CRM アクセス — 関係性の確認（HubSpot、Salesforce、CSV）
Read/Write — CSV の入出力と設定管理
Task ツール — 大量のリードのエンリッチメントを並列化

Markdown 対応

ログインしてコメント

基本情報

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

問題を報告