mcpField
I
inbound-lead-triage

inbound-lead-triage

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

inbound-lead-triage について

入ってきたリードを、緊急度、ICPへの適合度、関連情報に基づいて優先対応キューにまとめるマーケティング向けスキルです。設定済みのソースや貼り付けたデータを確認するチームを対象としています。

主な機能

  1. 01リードの収集と形式統一
  2. 02複数ソース間の重複統合
  3. 03緊急度シグナルによる順位付け
  4. 04ICP適合度の評価
  5. 05企業・人物情報の補足
  6. 06振り分け提案と返信文の作成

活用シーン

  1. 01デモ依頼への対応を優先
  2. 02指定期間のリードを一括確認
  3. 03競合企業と既存顧客を分類
  4. 04適合リードへの連絡文を作成

インストール

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

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

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

同梱ファイルskill.meta.json

詳細

インバウンドリードのトリアージ

指定した期間のインバウンドリードをすべて取得し、流入元と緊急度で分類して、ICP に照らして適格性を評価し、企業や人物のコンテキストを補完したうえで、優先順位付きのアクションキューを作成します。整理されていないフォーム入力の受信箱を、「誰に最初に電話するべきか」がひと目でわかるリストに変えます。

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

次の場合に、この複合機能を読み込みます。

  • ユーザーが「インバウンドリードをトリアージして」「新しいリードを確認して」「デモのリクエストをチェックして」と言った場合
  • ユーザーが任意の期間のインバウンドリードをまとめて処理したい場合
  • ユーザーが「最初に誰にフォローアップすべきですか?」と尋ねた場合
  • スケジュールされたワークフローが定期的なインバウンド確認を実行する場合

アーキテクチャ

[Lead Sources] → Step 1: Collect → Step 2: Classify & Rank → Step 3: Qualify → Step 4: Enrich → Step 5: Route & Respond
                    ↓                    ↓                        ↓                  ↓                    ↓
              Raw lead list      Urgency-ranked list       ICP-scored list    Context-rich list    Action queue + drafts

各ステップには明確な入力/出力の契約があります。ツールはクライアントごとに一度設定し、ハードコードしません。


ステップ 0:設定(クライアントごとに一度)

初回実行時に、リードの流入元と設定を行うようユーザーに尋ねます。現在の作業ディレクトリ、またはユーザーが希望する場所(例:config/inbound-triage.json)に保存します。

{
  "lead_sources": {
    "demo_requests": {
      "source_tool": "HubSpot | Salesforce | Typeform | CSV | other",
      "access_method": "API | CSV export | MCP tool | manual paste",
      "fields_available": ["name", "email", "company", "title", "message"]
    },
    "free_trial_signups": {
      "source_tool": "product database | Stripe | CSV | other",
      "access_method": "API | CSV export | manual paste",
      "fields_available": ["name", "email", "company", "signup_date", "plan"]
    },
    "content_downloads": {
      "source_tool": "HubSpot | Marketo | CSV | other",
      "access_method": "API | CSV export | manual paste",
      "fields_available": ["name", "email", "company", "content_title", "download_date"]
    },
    "webinar_registrations": {
      "source_tool": "Zoom | Luma | CSV | other",
      "access_method": "API | CSV export | manual paste",
      "fields_available": ["name", "email", "company", "webinar_title", "attended"]
    },
    "chatbot_conversations": {
      "source_tool": "Intercom | Drift | Crisp | CSV | other",
      "access_method": "API | CSV export | manual paste",
      "fields_available": ["name", "email", "company", "conversation_summary", "intent"]
    }
  },
  "urgency_overrides": {},
  "response_preferences": {
    "demo_request_sla": "< 1 hour",
    "trial_signup_sla": "< 4 hours",
    "default_sla": "< 24 hours"
  },
  "qualification_prompt_path": "path/to/existing/qualification-prompt.md or null"
}

2 回目以降の実行時: 設定を通知せずに読み込み、セットアップを省略します。

ユーザーが未加工の CSV を提供するか、リードを直接貼り付けた場合: 流入元の設定を省略し、提供されたデータだけを分類します。


ステップ 1:リードを収集する

入力
  • 期間(例:「過去 24 時間」「今週」「月曜日以降」)
  • 確認するリードの流入元(デフォルトでは設定済みのすべての流入元、またはユーザーが指定した流入元)
処理
  1. 指定した期間について、設定済みの各流入元からリードを取得します
  2. 流入元にかかわらず、共通のスキーマに正規化します。
{
  "name": "",
  "email": "",
  "company": "",
  "title": "",           // if available
  "source_type": "",     // demo_request | free_trial | content_download | webinar | chatbot | other
  "source_detail": "",   // which form, which webinar, which content piece
  "timestamp": "",
  "raw_message": "",     // form message, chat transcript, or null
  "raw_fields": {}       // all original fields preserved
}
  1. メールアドレスで重複を除去します。同じ人物が複数の流入元に現れた場合は、すべての流入元タイプを記載した 1 つのレコードに統合します(これはより強いシグナルです)。
