inbound-lead-qualifier-skill について
HubSpotのデータと補完情報を使い、インバウンドリードの適格性判定、スコアリング、振り分けを行うClaudeスキルです。初回メールはGmailの下書きとして用意し、顧客向けの記述には事前チェックを求めます。
主な機能
- 01HubSpotの連絡先・企業検索
- 02適格性ゲートとリードスコアリング
- 03適格リードの情報補完
- 04ティアと応答期限に応じた振り分け
- 05Gmail下書きとHubSpotフォローアップの提案
活用シーン
- 01デモや価格問い合わせのトリアージ
- 02適合度・意向・緊急度による優先順位付け
- 03既存顧客やパートナー問い合わせの振り分け
- 04確認済みの初回メールの準備
MCP 対応
MCPツールでHubSpot検索、適格性判定、情報補完、製品検索、文面チェック、Gmail下書き作成を行います。顧客向けメールは下書きにとどめ、送信しません。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/inbound-lead-qualifier-skillを入力して読み込まれたか確認します。
同梱ファイルconfig.json
詳細
インバウンドリードの選別とルーティング
インバウンドのシグナルを2分以内に意思決定へつなげます。HubSpotから連絡先を取得し、`qualify_lead`でそれがそもそもリードなのか（顧客、チャネル、製品のみのエンゲージャー、AE所有、抑制対象）とどのティアに属するかを判断させ、不足情報をエンリッチし、ICPフィット + インテント + 緊急度をレスポンスSLA付きの0〜100の優先度にスコアリングし、ルーティングし（Timが対応する、またはデモを予約してAEに引き継ぐ）、初回接触メールをGmailの下書きとして準備します。スピード・トゥ・リード：実行全体はCLAUDE.mdが定める60分のスピード・トゥ・リードの窓の中で完了させる必要があります。 キーワード：`inbound lead`、`qualify inbound`、`score lead`、`demo request`、`form fill`、`triage`<quick_start> トリガー：「このインバウンドリードを選別して」「[company]の[name]をスコアリングしてルーティングして」「インバウンドをトリアージして」。 入力： 名前 + 会社名、またはメールアドレス、または貼り付けられたフォーム通知。任意：ソース、フォームフィールド。
ツールの順序：
hubspot_search_contacts→hubspot_get_contact（Epiphan AI）— レコード、そのコンバージョン、ページビュー、オーナー、ライフサイクル。アカウントについてはhubspot_get_company。qualify_lead（Epiphan AI）— ゲートQ。判定により、何かをスコアリングする前に除外 / STALE AE LEAD / ティアが決まります。enrich_contact（Epiphan AI）— ゲートQを通過した行について、役職、シニアリティ、組織規模、LinkedIn。フォールバック：apollo_people_match（Apolloプラグイン）。- スコアリング（ステージ4）→ ルーティング（ステージ5）。
- フォームが指定した製品に対してゲートS（
search_product_catalog+ Epiphan Knowledgeのsearch）、メールとコール冒頭に対してゲートB（get_writing_styleを1回、文字列ごとにcheck_my_copy）。 - 配信：
[email protected]からGmailのcreate_draft（絶対に送信しない）；HubSpotのノート + タスク、確認優先；AEパス →ae-handoff-brief-skill。 </quick_start>
<house_rules>
顧客対応スキル。出力前に、ゲートを順番に実行します（詳細：/.claude/skills/epiphan-house-rules-skill/reference/gates.md）：
S：製品に関する主張の前にsearch_product_catalog（Epiphan AI）またはEpiphan Knowledgeの検索。 B：すべての顧客対応文字列に対してcheck_my_copy。
Q：候補取得の直後、ティアリング/エンリッチ/下書きの前にqualify_lead。 D：アウトバウンドテキストはGmailの下書きになり、絶対に送信されません。
識別子（オーナーID、ポータル、メール、シート）はそのスキルのreference/identifiers.mdから取得します — ここで再掲しないでください。
ゲート失敗時はreference/self-healing.mdに従い（リトライ、フラグ付きで縮退、Timへのアラート、停止）、/.claude/skill-runs/.jsonlに1行追加します。
</house_rules>
<success_criteria>
- 連絡先がHubSpotで解決されている（または
not in HubSpotとしてフラグが立ち、貼り付けられたフォームからスコアリングされている） -
qualify_leadの判定が記録されている：理由付き除外、STALE AE LEAD、またはティアATL/GRAY/BTL - エンリッチはゲートQを通過したリードに対してのみ試行されている
- 0〜100のスコアが、3つの構成要素とそれを生み出した入力とともに表示されている
- 優先ティア + SLA + ルート（Tim / ae-handoff-brief経由のAE / CSM / チャネル）が一行の理由付きで示されている
- 選別質問（必須 + 推奨）が、業種とフォームに記載されたニーズに結びついている
- メール/冒頭の製品ラインがゲートSを通過している；すべての顧客対応文字列が
check_my_copyを通過している - 初回接触メールがGmailの下書きとして存在する；HubSpotのノート/タスクは提案され、無言で書き込まれていない
- 結果サイドカー + 実行ログの行が書き込まれている </success_criteria>
MCP ツール: mcp__claude_ai_Epiphan_Ai__hubspot_search_contacts（メールアドレスで、なければ名前 + 会社名）→
mcp__claude_ai_Epiphan_Ai__hubspot_get_contact → mcp__claude_ai_Epiphan_Ai__hubspot_get_company。
取得項目: firstname, lastname, email, phone, jobtitle, company, country, lifecyclestage, hs_lead_status, hubspot_owner_id, first_conversion_event_name, recent_conversion_event_name, recent_conversion_date, hs_analytics_num_page_views, hs_analytics_last_url, notes_last_updated, device_count, is_channel、会社の industry, numberofemployees, domain。
- 複数一致 → 最も新しいコンバージョンを持つレコードを採用し、その他はゲート Q 用の重複候補としてリストアップします。
- 一致なし（リードが貼り付けられたフォーム通知として届いた場合）→ フォームデータで続行し、
not in HubSpotとマークし、納品時にhubspot_create_contactを提案します（確認優先）。 - ソースの優先順位: HubSpot 内のフォーム／コンバージョン名が、ユーザーが入力した内容より優先されます。
ステージ 2: ゲート Q — qualify_lead がこれがリードかどうかを判定する
MCP ツール: mcp__claude_ai_Epiphan_Ai__qualify_lead をコンタクトに対して（コンタクトが新規の場合は
会社に対しても）実行します。
| 判定 | ルート（スコアリングを停止） |
|---|---|
既存顧客（device_count >= 1 / ライフサイクルが customer） | インバウンドではなく拡張またはサポート: 担当 AE/CSM に一行メモを添えて引き継ぎます。見込み客への下書きは作成しません。 |
| チャネルパートナー | チャネルマネージャーへ。下書きは作成しません。 |
| 製品のみのエンゲージ（セットアップ／登録フォームであり、デモや価格ではない） | リードではなくサポートチケットです。記録して停止します。 |
| AE が所有、アクティビティ < 90 日 | 所有 AE に通知（Slack／メールメモ）、BDR の下書きは作成しません。 |
| AE が所有、停滞 > 90 日 | STALE AE LEAD — スコアリングし、AE 名とともに Tim に提示します。再エンゲージするかは Tim が判断します。 |
抑制対象（bdr_suppressed / ローカル抑制ファイル） | 停止し、理由を述べます。新たなインバウンドのエンゲージ自体がリリースのシグナルであるため、黙って復活させるのではなく Tim にフラグを立てます。 |
| パス | 続行します。ティア（ATL / GRAY / BTL / NEVER）はこの判定から導出されます。分類は CLAUDE.md にあり、ここでは繰り返しません。 |
非 NA のリード: フラグを立て、スコアリングは行い、identifiers.md に従って地域担当者にルーティングします。
1 回のリトライ後も qualify_lead が利用不可 → [Gate Q unverified] を付けてスコアを生成し、下書きなし、
ルーティングなし、アウトカムは partial、Tim にアラートを送ります。
ステージ 3: 不足している情報をエンリッチする
MCP ツール: mcp__claude_ai_Epiphan_Ai__enrich_contact で役職、シニアリティ、部門、LinkedIn、
組織規模を取得します。フォールバックは mcp__plugin_sales_apollo__apollo_people_match。HubSpot にすでに
役職 + 会社規模がある場合はスキップします。エンリッチの失敗は partial であり、停止には決してなりません — 判明している情報で
スコアリングし、不足している入力をマークします。
ステージ 4: スコアリング
ICP 適合度（0-40） — 汎用 SaaS ではなく Epiphan のバーティカル:
- バーティカル ICP（0-10）: CLAUDE.md のバーティカルスコア（高等教育 90、裁判所／法務 85、政府 80、コーポレート AV 80、ヘルスケア 75、礼拝施設 70、K-12 65）÷ 9 をマッピングします。不明なバーティカル = 4。
- バイヤーティア（0-10）: ATL 10 · GRAY 6 · BTL 3 · NEVER 0（ゲート Q より）。
- 組織適合度（0-10）: 複数ルーム／複数拠点／定期的なキャプチャ需要がフォーム、会社規模、またはサイトで見える = 8-10。単一ルームのホビー用途 = 2-4。
- 予算シグナル（0-10）: 予算の明言または見積もり依頼 10。進行中の助成金／会計年度の言及 7。過去の商談履歴 6。なし 3。
インテント（0-30）: デモ依頼 30 · 価格／見積もり 20 · コンテンツダウンロードまたはウェビナー 10 · 一般的な問い合わせ 5。過去 30 日間に hs_analytics_num_page_views > 5 の場合 +5 を加算（上限 30）。
緊急度（0-30）: 「ASAP」／日付指定のイベント 30 · タイムラインの明言 20 · 「検討中」10 · なし 5。
| 合計 | 優先度 | SLA | デフォルトルート |
|---|---|---|---|
| 80-100 | 🔴 HOT | 1 時間以内に電話 | ATL/GRAY → デモを予約し、ae-handoff-brief-skill で AE に引き継ぎ。BTL → Tim が電話し、EB を見つける |
| 60-79 | 🟡 WARM | 24 時間以内に電話 | Tim が対応。EB とタイムラインが確認できたらデモ |
| 40-59 | 🟢 COOL | まずメール、その後電話 | Tim。Gmail の下書き + Nooks シーケンスの提案 |
| < 40 | ⚪ NURTURE | 電話なし | マーケティングのナーチャリング。コンタクトにメモ |
ステージ 5: ルーティング
- AE パス（HOT + ATL/GRAY、またはフォームが BDR しきい値を超える規模と判定した案件）：ハウスルールスキルの
reference/identifiers.mdにあるテリトリー/ブックで AE を選びます。ここにオーナー ID を書かないでください。ae-handoff-brief-skillで引き継ぎます。オーナー変更は確認優先です（hubspot_update_contact_owner）。 - Tim パス（ゲート Q を通過したその他すべて）：Tim が記録上の BDR です。コールタスクを設定します。
- 既存顧客 / チャネル / サポート：ステージ 2 の表に従います。 「このルートの理由」を 1 行で記載します（ティア、業種、スコア、テリトリー）。
ステージ 6: 顧客向けテキストの前にゲート S と B
- S: フォームまたは冒頭文で言及されたすべての製品について：
search_product_catalog（Epiphan AI）→ Epiphan Knowledge のsearch/fetch。販売終了製品には EOL の確認と現行ラインナップへの誘導を付け、スペックは決して記載しません。ライブ結果がない場合 →[spec unverified]およびpartial。 - 競合製品の記載（Extron、Matrox、Blackmagic、Crestron、vMix、Teradek）：同様に検証するか、省略します。「おそらく X と比較している」は Tim への内部メモとしてのみ許容され、下書きには決して入れません。
- B:
get_writing_styleをセッションごとに 1 回、check_my_copyをメールの件名、本文、コールの冒頭文に対して実行します。ステージング前に修正を適用します。ブランド MCP がダウンしている場合 →[brand check skipped]を付けてステージングします。
ステージ 7: 配信
- Gmail 下書き —
mcp__claude_ai_Gmail__create_draft、差出人[email protected]、宛先はリード。件名Re: <form/demo request> — <Company>。本文：特定のフォームと要望に言及する 1 行、関連する場合のみ検証済みの製品 1 行、調整済みの質問 1 つ、15 分のお願い。send_messageは決して使いません。 - HubSpot — 提案し、確認後に：
hubspot_create_contact_note（「Inbound scored /100 ; route ; reason …」）と SLA 内のコール用にhubspot_create_contact_task。not in HubSpotのリード → まずhubspot_create_contact（確認優先）。 - チャット出力（意思決定カード）：
# Inbound: <Name> — <Company> Source: <form> · Received: <ts>
Score <n>/100 🔴/🟡/🟢/⚪ SLA: <x> Gate Q: pass | STALE AE LEAD (<AE>) | excluded: <reason>
ICP <n>/40 (vertical <v> · tier <t> · org <o> · budget <b>) · Intent <n>/30 · Urgency <n>/30
Route: <Tim | AE <name> via ae-handoff-brief | CSM | channel> — why: <one line>
Must-ask: 1. what is driving this now 2. current setup / what breaks 3. timeline + event
4. who signs Good-to-ask: success picture · budget range · alternatives seen
Call opener (brand-checked): "<2 sentences>"
Draft: <Gmail draft id> HubSpot: note + task proposed (confirm) Flags: [spec unverified] [brand check skipped] [not in HubSpot]
<anti_patterns>
- 連絡先が HubSpot に存在するのに、貼り付けられたテキストだけでスコアリングすること。
- ゲート S を通過していない製品または競合製品の主張を含むコールスクリプトを書くこと。
- このファイルに AE 名/オーナー ID をハードコードすること — それらは identifiers.md が管理します。
- 初回接触メールを下書きではなく送信してしまうこと。
- 抑制チェックをインラインで再実装すること；
qualify_leadがすでに適用しています。 </anti_patterns>
<self_healing>
success = 解決済み、ゲート通過済み、スコアリング済み、ルーティング済み、下書きステージング済み。partial = 意思決定カードは生成されたが、いずれかのステージが低下した（エンリッチメント失敗、ゲート S/B をスキップしてフラグ付け、HubSpot ノートが未確認、ゲート Q 未検証 → 下書きなし）。error = リードをまったく特定できなかった（使用可能な名前/会社/メールがない）。ラダーは ~/.claude/skills/epiphan-house-rules-skill/reference/self-healing.md に従います：1 回再試行 → フラグを付けて低下 → Tim に通知 → 停止。実行ごとに 1 行を ~/.claude/skill-runs/inbound-lead-qualifier-skill.jsonl に追記します。
</self_healing>
結果サイドカーの出力
最終ステップとして、~/.claude/skill-analytics/last-outcome-inbound-lead-qualifier-skill.json に書き込みます：
{"ts":"[UTC ISO8601]","skill":"inbound-lead-qualifier-skill","version":"<frontmatter version>","variant":"default",
"status":"[success|partial|error]","runtime_ms":[estimated ms from start],
"metrics":{"leads_qualified":[n],"hot_leads":[n],"warm_leads":[n],"cool_leads":[n],"nurture":[n],"excluded_by_qualify":[n],"stale_ae_surfaced":[n],"routed_to_ae":[n],"drafts_created":[n],"avg_score":[n]},
"error":null,"session_id":"[YYYY-MM-DD]"}
一部のステージが失敗しても結果が生成された場合は、ステータスに「partial」を使用します。error にはステージ名を指定する必要があります。出力がまったく生成されなかった場合にのみ「error」を使用します。