연락처 데이터가 정확한지 확인하기, CRM 가져오기 전에
파일을 이미 열어 둔 뒤에 나오는 질문: 여기서 "정확하다"가 무엇을 포괄하는지, 이 확인이 실제로 무엇을 검증하는지, 그리고 오직 CRM만 알려 줄 수 있는 것은 무엇인지.
도구 자체
CRM Import Check
CSV 또는 Excel 파일을 드롭하고 HubSpot, Salesforce, Pipedrive 중 하나를 고르면, 가져오기가 무엇을 거부하고, 잘라내고, 조용히 병합할지 확인할 수 있습니다.
파일 확인여섯 가지 추가 질문
무언가를 업로드하기 전에 묻는 아홉 가지 질문 — 도구가 무엇을 하는지, 어떤 CRM을 지원하는지, 파일이 업로드되는지, 그 밖의 것들 — 은 필요한 곳, 즉 도구 페이지 자체에서 답변됩니다. 이 질문들은 이미 자신의 파일을 들여다보며 "정확하다"가 실제로 무엇을 포괄하는지 궁금해질 때 나옵니다.
- CRM으로 가져오기 전에 연락처 데이터가 정확한지 어떻게 확인할 수 있나요?
- "정확하다"는 두 가지 서로 다른 것을 포괄하며, 이 도구는 그중 하나만 해결합니다. 선택한 대상을 기준으로 확인하는 것: 모든 필수 필드가 존재하는지(Salesforce 연락처라면 성, HubSpot 연락처라면 이메일 또는 이름과 성 모두), 모든 이메일 주소와 전화번호가 구조적으로 사용 가능한지, 날짜와 숫자가 대상이 기대하는 형식으로 입력되었는지, 어떤 두 행도 같은 이메일이나 키를 공유하지 않는지 — CRM 자체의 가져오기 기능이 이를 조용히 덮어쓰게 두는 부분입니다 —, 그리고 어떤 값도 대상이 공개한 필드 제한을 넘지 않는지입니다. 확인할 수 없는 것: 소유자, 리드 상태, 기타 드롭다운 값이 실제로 CRM에 설정된 옵션과 일치하는지, 이메일 주소가 실제로 메일을 받을 수 있는지, 기재된 사람이나 회사가 실제인지입니다. 판정이 깔끔하다는 것은 위 확인 항목에서 파일이 거부되거나 잘리거나 조용히 병합되지 않는다는 뜻이지, 그 안의 모든 사실이 참이라는 주장이 아닙니다.
- 드롭다운 목록이나 소유자 값이 제 CRM 설정과 일치하는지 확인할 수 있나요?
- 아니요. 드롭다운 옵션, 리드 상태, 소유자 배정, 기존 레코드와의 연결은 오직 여러분의 CRM 자체 설정 안에만 존재하며, 이 도구는 그곳에 절대 연결하지 않습니다 — 가져오려는 파일만 읽을 뿐, 그 이상은 하지 않습니다. 파일 안에서는 문제없어 보이는 값도 CRM에 일치하는 옵션이 없어서 가져오기 시 거부될 수 있습니다. 이는 CRM 자체나 그 설정을 아는 사람만 확인할 수 있습니다.
- 판정이 "준비 완료"라고 나오면 가져오기가 반드시 성공하나요?
- 이는 선택한 대상을 기준으로 실행된 확인 — 필수 필드, 형식, 파일 내 중복, 필드 길이, 열 매핑 — 을 모든 행이 통과했다는 뜻입니다. CRM이 자체적으로 결정하는 사항에 대한 보장은 아닙니다. 일치하지 않는 드롭다운 값, 더 이상 존재하지 않는 소유자, 파일 내 다른 행이 아니라 CRM에 이미 있는 레코드와의 중복, 가져오기를 실행하는 계정에 없는 권한 등이 그렇습니다. 이런 것들은 파일 확인으로는 볼 수 없는 CRM 내부 상태에 달려 있습니다.
- 정확성 확인은 회사 레코드에도 같은 방식으로 작동하나요?
- 네, 다만 규칙 세트가 다릅니다. 회사 레코드에는 이메일 주소가 필요 없습니다 — HubSpot은 도메인이나 회사명 중 하나만 있어도 받아들이고, Salesforce와 Pipedrive에도 각자의 해당 항목이 있습니다. 형식, 중복, 필드 길이 확인은 같은 방식으로 작동하지만, 연락처 객체가 아니라 회사 객체 자체의 필수 필드와 제한을 기준으로 합니다.
- 이메일 주소가 실재하며 반송되지 않을지 확인하나요?
- 아니요. 주소가 구조적으로 유효한지 — CRM의 가져오기 도구가 기대하는 형식인지 — 를 확인하고, info@나 sales@ 같은 역할 주소, 일회용 도메인, gmial.com처럼 오타일 가능성이 큰 도메인에 표시를 남깁니다. 사서함이 실제로 존재하고 메일을 받는지는 메일 서버에 접속해야 알 수 있는 문제이며, 이 도구는 여러분의 데이터를 실어 보내는 네트워크 요청을 전혀 하지 않습니다 — 전달 가능성을 확인하려면 각 주소를 어딘가로 보내야 하기 때문입니다.
- 제안된 수정을 모두 적용하면 파일이 완전히 정확해지나요?
- 이 도구가 확인할 수 있고 자동으로 바꿔도 되는 문제들 — 잘린 공백, 소문자로 바뀐 이메일, 제거된 잘못된 문자, 비워진 자리표시자 — 로부터는 자유로워집니다. 다만 위에서 말한 의미로 검증되는 것은 아닙니다. 형식을 고친다고 해서 드롭다운 값이 확인되거나, 작동하는 이메일 주소가 만들어지거나, 중복된 두 행 중 어느 쪽이 실제 레코드인지 정해지지는 않습니다. 이런 것들은 여전히 여러분이 내려야 할 판단이며, 변경 이력에 무엇이 바뀌었는지 정확히 나와 있어 그 판단을 내릴 수 있습니다.
실제 파일에서는 이렇게 보입니다
언뜻 보기엔 괜찮아 보였지만 그렇지 않았던 세 가지 사례입니다.
- 두 번 읽어야 알아채는 도메인
입력: 이메일 열에 있는 1,200행 중 한 행, ada@gmial.com.
출력: 해당 행과 올바를 것으로 추정되는 도메인을 알려 주는 경고.
발견: 도구가 gmail.com을 제안하고 두 값을 나란히 보여 줍니다. 수정에 체크하지 않는 한 아무것도 바뀌지 않습니다 — 제안은 사실이 아닙니다.
- 필수 필드를 통과시키려고 입력한 값
입력: 직함 열에 같은 날 추가된 40개 행에 걸쳐 "해당 없음"이 적혀 있음.
출력: 해당 행들과 반복된 값을 알려 주는 경고.
발견: 도구는 실제 직함을 지어내는 대신 자리표시자를 지웁니다 — 사람이 채우거나 비워 두도록 셀을 빈 채로 둡니다.
- 같은 필드를 두고 경쟁하는 두 열
입력: "Company" 열과 "Company Name" 열이 함께 있는 파일.
출력: 두 헤더와 둘 다 일치하는 필드를 알려 주는 경고.
발견: 도구는 둘 중 하나를 제안하고 나머지는 매핑되지 않은 것으로 표시합니다 — 어느 것이 맞는지는 정하지 않습니다. 어느 열을 신뢰하는지는 도구가 알 수 없기 때문입니다.
누가 이걸 묻나
이 질문은 같은 일의 네 가지 다른 지점에서 이미 파일을 손에 쥔 사람들에게서 나옵니다.
처음 가져오기를 하는 사람
회사가 처음 실행하는 CRM 가져오기는 이후 몇 년간 데이터베이스의 형태를 결정합니다. 아무것도 기록되기 전에 "정확하다"를 한 번에 제대로 해내는 편이 나중에 고치는 것보다 저렴합니다.
데이터 품질을 책임지는 사람이 누구든
대부분의 회사에 있는 직함은 아니지만, 결국 누군가는 이 일을 맡게 됩니다. 이는 가져오기 이후의 정리 프로젝트가 아니라 그 이전에 이루어지는 확인입니다.
고객사를 온보딩하는 컨설턴트
매번 다른 고객사의 파일이며, 기댈 수 있는 상시 CRM 연결도 없습니다. 확인할 수 있는 것은 그 파일뿐입니다.
CRM 마이그레이션을 이끄는 사람이 누구든
이전 시스템에서 내보낸 파일은 새 시스템의 규칙을 염두에 두고 작성된 적이 없습니다. 전환 전에 대상 시스템의 규칙에 맞춰 확인하는 것이 이 작업의 핵심입니다.