出力
  • 流入元の分類を含む、正規化されたリードリスト
  • 重複レポート:「Y 個の流入元から X 件のリードを取得し、Z 件の重複を統合しました」
人による確認ポイント

流入元ごとに収集したリード数を提示します。「これらのリードが見つかりました。トリアージを続けますか?」と尋ねます。


ステップ 2:緊急度で分類して順位付けする

緊急度のランク体系

流入元のタイプと行動シグナルに基づいて、各リードを 4 段階の緊急度に分類します。

Tier 1 — 今すぐ対応(SLA:1 時間未満)

  • デモのリクエスト(明確な購入意向)
  • 見込み客が価格、統合、導入について質問したチャットボットの会話
  • 競合他社の名前に言及しているリード
  • 時期に言及しているリード(「Q2 までに切り替えたい」「今月中に評価中」)
  • 複数の流入元があるリード:2 つ以上の流入元に現れた場合(例:コンテンツをダウンロードし、さらにデモをリクエスト)

Tier 2 — 本日中に対応(SLA:4 時間未満)

  • 無料トライアルへの登録(積極的な評価意向)
  • 製品について質問したチャットボットの会話(価格に関する質問を除く)
  • 実際に参加したウェビナーの参加者(登録しただけの人を除く)
  • ファネル下部のコンテンツのダウンロード(導入事例、ROI 計算ツール、比較ガイド、価格ページ)

Tier 3 — 24 時間以内に対応

  • 参加しなかったウェビナー登録者
  • ファネル中部のコンテンツのダウンロード(ハウツーガイド、業界レポート、テンプレート)
  • 個人用メールドメイン(gmail、yahoo など)で登録した無料トライアルユーザー(商業的な意向が低い)

Tier 4 — 一括対応/ナーチャリング

  • ファネル上部のコンテンツのダウンロード(ブログ記事、一般的な電子書籍、インフォグラフィック)
  • 他のシグナルがない、幅広いテーマや教育的なテーマのウェビナー登録者
  • 企業名または役職が不明で、補完できないリード
シグナルによるランク引き上げ(一段階上げる)
  • 企業が既存の ICP に一致する(適合性の高い業界、規模、ステージとして知られている)
  • 人物の役職が購買ペルソナに合致する
  • 企業がすでにパイプラインに存在する(既存の商談があり、関係性ができている)
  • 人物が過去にエンゲージメントを示している(他のコンテンツをダウンロードした、別のウェビナーに参加した)
  • シグナル複合機能によって企業に関するシグナルが検出されている(資金調達、採用、経営陣の交代)
シグナルによるランク引き下げ(一段階下げる)
  • 企業情報のない個人用メールドメイン
  • ボットのような行動(フォームの入力が 3 秒未満、意味不明な入力欄)
  • 既存顧客(アップセルのシグナルがある場合を除く。Tier は維持し、別途フラグを付ける)
  • 競合他社の従業員(リードではなく、競合インテリジェンスとして別途フラグを付ける)
緊急度の上書き

ユーザーが urgency_overrides にカスタムの緊急度ルールを設定している場合は、デフォルトの分類の後に適用します。

出力
  • 緊急度の階層順に並べ、その階層内ではタイムスタンプ順に並べたリードリスト
  • 各リードに次のタグを付与します:urgency_tier、urgency_reason、signal_boosters[]、signal_dampeners[]

ステップ 3:ICP に基づいて適格性を確認する

プロセス

各リードについて、簡易的な ICP 適格性チェックを実施します。これは lead-qualification 機能の完全な評価ではなく、適合の可能性が高いリードと低いリードを素早く分けるためのものです。

  1. 適格性確認用のプロンプトがある場合(lead-qualification 機能から取得):簡易モードで適用します。重大な不適格要因のみを確認し、詳細な情報収集は省略します
  2. 適格性確認用のプロンプトがない場合: 企業のコンテキストを使って基本的な適合性を確認します:
    • 企業の規模、業界、ステージは ICP におおむね一致していますか?
    • 担当者の役職は購入者またはユーザーのペルソナに当てはまりますか?
    • 明らかな不適格要因はありますか?(対象地域外、対象外の業界、規模が小さすぎる/大きすぎるなど)
