인바운드 잠재고객 정보 보강 — 빈칸을 자동으로 채우기 — Claude Skill
Claude Code용 Claude 스킬 · 제공: Gooseworks · 실행: /inbound-lead-enrichment (Claude 내)·업데이트: 2026년 6월 13일
인바운드 잠재고객에 회사, 역할, CRM 맥락을 보강합니다
- 이름, 도메인, 이메일에서 회사 정보를 조사합니다
- 잠재고객의 역할과 직급을 식별합니다
- 같은 회사의 다른 이해관계자를 찾습니다
- 기존 관계가 CRM에 있는지 확인합니다
- 보강된 잠재고객 레코드를 출력합니다
대상
기능
모든 인바운드 데모 요청이 영업 담당자 일정에 들어가기 전에 보강됩니다.
모든 가입을 점수화하고 보강해 영업 담당자가 먼저 후속 조치할 대상을 알 수 있게 합니다.
부분적으로 작성된 양식도 보강해 올바른 다음 단계로 라우팅합니다.
작동 방식
이름, 이메일, 회사가 있는 인바운드 잠재고객을 입력으로 받습니다
웹 출처 전반에서 회사를 조사합니다
연락처의 역할과 직급을 식별합니다
회사 내 다른 이해관계자를 찾습니다
기존 관계를 CRM에서 확인하고 레코드를 업데이트합니다
개선되는 지표
지원 도구
인바운드 잠재고객 정보 보강을(를) 사용해 보시겠어요?
시작 방법을 선택하세요.
이 스킬을 컴퓨터에 로컬로 설치하고 실행합니다.
컴퓨터에서 터미널을 열고 이 명령을 붙여넣으세요:
이 명령은 스킬과 모든 파일을 컴퓨터에 다운로드합니다:
모든 프로젝트에서 사용하려면 끝에 -g를 추가하세요.
Claude Code를 시작한 다음 명령을 입력하세요:
인바운드 잠재고객 정보 보강
불완전한 데이터가 있는 인바운드 잠재고객을 받아 빈칸을 채웁니다. 회사를 조사하고, 사람의 역할을 식별하며, 같은 회사의 다른 이해관계자를 찾고, CRM에서 기존 관계를 확인합니다. 단순 이메일 주소를 전체 잠재고객 프로필로 바꿉니다.
자동 로드 시점
다음 경우 이 복합 스킬을 로드하세요.
- 사용자가 "이 잠재고객을 보강해 줘", "누락 데이터를 채워 줘", "이 인바운드 잠재고객을 조사해 줘"라고 말함
inbound-lead-qualification이 잠재고객을insufficient_data로 표시함inbound-lead-triage가 회사/직함 필드가 누락된 잠재고객을 감지함- 사용자가 이메일 목록 또는 부분 잠재고객 데이터를 갖고 있으며 완전한 프로필이 필요함
구조
[원시 잠재고객] → 1단계: 빈틈 평가 → 2단계: 회사 조사 → 3단계: 인물 조사 → 4단계: 이해관계자 발견 → 5단계: 관계 확인 → 6단계: 취합 및 출력
↓ ↓ ↓ ↓ ↓ ↓
빈틈 목록 회사 프로필 인물 프로필 구매 위원회 CRM/파이프라인 매칭 보강된 잠재고객 레코드
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
}
}
이후 실행: 구성을 조용히 불러옵니다.
1단계: 데이터 빈틈 평가
프로세스
각 잠재고객에 대해 알려진 것과 모르는 것을 목록화합니다.
필수 필드(반드시 채움):
company_name— 어느 회사에서 일하나요?company_domain— 회사 웹사이트 도메인person_name— 전체 이름person_title— 현재 직함person_email— 연락 이메일(보통 인바운드에서 이미 있음)
가치 있는 필드(가능하면 채움):
company_size— 직원 수 또는 범위company_industry— 산업 분류company_stage— 투자 단계 또는 성숙도company_hq— 본사 위치company_description— 회사가 하는 일 한 문장person_seniority— IC, Manager, Director, VP, C-Level, Founderperson_department— Engineering, Sales, Marketing 등person_linkedin— LinkedIn 프로필 URLperson_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 등)
- 도메인으로 회사명과 설명을 조회합니다
회사 프로필 조사:
| 필드 | 주요 출처 | 대체 출처 |
|---|---|---|
| 회사명 | 도메인 조회 | 웹 검색 |
| 설명 | 회사 웹사이트(홈페이지, 회사 소개) | 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 등)을 사용한 경우:
- 이름 + 다른 사용 가능한 데이터로 회사를 식별할 수 있는지 확인합니다(예: 양식 필드, 채팅 메시지)
- 양식 제출 또는 채팅에 회사가 언급되어 있으면 그것을 사용합니다
- 정말 알 수 없으면
company_unidentified로 표시합니다. 이름이 있으면 인물 조사는 계속 진행합니다
3단계: 인물 조사
프로세스
각 잠재고객에 대해 인물 프로필을 만듭니다.
이름 + 회사에서 시작(직함이 없을 때):
- 구성된 도구 또는 웹 검색으로 회사의 해당 인물을 LinkedIn에서 검색합니다
- Apollo 또는 다른 연락처 데이터베이스와 교차 확인합니다
- 일치 항목이 여러 개면 이메일 도메인으로 구분합니다
인물 프로필 조사:
| 필드 | 주요 출처 | 대체 출처 |
|---|---|---|
| 전체 이름 | 입력 데이터 | 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 abbreviations(CTO, CMO, CRO, CFO), President →
C_Level - 다음이 포함된 직함: Founder, Co-founder, Owner →
Founder
회사 규모에 따라 조정:
- 직원 20명 미만 회사: 직급을 한 단계 올려 봅니다("Manager"가 Director 수준 범위를 가질 수 있음)
- 직원 5000명 초과 회사: 직급을 한 단계 낮춰 봅니다("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-level입니다.
- 내부 지지자 — 내부 도입을 밀어붙일 가능성이 가장 큰 사람. 보통 고통을 느끼는 선임 IC 또는 Director입니다.
- 기술 평가자 — 제품의 기술 적합도를 평가할 사람. 보통 엔지니어링 또는 운영 담당입니다.
- 최종 사용자 — 제품을 매일 사용할 사람. 이들의 동의는 판매 후 이탈을 줄입니다.
회사별 프로세스:
- 구매자 페르소나를 사용해 검색할 역할을 결정합니다
- 구성된 도구(Apollo, 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 / 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단계: 취합 및 출력
보강된 잠재고객 레코드
모든 조사를 잠재고객별 하나의 보강 레코드로 병합합니다.
{
"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
보조: 정보 보강 보고서
## 잠재고객 정보 보강 보고서: [Date]
### 요약
- **보강된 전체 잠재고객:** X
- **심층 보강:** X건(Tier 1-2)
- **표준 보강:** X건(Tier 3)
- **최소 보강:** X건(Tier 4)
### 데이터 품질
- **완전 보강**(필수 + 가치 있는 필드 모두): X건
- **대부분 보강**(필수 모두, 가치 있는 필드 일부): X건
- **부분 보강**(일부 필수 필드 여전히 누락): X건
- **보강 불가**(시작 데이터 부족): X건
### 회사 조사
- **조사한 고유 회사:** X
- **이미 CRM에 있는 회사:** X
- **활성 거래가 있는 회사:** X(거래 담당자에게 표시)
- **신호 이력이 있는 회사:** X
### 이해관계자 발견
- **발견한 전체 이해관계자:** Y개 회사의 X명
- **식별된 경제적 구매자:** X
- **식별된 내부 지지자:** X
- **전체 구매 위원회가 매핑된 회사:** X
### 관계 플래그
- **이미 CRM에 있는 잠재고객:** X(상태 업데이트, 중복 생성 금지)
- **이전에 연락한 잠재고객:** X(다시 연락하기 전에 연락 이력 확인)
- **활성 거래가 있는 회사:** X(거래 담당자와 조율)
- **따뜻한 소개 경로 발견:** X
### 비용
- **사용한 정보 보강 도구 크레딧:** [도구별 분해]
- **잠재고객당 비용:** [평균]
### CSV 저장 위치: [path]
예외 상황 처리
이메일만 있고 아무 정보도 없는 잠재고객:
- 도메인 추출 → 회사 조회
- LinkedIn/웹에서 "[name] [company]" 검색
- 그래도 식별할 수 없으면 이유와 함께
enrichment_failed로 표시하고 수동 조회를 권장합니다 - 정말 식별할 수 없는 잠재고객에 유료 API 크레딧을 낭비하지 마세요. 먼저 웹 검색을 사용합니다
같은 회사가 여러 번 나타남(여러 인바운드 잠재고객):
- 회사는 한 번만 조사하고 모든 잠재고객에 적용합니다
- 이해관계자 발견은 잠재고객별이 아니라 회사별로 한 번 실행합니다
- 다중 잠재고객 신호를 기록합니다. "[Company]에서 3명이 인바운드로 들어옴 — 구매 위원회가 형성 중인가?"
잠재고객이 LinkedIn과 맞지 않는 직함을 주장함:
- 자체 입력 양식 데이터보다 LinkedIn을 신뢰합니다(사람들이 양식에서 직함을 부풀리는 경우가 있음)
- 불일치를 기록합니다. "양식에는 'VP of Engineering', LinkedIn에는 'Senior Engineer'"
- 적격 판정 목적에는 LinkedIn 직함을 사용합니다
회사가 최근 이름을 바꾸었거나, 합병되었거나, 인수됨:
- 회사 도메인이 리디렉션되면 리디렉션을 따라갑니다
- 기업 활동을 기록합니다. "[Company]는 [date]에 [Parent]에 인수됨"
- 과거 법인이 아니라 현재 법인 기준으로 적격 판정합니다
양식을 작성한 뒤 사람이 회사를 떠남:
- LinkedIn이 양식 제출과 다른 회사를 보여 주면 표시합니다
- 기록: "잠재고객은 [Company]를 통해 제출했지만 [date] 기준 [New Company]의 [직함]입니다"
- 두 회사 모두 잠재적으로 관련이 있으면 둘 다 적격 판정합니다
정보 보강 도구 속도 제한 또는 실패:
- 주요 도구가 실패하면 보조 도구로 전환합니다(웹 검색은 항상 사용 가능)
- 특정 잠재고객에서 둘 다 실패하면
enrichment_partial로 표시하고 계속 진행합니다 - 한 잠재고객 실패 때문에 전체 배치를 막지 마세요
매우 큰 규모(잠재고객 100명 이상):
- 회사 조사를 먼저 배치 처리합니다(회사 중복 제거)
- Task 에이전트로 인물 조사를 병렬화합니다(배치당 잠재고객 15-20명)
- Tier 4 및 티어 없는 잠재고객은 이해관계자 발견을 건너뜁니다
- 유료 정보 보강 도구를 실행하기 전에 비용 추정을 제공합니다
개인 이메일 도메인:
- 양식에 회사 필드가 있으면 이메일이 개인 도메인이어도 그것을 사용합니다
- 회사 정보가 없으면 이름으로 LinkedIn 검색을 시도합니다
- 마지막 수단:
company_unidentified로 표시하고 인물만 보강합니다
업데이트 프로토콜
정보 보강이 완료되면 원본 시스템을 업데이트합니다.
- CRM이 구성된 경우: 보강 데이터로 잠재고객 레코드를 생성/업데이트합니다. 기존 데이터를 덮어쓰지 말고 추가하거나 빈칸만 채웁니다.
- Supabase가 데이터 저장소인 경우:
people및companies테이블에 upsert합니다. - 중복 표시: 정보 보강 결과 다른 이메일로 이미 CRM에 있는 잠재고객임이 드러나면 두 번째 레코드를 만들지 말고 중복으로 표시합니다.
필요한 도구
- 웹 검색 — 모든 조사의 기본 대체 수단
- Apollo — 회사 + 인물 조회(선택, 깊이 향상)
- LinkedIn scraper (Apify) — 인물 프로필 보강(선택)
- Company-contact-finder — 이해관계자 발견
- CRM 접근 — 관계 확인(HubSpot, Salesforce, Supabase)
- Supabase client — 파이프라인, 연락 이력, 신호 조회
- Read/Write — CSV 입출력과 구성 관리
- Task tool — 큰 잠재고객 배치의 정보 보강 병렬화