CRM 중복 고객 병합: 계약·활동 이력을 지키는 검수 기준

CRM 중복 고객 병합은 같은 이름의 행을 지우는 작업이 아니라 두 기록이 같은 고객인지 확인한 뒤 대표 고객과 남길 값을 승인하고, 계약·활동·동의·연동 참조가 올바르게 이어졌는지 검수하는 작업입니다. 잘못 합쳤을 때 원본과 병합 이후 변경을 어디까지 복구할 수 있는지도 실행 전에 정해야 합니다.

영업팀의 엑셀과 CRM에 비슷한 거래처가 각각 등록돼 있다고 가정해 보겠습니다. 한 기록에는 오래된 계약과 세금계산서 수신 담당자가 있고 다른 기록에는 최근 상담과 견적이 있습니다. 이름이 비슷하다고 두 기록을 바로 합치면 실제로는 다른 법인의 계약을 한곳에 섞을 수 있습니다. 반대로 중복을 그대로 두면 영업 담당자가 과거 약속을 놓치고 같은 고객에게 서로 다른 조건을 안내할 수 있습니다.

이 글의 회사명·번호·수량·사건은 모두 가상의 검수 예시입니다. 고객 후보를 어떻게 찾는지보다 사람이 최종 병합을 승인한 뒤 이력과 연결을 보존하는 데 초점을 맞춥니다. 전시회 명함을 수집해 리드를 배정하거나 온톨로지에서 여러 원천의 개체를 연결하는 문제와는 산출물과 실행 권한이 다릅니다. 같은 회사로 보이는 후보를 찾았다는 사실은 한 고객으로 합쳐도 된다는 승인과 같지 않습니다.

먼저 법인, 사업장, 사람, 영업 기회를 구분합니다. 이름이나 대표 전화가 같아도 서로 다른 법인일 수 있고, 한 법인의 여러 사업장은 계약이나 정산 단위가 다를 수 있습니다. 고객과 담당자의 관계 역시 한 회사에만 속한다고 가정하지 않습니다. 확실한 식별자와 실제 계약 당사자, 운영 조직의 확인이 모이지 않으면 병합 후보를 보류하고 기존 기록을 유지합니다.

공식 문서가 보여주는 병합의 제품별 차이#

Microsoft Business Central 공식 문서는 중복 병합에 별도 권한이 필요하며 병합을 실행한 뒤에는 되돌릴 수 없다고 안내합니다. Salesforce의 거래처 병합 안내는 관련 항목을 병합 기록에 연결하는 과정에도 예외가 있고 숨김·읽기 전용 필드는 대표 기록을 따를 수 있다고 설명합니다. 이는 각각의 제품과 안내된 기능에 관한 설명입니다. 모든 CRM이 같은 방식으로 동작하거나 알파카랩스가 해당 제품의 병합 작업을 수행했다는 근거는 아닙니다. 사용하는 제품의 에디션·권한·설정과 현재 연결을 실제 표본으로 확인하세요.

• Microsoft Learn: 중복 기록 병합: 병합 권한과 실행 후 되돌리기 제한에 관한 Business Central 문서입니다.
• Salesforce: 중복 거래처 병합 시 고려사항: 대표 기록, 관련 항목과 숨겨진 필드의 예외를 확인하는 제품별 자료입니다.

병합 후에도 원본과 업무 책임을 찾을 수 있어야 합니다#

실무에서 가장 먼저 필요한 것은 모든 필드를 한 줄로 합치는 화면이 아니라 변경 전후를 설명할 수 있는 병합 명세입니다. 고객 A와 B의 식별자, 대표로 유지한 고객, 각 필드의 이전 값과 최종 선택, 승인자, 실행 시각, 연관 계약과 활동의 이동 결과를 남깁니다. 민감한 값을 로그에 무한 복제하기보다 필요한 증거의 범위와 열람 권한·보관 기간을 따로 정하세요. 담당자 화면에서 볼 수 있는 요약과 제한된 감사 기록은 같은 권한일 필요가 없습니다.

원본 백업과 되돌리기 설계는 구분해야 합니다. 병합 전 자료를 별도로 보관해도 병합 뒤 새로 작성된 상담이나 수정된 계약까지 원래 두 고객으로 정확히 나눌 수 있는 것은 아닙니다. 실행 전 스냅샷에 무엇이 포함되는지, 실행 뒤 새로 만들어진 자료를 누가 어떤 근거로 분리할지 정하고 복구 가능 시한과 승인 책임을 남깁니다. 특정 제품이 병합 취소를 지원하지 않으면 원본에서 필요한 필드와 연결을 복원하는 수동 절차를 사전에 시연해야 합니다.