適格性カテゴリー
  • 適合度が高い — 企業と担当者が明確に ICP に一致している
  • 適合の可能性が高い — データは一部のみですが、確認できる情報は良好
  • 適合度不明 — 判断に十分なデータがない(情報収集が必要)
  • 適合度が低い — 明らかに ICP の対象外(ただし、インバウンドで問い合わせた理由があるため記録する)
  • フラグ:競合他社 — 既知の競合他社の従業員
  • フラグ:既存顧客 — すでに顧客である(営業ではなく、カスタマーサクセス/アップセルに振り分ける)
出力
  • 各リードに次のタグを付与します:icp_fit、fit_reasoning(1 文)
  • 「適合度が低い」または「フラグ」カテゴリーのリードは、二次リストに分けます

ステップ 4:コンテキストを補足する

プロセス

Tier 1 と Tier 2 のリード(および Tier 3 のうち適合度が高い、または適合の可能性が高いリード)について、対応者がより良い会話をできるようにコンテキストを収集します。

企業情報の補足(企業ごとに実施):

  • その企業は何をしていますか?(1 文)
  • 企業の規模、ステージ、業界
  • 最近のニュースやシグナルはありますか?(シグナルの複合情報がこの企業にフラグを立てていないか確認します)
  • すでに当社のパイプラインに入っていますか?(CRM を確認します — HubSpot、Salesforce、CSV)
  • 過去のエンゲージメント履歴(この企業の他の担当者によるエンゲージメント)

担当者情報の補足:

  • 現在の役職と在職期間
  • LinkedIn の見出し(情報補足ツールで取得できる場合)
  • 当社との過去のエンゲージメント(以前のダウンロード、ウェビナーへの参加、メールへの返信)
  • 共通の知人、または紹介につながる経路(検出できる場合)

エンゲージメントのコンテキスト:

  • どのコンテンツをダウンロードしましたか?(トピックを要約します。対応者がリードの関心を把握できるようにします)
  • デモ申込フォームには何と記入していましたか?(重要なフレーズを引用します)
  • チャットボットとの会話では何が話題になりましたか?(3 文で要約します)
  • どのウェビナーに参加しましたか?(製品とのトピックの関連性)
ツールの柔軟な利用
  • 設定されている情報補足ツールを使用します(SixtyFour または Orthogonal、LinkedIn スクレイパー、ウェブ検索)
  • 情報補足ツールが設定されていない場合は、企業名と担当者名で基本的なウェブ検索を行います
  • Tier 4 のリードについては情報補足を省略します(コストに見合わないため、一括でナーチャリングします)
出力
  • Tier 1~3 の各リードに、企業、担当者、エンゲージメントのコンテキストを含む情報補足ブロックを付けます
  • 情報補足はベストエフォートで行います。不足している項目は記載しますが、プロセスを妨げることはありません

ステップ 5:対応先を決定し、返信を提案する

各リードについて判断すること:

1. 対応アクション:

緊急度ICP 適合度アクション
Tier 1強い/可能性あり直ちに個別にアプローチ — パーソナライズしたメールまたは電話用スクリプトを作成
Tier 1不明直ちにアプローチし、電話で適合性を確認 — ヒアリング用の質問を含むメールを作成
Tier 1低いそれでも返信する(デモを希望しているため)— 丁寧な返信を作成し、電話で適合性を確認
Tier 2強い/可能性あり当日中に個別にアプローチ — パーソナライズした歓迎/フォローアップメールを作成
Tier 2不明当日中にテンプレートでアプローチ — 1行だけ個別の内容を加えたテンプレートを送信
Tier 2低いテンプレートで返信 — 標準の歓迎メッセージを送り、優先対応はしない
Tier 3強い/可能性あり翌日にパーソナライズしてアプローチ — 相手が関心を示した内容に触れたメールを作成
Tier 3不明/低いナーチャリングシーケンスに追加 — 自動配信を行い、手動対応はしない
Tier 4すべてナーチャリングシーケンスのみ — 適切なステップメールキャンペーンにまとめて追加
フラグ:競合他社—競合情報として記録 — 営業アプローチは送らない
フラグ:顧客—CS チームに引き継ぐ — 関連する場合はアップセルの機会としてフラグを設定

2. 返信文の作成(個別にアプローチする Tier 1〜3 のリード向け):

次の内容を含む返信メールを作成します。

  • 相手が行った具体的なアクションに触れる(「…のデモをご希望と拝見しました」「…に関するガイドをダウンロードいただき、ありがとうございます」)
  • 相手が関心を持っていると考えられる内容を、関連する製品機能につなげる
  • エンリッチメントの情報を自然に活用する(不気味な印象を与えないようにし、公開情報のみを参照する)
  • Tier に適した明確な CTA を含める:
    • Tier 1:「今週、短いお電話のお時間をいただける日時はありますか?[具体的な日時候補]」
    • Tier 2:「[関連機能]についてご説明しましょうか?」
    • Tier 3:「ダウンロードいただいた資料に関連する[関連リソース]をまとめました。ご質問があれば、ぜひお話しできればと思います。」

