대리점 CRM 구축: 본사·대리점 고객 중복과 영업 권한 설계
대리점 CRM 구축에서 본사와 대리점의 고객 정보, 영업 기회, 견적 권한을 나누는 기준을 정리합니다. 같은 고객을 여러 대리점이 등록할 때의 중복 판정, 영업권 분쟁, 담당자 변경과 ERP 연동 시나리오로 개발업체 제안을 비교하고 검수할 수 있습니다.
이 글을 쓴 알파카랩스카카오·네이버·쿠팡 출신, 재하청 0%, 대기업·공공기관 등 18개사+ 레퍼런스
대리점 CRM 구축의 핵심은 고객 목록을 한곳에 모으는 것이 아니라, 같은 고객을 여러 판매 조직이 만날 때 누가 어떤 정보와 영업 기회를 다룰 수 있는지 정하는 것입니다. 고객의 동일성, 영업권 배정, 정보 열람 권한은 서로 다른 규칙으로 설계해야 합니다.
본사는 전체 파이프라인을 보고 싶고 대리점은 자신의 고객과 견적을 보호하고 싶습니다. 이때 전체 공유와 완전 분리 중 하나만 선택하면 문제가 남습니다. 전체 공유는 다른 대리점의 영업 정보를 노출할 수 있고, 완전 분리는 같은 고객에 대한 중복 제안과 본사 지원 업무를 놓칠 수 있습니다.
이 글은 대리점을 운영하는 제조·유통 기업이 CRM 개발업체에 요구할 설계와 검수 자료를 다룹니다. 아래 정책과 시나리오는 발주용 예시이며 특정 고객사의 구축 실적이나 모든 업종에 적용되는 표준을 뜻하지 않습니다. 일반적인 영업 단계는 B2B 영업 CRM 설계와 함께 보면 좋습니다.
고객 중복과 영업권을 왜 나눠야 할까요?#
고객 중복 판정은 두 기록이 같은 조직을 가리키는지 확인하는 일입니다. 반면 영업권은 특정 제품이나 프로젝트를 누가 담당할지 정하는 업무 결정입니다. 고객 기록을 연결했다고 해서 두 대리점의 견적과 영업 메모까지 공유할 이유는 없습니다.
예를 들어 A대리점은 한 제조사의 공장에 장비를 제안하고, B대리점은 같은 제조사의 연구소에 다른 제품을 제안할 수 있습니다. 법인 이름이 같다는 이유로 한쪽의 기회를 지우면 실제 영업 구조가 사라집니다. 고객 마스터 아래에 사업장·부서·담당자를 두고, 영업 기회에는 제품·프로젝트·판매 조직을 따로 연결하는 식으로 검토하세요.
| 판단 | 확인할 질문 | 남길 데이터 | 자동 처리의 경계 |
|---|---|---|---|
| 같은 고객인가 | 법인과 사업장이 같은가 | 원본 코드·연결 근거 | 이름 유사도만으로 병합하지 않기 |
| 같은 기회인가 | 제품·현장·시기가 같은가 | 기회 ID·대상 제품·유효기간 | 고객이 같아도 별도 기회 가능 |
| 누가 담당하는가 | 누가 어떤 근거로 승인했나 | 신청·승인·예외 사유 | 등록과 영업권 확정 구분 |
| 무엇을 볼 수 있나 | 메모·가격·첨부도 공유하나 | 조직 관계·행위별 권한 | 고객 연결과 정보 공개 분리 |
중복을 발견했을 때 기존 고객명을 통째로 알려주는 기능도 주의해야 합니다. 대리점에는 본사 검토가 필요한 신청이라는 상태만 보여주고, 다른 판매 조직의 이름이나 접촉 이력을 감추는 정책을 선택할 수 있습니다. 어떤 정보까지 안내할지는 영업 책임자가 먼저 결정해야 합니다.
고객 식별 키는 무엇으로 잡아야 할까요?#
회사명 한 칸에 의존하지 말고 고객 마스터 ID와 원천 시스템의 코드를 분리하세요. 상호 변경, 지점 추가와 담당자 이동이 있어도 같은 고객의 이력을 추적할 수 있어야 합니다. 사업자등록번호나 도메인은 유용한 확인 자료지만 그것만으로 모든 관계를 확정하는 규칙은 피하는 편이 좋습니다.
실제 자료에는 약칭, 띄어쓰기, 해외 법인, 공용 이메일과 개인 이메일이 섞여 있습니다. 입력 단계에서 같은 값을 정규화하는 규칙과, 후보를 사람에게 보여주는 검토 절차를 나누세요. 병합했다면 살아남는 값, 충돌한 담당자, 첨부와 활동 이력의 이동 결과도 기록해야 합니다.
HubSpot의 중복 제거 공식 안내는 연락처 이메일, 회사 도메인과 레코드 ID 등 식별 기준을 설명합니다. 이는 제품의 동작을 확인하는 자료이며, 우리 회사의 대리점 영업권 정책까지 결정해 주는 규칙은 아닙니다. 설정형 CRM도 데이터 생성·수입·연동 경로별 동작을 실제 표본으로 확인해야 합니다.
본사와 대리점의 권한은 어떻게 나눌까요?#
직급 이름만 나열하기보다 사용자와 판매 조직의 관계, 담당 기회, 수행하려는 작업을 함께 정의하세요. 조회 가능하다고 다운로드·가격 수정·담당자 변경까지 허용되는 것은 아닙니다. 고객 목록뿐 아니라 검색 결과, 알림과 엑셀 내보내기도 같은 기준으로 검수해야 합니다.
| 대상 | 기본 열람 범위 예시 | 별도 승인할 작업 | 검수할 누락 경로 |
|---|---|---|---|
| 대리점 영업 직원 | 소속 대리점의 배정 기회 | 견적 할인·고객 병합 | 검색·파일·내보내기 |
| 대리점 관리자 | 소속 조직의 기회와 담당자 | 다른 대리점으로 인계 | 퇴사자 계정·예약 알림 |
| 본사 채널 담당 | 배정된 채널의 신청과 지원 이력 | 영업권 충돌 조정 | 대리점 전용 메모 노출 |
| 본사 운영 관리자 | 운영에 필요한 설정과 감사 이력 | 대량 반출·권한 변경 | 지원용 임시 접근 만료 |
이 표는 정책 예시입니다. 본사가 모든 가격을 볼 수 있는지, 대리점 자체 메모를 본사에 공개하는지, 고객이 판매 채널을 바꿀 때 무엇을 이전하는지는 계약과 업무 방식에 따라 달라집니다. 합의되지 않은 항목을 개발사가 임의의 관리자 권한으로 덮지 않도록 예외 목록을 남기세요.
OWASP 접근 제어 지침은 최소 권한, 기본 거부와 요청별 권한 검증을 권고합니다. 화면에서 메뉴를 숨기는 것과 서버가 고객·기회·파일 접근을 허용하는 것은 다릅니다. 후보 업체에는 권한 없는 표본 계정의 요청을 서버에서 막는 검수 방법을 물어보세요.
영업 기회 등록 분쟁은 상태로 관리하세요#
기회 등록은 신청, 검토, 승인, 보완, 만료와 이관으로 나눌 수 있습니다. 신청 시각 하나를 영구적인 소유권으로 취급하지 말고, 승인 근거와 유효기간을 남기세요. 만료 전에 활동 증거를 제출하면 연장하는지, 고객 요청으로 담당을 바꾸면 기존 제안서를 누가 보유하는지도 정해야 합니다.
같은 기회가 접수됐다는 이유로 나중 신청을 즉시 삭제하면 분쟁 자료까지 잃을 수 있습니다. 원본 신청은 보존하고 검토 결과를 연결하는 방식이 실무에서 설명하기 쉽습니다. 분쟁을 처리한 사람, 결정 시점, 적용 정책 버전과 이의 제기 경로를 함께 남기면 담당자가 바뀌어도 맥락을 이어갈 수 있습니다.
본사 직판과 대리점 영업이 동시에 진행되는 경우도 별도 표본으로 넣으세요. 공동 영업은 두 조직이 모든 데이터를 공유하는 상태와 다릅니다. 기술 지원 메모만 공유하고 할인율은 제한하는 등 협업 범위를 구분할 수 있어야 합니다.
CRM 개발업체에 이 다섯 장면을 시연 요청하세요#
- 다른 표기로 같은 고객 등록: 약칭과 정식 상호로 신청해 중복 후보가 잡히는지, 다른 대리점의 영업 메모는 숨겨지는지 확인합니다.
- 같은 고객의 다른 제품 기회: 고객 마스터는 연결하되 제품과 현장이 다른 기회를 독립적으로 유지하는지 봅니다.
- 본사 직판과 채널 충돌: 자동 확정 대신 검토 상태로 이동하고 담당자가 근거를 남겨 조정하는지 확인합니다.
- 직원 퇴사와 후임 인계: 계정을 차단한 뒤 진행 기회만 새 담당자에게 넘기고 과거 작성자·승인 이력은 유지하는지 봅니다.
- 다른 대리점의 파일 접근: 허용된 시험 환경에서 다른 조직의 견적·첨부·내보내기가 차단되고 민감한 정보가 오류 메시지에도 나오지 않는지 확인합니다.
업체별로 다른 데모를 보면 비교가 어렵습니다. 가상 고객과 대리점 두 곳, 본사 계정, 충돌 기회와 퇴사자를 같은 표본으로 제공하세요. 결과는 지원, 설정 필요, 추가 개발과 미지원으로 구분하고, 추가 개발에는 산출물·비용 가정·시험 책임자를 붙이면 됩니다. 점수 합계보다 타 대리점 정보 노출 같은 보류 조건을 먼저 정하는 것이 중요합니다.
ERP 연동과 운영 인수에서 남겨야 할 것은 무엇일까요?#
CRM의 고객과 ERP의 청구 거래처가 항상 같은 단위는 아닙니다. 판매 대리점, 최종 사용자, 납품처와 세금계산서 발행 대상의 관계를 먼저 구분하세요. 어느 시스템이 고객명·주소·여신·단가를 확정하는지 정하지 않으면 연동할 때마다 다른 값으로 덮어쓸 수 있습니다.
견적 승인 뒤 ERP 주문을 만드는 구간에는 원본 기회·견적 버전과 외부 주문 ID를 연결합니다. 실패한 요청을 다시 보내더라도 같은 주문이 중복 생성되지 않아야 하며, 재처리 대기와 수동 확인이 필요한 상태를 운영자가 구분할 수 있어야 합니다. 기회가 취소됐을 때 ERP 주문까지 자동 취소할지는 별도 승인 정책으로 다룹니다.
인수 자료에는 권한표, 고객 식별·병합 규칙, 기회 상태도, 원천 코드 매핑, 재처리 목록과 퇴사·대리점 계약 종료 절차를 포함하세요. 파일 반출과 삭제 범위, 개인정보 처리와 기록 보존은 실제 계약과 적용 법령을 별도로 검토해야 합니다. 시스템 기능이 영업권 계약이나 법률 검토를 대신하지는 않습니다.
핵심 요약
- ✓고객의 동일성, 기회 담당과 정보 열람 권한을 별도 규칙으로 나눕니다.
- ✓제품·사업장·기간이 다른 영업 기회를 고객 중복과 혼동하지 않습니다.
- ✓동일한 가상 데이터로 충돌·퇴사·파일 접근·재처리 장면을 시연합니다.
- ✓고객 코드, 권한표와 운영 절차를 새 담당자가 재현할 수 있게 인수합니다.
자주 묻는 질문
도입 방식은 맞춤 CRM과 Salesforce·HubSpot 비교, 기존 자료 이전은 CRM 마이그레이션 가이드에서 이어서 확인할 수 있습니다. 자사의 실제 제공 범위는 아래 서비스 안내와 구분해 검토하세요.