CRM과 ERP가 서로 다른 고객 코드를 쓴다면 병합 전에 기준 시스템과 각 방향의 동기화 규칙을 확인합니다. CRM의 고객을 합쳤다는 사실이 회계 원장의 거래처 삭제를 승인한 것은 아닙니다. 이전 코드로 입금이나 계약 변경이 도착할 때 대표 고객으로 안내할지, 검토 대기열로 보낼지 업무 책임자가 결정합니다. 이미 처리된 메시지의 재전송은 요청 식별자와 결과를 대조해 중복 연결이나 알림이 생기지 않도록 확인합니다.

영업 담당자가 다른 두 고객을 합치는 경우 담당권 충돌도 중요합니다. 대표 고객의 현재 담당자만 남기더라도 이전 계약의 작성자와 당시 담당자를 바꾸지 않아야 과거 약속을 추적할 수 있습니다. 한 팀에 공개되지 않았던 계약이 병합 후 다른 팀의 화면에서 보일 수 있으므로 변경 전후에 같은 역할 계정으로 접근을 검수합니다. 권한 충돌을 해결하지 못하면 병합 자체를 보류하고 관계만 별도로 표시하는 선택지도 있습니다.

월마감이나 대량 이관이 진행 중이라면 병합 시점도 정해야 합니다. 고객별 합계가 확정된 보고서와 이후의 대표 고객 기준 보고서를 같은 숫자로 단정할 수 없기 때문입니다. 집계 기준 시점과 이전 고객 코드의 처리 방법을 보고서 사용자에게 알려야 합니다. 병합 대기 목록, 실패 목록, 승인 유효기간과 매일 확인할 책임자를 운영 문서에 두면 담당자 교체 뒤에도 예외가 방치되지 않습니다.

기록 전체를 새 시스템으로 옮긴다면 기존 CRM 데이터 이관과 컷오버에서 관계와 전환 범위를 함께 살펴보세요. 고객 병합 이후에도 유지할 영업 기회는 B2B 영업 파이프라인 설계와 연결해 확인할 수 있습니다. 여러 시스템의 동일 개체 판별은 온톨로지 엔터티 해소에서 별도로 다룹니다.

작은 표본으로 먼저 확인할 6가지 검수#

제안사에는 같은 가상 표본을 제공하고 기존 CRM의 설정만으로 되는 부분과 별도 개발이 필요한 부분을 나눠 설명해 달라고 요청합니다. 예를 들어 고객 A와 B는 같은 가상 법인으로 확인하고, C는 상호가 비슷하지만 사업자 정보가 다른 별도 법인으로 둡니다. A에는 계약 2건과 활동 3건, B에는 계약 1건과 활동 2건을 연결합니다. A와 B의 병합 승인 후 계약 3건·활동 5건이 각각의 원본 식별자로 한 번씩 조회되고 C는 변경되지 않아야 합니다.

필드 충돌 표본에서는 A와 B의 담당자와 주소가 다르게 합니다. 검토자가 승인한 값이 대표 고객에 반영되는지, 선택하지 않은 값과 출처는 합의한 보존 범위에서 찾아볼 수 있는지 확인합니다. 두 기록의 수신 설정이 충돌하면 자동 발송부터 중지하고 권한 있는 담당자가 판단하도록 보류하는 시나리오를 시연합니다. 실제 법적 처리 방식은 회사 정책을 따른다는 점도 검수표에 남깁니다.

권한 표본에는 조회만 가능한 영업 사용자, 병합을 요청하는 담당자, 승인자와 운영자를 분리합니다. 조회만 가능한 사용자의 직접 요청과 승인 없는 실행이 거절되는지, 승인자가 볼 수 없는 연결 계약이 있을 때 안내 또는 보류되는지 확인합니다. 권한 오류만 화면에 보이고 실제 연결이 이미 바뀐 상태라면 실패입니다. 고객 행뿐 아니라 계약과 첨부, 알림 이력에도 예상치 못한 변경이 없는지 살펴보세요.

장애 표본으로는 병합 직후 외부 ERP 전달 실패, 같은 요청의 재시도, 승인 직후 원본 변경, 응답 유실을 준비합니다. CRM 처리와 ERP 전달의 상태가 각각 보이고 실패한 부분만 안전하게 재처리할 수 있는지 확인합니다. 같은 요청을 다시 보냈을 때 중복 병합 이력이나 중복 알림이 생기지 않아야 합니다. 연동을 통제할 수 없는 외부 서비스라면 자동 복구를 약속하지 말고 수동 확인 절차를 인수 범위에 적습니다.

마지막으로 잘못된 병합을 가정해 사전 스냅샷에서 고객 두 건과 계약·활동의 연결을 복원하는 훈련을 합니다. 병합 뒤 새로 생긴 활동까지 자동 분리할 수 있는지, 불가능하면 누가 관계를 판단할지 문서로 남깁니다. 운영 인수 자료에는 상태·승인표, 식별자 매핑, 복구 가능한 자료와 보관 기간, 실패 확인 위치, 연락 담당자, 제품별 제한이 포함돼야 합니다. 이 기준을 계약 전에 합의하면 단순한 병합 버튼과 실제 운영 가능한 절차를 구분할 수 있습니다.