3. 担当者を割り当てる(チーム体制が設定されている場合):

  • クライアント設定に基づき、地域、アカウント規模、またはラウンドロビン方式で振り分ける
  • チーム体制が設定されていない場合:すべてのリードをユーザーに割り当てる

出力形式

メイン:優先順位付きアクションキュー

緊急度の高い順に整理した、明確で実行可能な表として提示します。

## Inbound Lead Triage: [Period]
Generated: [timestamp]

### Summary
- **Total leads:** X from Y sources
- **Tier 1 (respond now):** X leads
- **Tier 2 (respond today):** X leads
- **Tier 3 (respond within 24h):** X leads
- **Tier 4 (nurture):** X leads
- **Flagged:** X competitors, X existing customers

---

### 🔴 Tier 1 — Respond NOW

#### Lead: [Name] — [Company] — [Title]
- **Source:** Demo request via [tool] at [time]
- **Urgency reason:** Explicit demo request + company matches ICP
- **ICP fit:** Strong — [one sentence reasoning]
- **Company:** [one sentence what they do, size, stage]
- **Signal context:** [any signals from other composites]
- **Engagement:** "[quote from form message or chat]"
- **Recommended action:** Personal email + calendar link
- **Draft response:**
  > [ready-to-send email draft]

---

#### Lead: [Name] — [Company] — [Title]
...

---

### 🟡 Tier 2 — Respond TODAY
...

### 🟢 Tier 3 — Respond Within 24h
...

### ⚪ Tier 4 — Add to Nurture
[Batch list — name, company, source, content engaged with. No individual drafts.]

### 🔵 Flagged
- **Competitors:** [list with company name — route to competitive intel]
- **Existing customers:** [list with company name — route to CS]
サブ:CSV エクスポート

すべてのリードとトリアージデータを含むフラットな CSV も作成します。

  • 元のフィールドすべて
  • urgency_tier、urgency_reason、icp_fit、fit_reasoning
  • recommended_action、response_draft
  • company_context、person_context、engagement_context

現在の作業ディレクトリ、またはユーザーが希望する場所(例:leads/inbound-triage-[date].csv)に保存します。


エッジケースへの対応

対象期間にリードがない場合: 確認したソースを記載したうえで、「[period] に新しいインバウンドリードは見つかりませんでした」と報告します。

メールアドレスのないリード: 会社名と氏名があれば、引き続きトリアージします。「直接連絡先なし — 手動での調査が必要」とフラグを設定します。

非常に大規模な企業(エンタープライズ)からのリード: 緊急度を1段階引き上げます。エンタープライズからのインバウンドリードはまれで、価値が高いためです。「エンタープライズリード — 経営幹部レベルでの対応を検討」と記載します。

すでに有効なアウトバウンドシーケンスに含まれているリード: 「すでにアウトバウンドシーケンス[キャンペーン名]に含まれています — 重複を確認してから返信してください」とフラグを設定します。競合する2通目のメッセージは送信しないでください。

重複リード(同一人物、同一ソース、同一期間): 最も新しい登録情報を残します。再度関心を示したことを、シグナルを強める情報として記録します。

データが不完全(会社名なし、役職なし): 利用可能な情報に基づいて分類します。ソースの種類によって緊急度は引き続き決定します。「データが不完全 — アプローチ前にエンリッチメントを検討」と記載します。

件数が多い場合(期間内に100件以上のリード): Tier 3〜4 のリードについては個別のエンリッチメントを省略します。会社名を ICP に照らして一括で適合性を確認し、個別のブリーフの代わりに集計データを作成します。人による対応は Tier 1〜2 のみに集中します。


実施頻度

  • 1日2〜3回(アクティブなチーム向け):SLA の目標を達成するため、数時間ごとに新規リードをトリアージします
  • 毎日午前(最低限):前日および夜間に入ったすべてのリードを朝にトリアージします
  • 毎週(簡易):インバウンド件数、流入元の効果、応答時間の概要統計を確認します

必要なツール

エージェントが以下にアクセスできるようにしてください。

  • CRM/フォームツールへのアクセス — インバウンドリードの取得用(HubSpot、Salesforce、Typeform など)
  • ウェブ検索 — 他のツールが利用できない場合の企業/人物情報の補完用
  • リード情報補完ツール — SixtyFour、Orthogonal、LinkedIn スクレイパーなど(任意、品質向上に役立ちます)
  • メールの下書き作成 — 返信のフレームワークとしてemail-draftingの機能を参照します
  • カレンダーツール — Tier 1 の返信に空き時間枠を含めるためのツール(gcalcli など)

コメント