inbound-lead-enrichment

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

データが不完全なインバウンドリードを受け取り、不足している情報を補います。企業を調査し、担当者の役職を特定し、同じ企業の他の関係者を見つけ、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 回）

初回の実行時に、情報補完ツールの設定を確立します。clients/<client-name>/config/lead-enrichment.json に保存します。

{
  "enrichment_tools": {
    "company_research": {
      "primary": "web-search | Apollo | Crunchbase | none",
      "secondary": "web-search"
    },
    "person_research": {
      "primary": "Apollo | LinkedIn scraper (Apify) | web-search | none",
      "secondary": "web-search"
    },
    "stakeholder_finding": {
      "primary": "Apollo | LinkedIn Sales Nav export | company-contact-finder | none",
      "secondary": "web-search"
    }
  },
  "crm_source": {
    "tool": "Supabase | 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"
  },
  "cost_controls": {
    "max_apify_credits_per_run": null,
    "max_apollo_credits_per_run": null,
    "skip_paid_enrichment_for_tier_4": true
  }
}

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

---

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

プロセス

各リードについて、判明している情報と不明な情報を一覧にします。

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

• company_name — どの企業に勤めていますか？
• company_domain — 会社ウェブサイトのドメイン
• person_name — 氏名
• person_title — 現在の役職
• person_email — 連絡先メールアドレス（通常、インバウンドの情報に含まれています）

有用なフィールド（可能な場合に入力）：

• company_size — 従業員数またはその範囲
• company_industry — 業界分類
• company_stage — 資金調達段階または事業の成熟度
• company_hq — 本社所在地
• company_description — 事業内容を説明する一文
• 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：企業調査

プロセス

リードリスト内の各企業について調査します（重複を除外し、複数のリードが同じ企業に属する場合も、同じ企業を二度調査しないでください）。

会社名が不明な場合はメールドメインから特定します：

1. メールアドレスからドメインを抽出します（例：[email protected] → acme.com）
2. 個人用メールドメイン（gmail、yahoo、hotmail、outlook など）はスキップします
3. ドメインを検索し、会社名と説明を特定します

会社プロフィールの調査：

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

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

• 詳細： すべての項目を複数の情報源で調査し、情報源間で照合します
• 標準： 必須項目と有用な項目を主な情報源のみで調査します
• 最小限： 会社名、説明、規模のみを調査します

出力

各企業に 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 など）を使用している場合：

1. 名前と、利用可能なその他の情報から会社を特定できるか確認します（例：フォームの入力欄、チャットメッセージ）
2. フォームの送信内容またはチャットで会社名が言及されている場合は、その情報を使用します
3. どうしても特定できない場合は company_unidentified として記録します。名前がわかる場合は、引き続き人物の調査を行います

---

ステップ 3：人物の調査

プロセス

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

名前と会社名から特定します（役職が不明な場合）：

1. LinkedIn で会社に所属する人物を検索します（設定済みのツールまたはウェブ検索を使用）
2. Apollo またはその他の連絡先データベースと照合します
3. 該当する人物が複数いる場合は、メールドメインを使って特定します

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

項目	主な情報源	代替情報源
氏名	入力データ	LinkedIn プロフィール
現在の役職	LinkedIn プロフィール、Apollo	ウェブ検索
職位レベル	役職から推定	LinkedIn プロフィール
部門	役職から推定	LinkedIn プロフィール
在籍期間	LinkedIn プロフィール	Apollo
過去の勤務先	LinkedIn プロフィール	ウェブ検索
学歴	LinkedIn プロフィール	スキップ
LinkedIn URL	Apollo、ウェブ検索	スキップ
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-level の略称（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：関係者の特定

プロセス

リードリストにある各企業について、購買委員会となるほかの関係者を特定します。

重要な理由：

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

見つけるべき人（設定のバイヤーペルソナに基づく）：

1. 経済的購買者 — 予算を承認する人です。通常、該当部門の VP 以上または C レベルです。
2. 推進者 — 社内で導入を推進する可能性が最も高い人です。通常、課題を強く感じているシニア IC またはディレクターです。
3. 技術評価者 — 製品の技術的な適合性を評価する人です。通常、エンジニアリングまたはオペレーション部門の人です。
4. エンドユーザー — 製品を日常的に使用する人です。その賛同を得ることで、販売後の解約を防げます。

企業ごとのプロセス：

1. バイヤーペルソナを使用して、検索する役職を決定します
2. 設定済みのツール（Apollo、LinkedIn、company-contact-finder）で検索します
3. 見つかった各関係者について、氏名、役職、職位、LinkedIn URL、メールアドレス（入手可能な場合）を記録します
4. インバウンドリードとの関係を記録します。同じチームか、同じ部門か、異なる職能かを確認します

調査の深さ：

• 詳細なエンリッチメント（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 / Supabase の people テーブル：

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

確認 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

保存先：clients/<client-name>/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]

---

エッジケースへの対応

メールアドレス以外の情報がないリード：

1. ドメインを抽出 → 企業を検索します
2. LinkedIn／ウェブで「[name] [company]」を検索します
3. それでも特定できない場合：理由を添えて enrichment_failed のフラグを付け、手動検索を推奨します
4. 本当に特定できないリードに、有料 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 のフラグを付け、人物情報のみを拡充します

---

更新プロトコル

拡充が完了したら、ソースシステムを更新します。

1. CRM が設定されている場合： 拡充したデータを使ってリードレコードを作成または更新します。既存のデータを上書きせず、追記するか、不足している項目のみを補完します。
2. Supabase がデータストアの場合： people テーブルと companies テーブルに Upsert します。
3. 重複にフラグを付ける： 拡充の結果、CRM に別のメールアドレスで登録済みのリードが見つかった場合、2 件目のレコードを作成せず、重複としてフラグを付けます。

---

必要なツール

• ウェブ検索 — すべての調査における主な代替手段
• Apollo — 企業と人物の検索（任意。情報の深さを高めます）
• LinkedIn スクレイパー（Apify） — 人物プロフィールの拡充（任意）
• Company-contact-finder — ステークホルダーの特定
• CRM アクセス — 関係性の確認（HubSpot、Salesforce、Supabase）
• Supabase クライアント — パイプライン、アウトリーチ履歴、シグナルの検索
• Read/Write — CSV の入出力と設定管理
• Task ツール — 大量のリードバッチに対する拡充処理の並列化