HubSpot으로 파싱된 데이터 보내기
는 열 매핑 작업입니다
Salesforce의 State of Sales 연구에 따르면 영업 담당자는 주중 시간의 약 28%만 실제 영업에 사용하며, 수동 데이터 입력이 나머지 시간을 차지하는 가장 큰 요인 중 하나입니다(Salesforce). 대부분의 생산성 연구는 이 수치에서 멈춥니다. 입력이 시작되는 지점, 즉 자체적으로 CRM 레코드가 될 기회가 없었던 문서나 이메일까지 거슬러 올라가는 경우는 드뭅니다.
리드 문의, 서명된 계약서, 공급업체 인보이스, 스캔한 신분증은 채워진 HubSpot 행으로 도착하지 않습니다. 이메일 본문 텍스트, PDF 첨부 파일, 또는 휴대폰 사진으로 도착하며, 해당 메시지와 레코드 사이 어딘가에서 사람이 이를 읽고 속성에 입력합니다. 이 글은 그 격차를 해소하는 파이프라인에 관한 것입니다: 파싱된 데이터를 HubSpot으로 자동 전송하는 방법, 각 문서가 속한 HubSpot 개체, 그리고 매핑 작업이 실제로 수행되는 위치에 대해 설명합니다.
핵심 요점
- 문서를 HubSpot에 넣는 작업의 어려운 부분은 통합이 아니라 추출 열의 이름을 무엇으로 지정하느냐입니다.
- 필드 매핑은 일반적으로 파서가 필드 이름을 지정한 후 마지막에 수행되므로
inv_total및ref는 여전히 단일 템플릿 편집으로 깨질 수 있는 사람의 번역이 필요합니다. - 열 이름을 HubSpot 자체 속성에 맞춰 지정하면 가져오기, Zap 또는 API 호출에서 번역할 작업이 남지 않습니다.
HubSpot 자체 도구가 수신 문서로 수행하는 작업
HubSpot의 연결된 받은 편지함은 이메일을 CRM에 가져오지만 문서의 데이터를 레코드 필드에 가져오지는 않습니다. 인보이스나 리드 이메일을 HubSpot의 로깅 주소로 전달하면 메시지가 연락처 또는 거래 타임라인에 저장되고 표시되며, 발신자, 제목, 본문 텍스트와 함께 첨부 파일은 레코드의 첨부 파일 섹션에 보관됩니다. 이는 대화 기록으로 유용합니다. 필터링, 보고, 워크플로우 트리거에 사용할 수 있는 구조화된 속성 데이터는 아닙니다.
HubSpot의 기본 제공 AI는 기능 이름이 암시하는 것보다 범위가 좁습니다. 이메일에서 연락처 세부 정보를 채우는 설정은 이메일 서명을 스캔하고 본문에서 전화번호를 찾을 수 있지만, 이름, 성, 전화번호, 직함, 휴대폰 번호, 팩스, 도시, 주, 국가, 우편번호, 거리 주소 등 고정된 기본 연락처 속성 목록만 작성합니다. 속성이 비어 있고 사용자가 한 번도 편집한 적이 없는 경우에만 속성을 채우며, 연락처를 생성하지 않습니다(HubSpot 지식 베이스). 인보이스 합계, 구매 주문 번호, 계약 기간, 라인 항목 표를 맞춤 속성으로 전환하지 않습니다.
기본 계층은 어떤 대화가 있었는지 기록하며, 문서 자체의 사실은 첨부 파일에 잠겨 있습니다. 인보이스 번호와 PO 참조 번호는 업스트림 단계에서 명명된 필드로 먼저 추출하지 않는 한 HubSpot 속성이 되지 않습니다.
운영 팀은 자신의 말로 이 정확한 격차를 설명합니다. 문서에서 수동 복사를 피하는 방법에 대한 r/hubspot 스레드에서 게시자는 이렇게 명확히 말했습니다: "누군가의 세부 정보가 담긴 문서를 받으면 여전히 직접 읽고 HubSpot에서 필드를 채워야 합니다. 작동은 하지만 시간이 걸리고 오타가 발생합니다. 모두 복사/붙여넣기를 하고 있는 건가요, 아니면 더 나은 워크플로우가 있나요?"
연락처, 거래, 또는 회사: 목적지를 먼저 선택하세요
HubSpot 개체가 필요한 열을 결정하므로, 자동화 도구를 선택하기 전에 개체를 먼저 결정하세요. HubSpot은 레코드 생성 시 소수의 필수 속성을 적용합니다. 연락처는 이메일이 필요하고, 회사는 이름 또는 회사 도메인 이름이 필요하며, 거래는 거래 이름, 파이프라인, 거래 단계가 필요합니다. 중복을 만들지 않고 기존 레코드를 업데이트하려면 행에 고유 식별자도 필요합니다. 연락처의 경우 이메일 주소, 회사의 경우 회사 도메인 이름입니다(HubSpot 지식 베이스). 추출 전에 이를 알면 문서에서 40개 필드를 가져온 후 아무것도 가져올 수 없다는 일반적인 함정을 피할 수 있습니다.
| 문서 | 대상 HubSpot 개체 | 중요한 열 |
|---|---|---|
| 리드 또는 문의 이메일, 문의 양식 | 연락처, 일반적으로 회사 | email, firstname, lastname, phone, company, message |
| 명함 또는 신분증 스캔 | 연락처 | firstname, lastname, jobtitle, company, email, phone |
| 서명된 계약서 또는 제안서 | 거래, 연락처에 연결됨 | dealname, amount, closedate, contract term |
| 공급업체 인보이스 또는 구매 주문서 | 거래 또는 사용자 지정 개체 | invoice number, vendor, amount, due date, PO reference |
실용적인 규칙은 간단합니다. 문서가 시스템에 들어오는 사람이나 회사를 나타내면 연락처 또는 회사를 대상으로 하세요. 거래 또는 상업적 이벤트를 나타내면 거래를 대상으로 하세요. 회사 레코드는 추출을 건너뛸 수 있는 경우가 많습니다. HubSpot이 연락처의 업무 이메일 도메인에서 회사를 자동으로 연결하거나 생성할 수 있고, 도메인을 회사 도메인 이름 속성과 일치시키기 때문입니다(HubSpot 지식 베이스). [email protected]으로 연락처를 푸시하면 별도의 회사 행 없이 acme.com 회사 링크가 자동으로 나타납니다.
반대로 피해야 할 실수는 모든 인바운드 문서를 새 연락처 및 새 거래로 보내는 것입니다. 명세서, 공과금 청구서, 정기 알림은 영업 파이프라인이 아닌 회사 또는 사용자 지정 개체에 속합니다. 문서가 어떤 개체에 속하는지는 프로세스에 대한 판단이며, 어떤 자동화 도구도 이를 대신할 수 없습니다.
매핑은 실제로 열 이름에서 이루어집니다
모든 가이드는 추출 후에 필드 매핑을 다루지만, 그 시점에는 이미 비용이 많이 드는 결정이 내려진 상태입니다. 파서가 vendor_name, inv_total, ref 같은 필드 이름을 넘겨준다면, 사람이 여전히 inv_total이 Deal의 Amount 속성을 의미하고 ref가 맞춤 PO 속성을 의미한다는 것을 직접 파악해야 합니다. 이러한 변환은 모든 워크플로에서 가장 취약한 부분이며, 템플릿이 편집될 때마다 즉시 변경됩니다.
ImageToTable.ai는 맞춤 열 추출로 순서를 뒤집습니다. 알려진 레이아웃의 필드 주위에 상자를 그리는 대신, 원하는 열 이름을 입력하면 AI가 각 문서를 읽어 의미상 해당 이름과 일치하는 값을 찾습니다. 이메일 본문, 스캔된 인보이스, 촬영된 신분증은 모두 레이아웃이 다르지만, 열 이름을 email로 지정하면 AI는 그중 어떤 문서에서도 이메일 주소를 찾습니다. 소스별 템플릿이 필요 없으며, 발신자의 형식이 재설계되어도 추출이 깨지지 않습니다.
열 이름을 직접 선택할 수 있으므로 HubSpot의 내부 속성 이름으로 선택할 수 있습니다. 그렇게 하면 자동화 단계에서 변환할 것이 없어집니다. firstname 열은 Contact 속성 firstname에 매핑됩니다. email 열은 값이자 동시에 중복 제거를 위한 Contact의 고유 식별자입니다. dealname, amount, closedate 열은 HubSpot이 레코드를 생성하는 데 필요한 Deal 필드와 정확히 일치합니다. 이는 추출된 열을 대상 시스템의 가져오기 형식에 맞추는 것과 같은 원칙으로, 재고 시스템 통합 연습에서 조달 측면을 다룹니다.
| 추출 열 이름 | HubSpot 대상 | 중요한 이유 |
|---|---|---|
email | Contact: 이메일 | 생성에 필요하며 업데이트 시 중복 제거 키로 사용됨 |
firstname, lastname | Contact: 이름/성 | 레코드의 기본 신원 정보 |
company | Contact: 회사 이름 | 자동 회사 연결을 지원함 |
dealname | Deal: 거래 이름 | HubSpot이 Deal을 생성하는 데 필요한 세 가지 속성 중 하나 |
amount | Deal: 금액 | 레코드뿐 아니라 파이프라인이 의존하는 값 |
closedate | Deal: 마감일 | 레코드를 올바른 타임라인에 유지함 |
나중에 정리 작업을 줄여 주는 한 가지 주의 사항: 실제로 사용할 데이터만 추출하세요. HubSpot 속성에서 사용되지 않는 열은 결국 수동으로 매핑하거나 삭제해야 하는 열이 됩니다. 구조화된 데이터 입력 워크플로에서도 캡처 측면에서 같은 점을 지적합니다. 추출의 가치는 페이지의 모든 값을 가져오는 것이 아니라 정의된 출력 형태에서 나옵니다.
HubSpot으로 행을 가져오는 세 가지 방법
열이 대상과 일치하면 행을 이동하는 현실적인 방법은 세 가지가 있으며, 주로 누가 트리거하는지와 설정량에 따라 다릅니다.
방법 1: 파일 가져오기. HubSpot의 가져오기 도구는 HubSpot 속성에 해당하는 열이 있는 헤더 행이 포함된 .csv 또는 .xlsx 파일을 허용합니다. 추출 결과가 스프레드시트에 직접 저장되면 시트 자체가 가져오기 파일이 되며, 객체 선택, 헤더 매핑, 고유 식별자 선택만 하면 됩니다. 이 방법은 대량의 과거 데이터나 정기적으로만 동기화하는 팀에 적합합니다. Google Sheets로 추출하면 다운로드 및 형식 변환 단계가 필요 없으며, 스프레드시트 대상으로 전송된 스크린샷 데이터에도 동일한 패턴이 적용됩니다.
방법 2: 노코드 커넥터. Zapier, Make, n8n은 모두 완료된 파싱을 트리거로 처리한 다음 추출된 필드를 HubSpot 작업에 매핑합니다. 중요한 작업은 "생성"이 아니라 "생성 또는 업데이트"입니다. 같은 연락처가 두 번째 문서를 보낼 때마다 새 중복 항목이 생기는 것을 방지하기 때문입니다. Zapier는 이메일을 중복 제거 키로 설정하면 해당 조회를 자동으로 처리합니다. Make는 검색 단계와 업데이트/생성 분기 라우터가 필요합니다. 이 방법은 개발자가 필요 없으며 중간 정도의 볼륨에 가장 적합합니다. 비용은 체인 자체입니다. 세 가지 도구를 연결하면 누군가 워크플로를 편집하는 순간 중단될 수 있습니다.
방법 3: 직접 API 호출. 개발자가 있는 팀의 경우 추출 서비스는 공개 REST API인 v1 API를 제공하며, 문서 업로드를 허용하고 구조화된 JSON을 반환하며 배치가 완료되면 webhook을 트리거할 수 있어 코드가 상태를 폴링할 필요가 없습니다. 그런 다음 JSON은 이메일을 키로 사용하는 연락처 업서트 엔드포인트와 속도 제한을 유지하는 배치 엔드포인트를 사용하여 HubSpot의 CRM API에 게시됩니다. 작업별 미들웨어 수수료가 없고 타사 커넥터에 의존하지 않지만, 접착 코드를 직접 관리해야 합니다. 이 방법은 더 높은 볼륨과 이미 다른 시스템으로 레코드를 라우팅하는 팀에 적합합니다.
캡처 단계는 그 어떤 단계보다 먼저 이루어집니다
세 가지 경로 모두 문서가 이미 대기열에 있다고 가정하며, 이것이 가장 먼저 무너지는 지점입니다. 리드 이메일은 공유 받은 편지함에, 인보이스는 개인 받은 편지함에, ID 스캔본은 문자 메시지로 도착하며, 그 어느 것도 파서 근처에 있지 않습니다. 캡처 레이어가 이러한 소스들을 한곳으로 모으는 역할을 합니다.
ImageToTable.ai는 모든 계정에 전용 받은 편지함 주소를 제공하며, 이것이 이메일 받은 편지함 기능입니다. 공급업체 인보이스, 고객 양식 또는 자신의 이메일을 해당 주소로 전달하면 업로드 페이지 없이 첨부 파일이 처리 대기열에 들어옵니다. 저장된 열 템플릿으로 자동 처리를 켜면 메일이 도착하는 즉시 추출이 시작됩니다. 발신자 화이트리스트는 관련 없는 메일을 대기열에서 걸러내고, 비밀번호로 보호된 PDF는 사전에 저장한 비밀번호로 잠금이 해제되며, 처리는 첨부 파일만, 이메일 본문만, 또는 둘 다 읽도록 설정할 수 있습니다. 일부 공급업체는 첨부 파일 없이 인보이스 데이터를 메시지 본문에 바로 붙여넣기 때문에 마지막 옵션이 중요합니다(이메일 파싱 옵션).
문서가 자신의 받은 편지함이 아니라 다른 사람으로부터 와야 하는 경우, 수집 링크는 공급업체, 고객 또는 현장 작업자가 계정 없이 짧은 코드를 입력한 후 파일을 업로드할 수 있는 공유 가능한 주소입니다. 파일은 동일한 처리 대기열에 들어오므로, 문서 파이프라인은 세 가지 다른 캡처 지점에서 시작해도 동일한 형태의 행을 생성할 수 있으며, 이는 문서 추출 파이프라인 개요에 제시된 것과 동일한 아키텍처입니다.
여전히 사람이 필요한 부분
문서를 추출하고 CRM 레코드를 작성하는 파이프라인은 정확한 레코드를 작성하는 파이프라인과 같지 않으며, 그 차이는 자동화가 단독으로 결정해서는 안 되는 몇 가지 판단에 있습니다.
중복 제거는 정책이지 설정이 아닙니다. 첫 번째 행이 도착하기 전에 고유 식별자를 결정하십시오. 연락처는 이메일, 회사는 회사 도메인을 사용하고, 생성이 아닌 업데이트하는 액션을 사용하십시오. 이 단계가 없는 파이프라인은 Jane이 두 번째로 이메일을 보낼 때 두 번째 Jane Smith를 충실히 생성할 것입니다.
가치가 높거나 모호한 행은 검토 과정을 거쳐야 합니다. 특이한 조건의 계약서나 임계값을 초과하는 인보이스는 파이프라인에 도달하기 전에 육안으로 확인하는 것이 저렴하고, 이후에 수정하는 것은 비용이 많이 듭니다. 손글씨도 같은 범주에 속합니다. 인쇄된 문서는 매우 높은 정확도로 추출되지만, 서두른 서명이나 ID 사진은 AI의 추측을 다시 한번 확인할 가치가 있는 바로 그 지점입니다.
모든 문서가 Deal(거래)인 것은 아닙니다. 위의 개체 결정은 잘 구축된 파이프라인이 판매 파이프라인에 원래 속하지 않았어야 할 반복 명세서를 넘쳐나게 하여 CRM을 조용히 저하시키는 가장 흔한 지점입니다.
동의는 데이터와 별개입니다. 연락처를 HubSpot에 등록한다고 해서 이메일이나 문자를 보낼 권한이 부여되는 것은 아닙니다. 마케팅 이메일과 자동 문자에는 각각의 규칙이 있으며, 추출 레이어는 이에 대해 의도적으로 어떠한 의견도 제시하지 않습니다.
자주 묻는 질문
HubSpot이 이메일이나 PDF 데이터를 맞춤 속성으로 기본 파싱할 수 있나요?
아니요. HubSpot의 내장 AI는 이메일 서명이나 본문의 전화번호에서 기본 연락처 속성의 짧은 목록을 채울 수 있지만, 연락처를 생성하거나 인보이스, 구매 주문서, 계약서를 맞춤 속성으로 읽어들이지는 않습니다. 문서 내용을 속성으로 변환하려면 업스트림에서 추출 단계를 거친 후 파일 가져오기, 노코드 커넥터 또는 API 호출이 필요합니다.
추출된 데이터를 HubSpot에 직접 넣을 수 있나요, 아니면 CSV여야 하나요?
둘 다 가능합니다. 파일 가져오기 경로는 CSV 또는 XLSX를 사용합니다. 직접 경로는 JSON을 HubSpot의 CRM API에 게시하며 개발자가 필요합니다. 연락처 업서트 엔드포인트는 서버 측에서 이메일로 중복 제거를 처리합니다. 노코드 커넥터는 그 사이에 있으며 엔지니어링 지원이 없는 팀이 일반적으로 선택합니다.
파이프라인이 중복 연락처를 생성하지 않도록 하려면 어떻게 해야 하나요?
생성 또는 업데이트 작업을 사용하고 이메일 주소를 고유 식별자로 설정하세요. 파일 가져오기에서 Email 열을 연락처의 고유 식별자에 매핑하면 HubSpot이 새 레코드를 추가하는 대신 기존 레코드와 일치시킵니다. 회사의 경우 동일한 식별자는 회사 도메인 이름입니다.
이메일 본문과 첨부 파일을 모두 읽을 수 있나요?
예. 첨부 파일만, 이메일 본문만, 또는 둘 다 읽도록 처리를 구성할 수 있습니다. 이는 일부 발신자가 PDF를 첨부하고 다른 발신자는 메시지에 세부 정보를 직접 작성하는 현실적인 혼합 상황을 포괄합니다.
개발자가 필요한가요?
가져오기 또는 노코드 경로에는 필요하지 않습니다. 개발자는 직접 API 경로에만 필요하며, 이 경로는 일반적으로 대량 볼륨이거나 추출된 동일한 데이터가 다른 내부 시스템에도 공급되는 경우 선택됩니다.
모든 HubSpot 통합 가이드가 건너뛰는 핵심은 추출 열 이름을 HubSpot 자체 속성 이름으로 지정하는 순간 매핑 문제가 해결된다는 것입니다. 그렇게 하면 Zap, 가져오기 또는 API 호출이 변환 작업 대신 단순 전달이 됩니다.
열이 HubSpot의 객체와 일치하면 파이프라인에는 한 가지 변수만 남습니다: 매주 도착하는 문서의 볼륨과 다양성입니다. 받은 편지함에 이미 존재하는 캡처 지점에서 시작하고, HubSpot이 실제로 사용하는 몇 개의 열을 정의한 다음, 커넥터가 나머지를 처리하도록 하세요. 자신의 리드 이메일이나 인보이스 중 하나로 시도해 보세요 어떤 열이 반환되는지 확인하세요.