식별 수준
연락 가능한 사람, 법인·사업체, 상담 기회와 접수 한 건은 다른 개체입니다. 어떤 대상의 중복을 줄이려는지 먼저 정합니다. 고객 개인 정보를 분석 도구에 보내 식별을 대신하지 않고 권한 있는 업무 원장에서 처리합니다.
가정한 분기 규칙
아래는 실제 고객 데이터가 없는 설계 예시입니다. CRM의 고유 제약과 검색 지원, 업무 정책을 확인해 구현해야 합니다.
same technical request key -> return previous processing result
known contact + new business inquiry -> link new inquiry to contact
unknown contact -> create permitted contact and inquiry records
ambiguous match -> review queue, avoid destructive merge
existing open opportunity -> apply documented attach-or-new rule
recorded evidence -> preserve original submission reference
모호한 경우
가정한 예로 공용 이메일을 여러 담당자가 쓰면 같은 주소가 같은 사람을 뜻하지 않을 수 있습니다. 회사가 바뀌거나 연락처가 갱신되는 경우도 있습니다. 자동 연결이 안전한 범위와 사람이 확인할 범위를 나누고 파괴적인 병합은 별도 권한과 근거를 요구하도록 설계합니다.
검수 순서
- 신규·기존·재문의·동시 요청의 가정 데이터를 만듭니다.
- 고객 항목과 문의 항목의 생성 수를 확인합니다.
- 모호한 일치와 변경된 연락처를 시험합니다.
- 연결·보류·병합의 이력을 대조합니다.
두 요청이 동시에 신규 고객을 만들려는 상황도 확인합니다. 기존 조회 뒤 생성 사이의 중복은 실제 저장소와 CRM의 지원 기능으로 다뤄야 합니다. 사용자에게는 접수가 성공했는데 내부 연결만 보류인 경우 어떤 후속 책임이 남는지 분명히 합니다.
완료 기준
정당한 새 문의가 보존되고 기술 재시도의 중복이 줄어야 합니다. 원장 수가 줄었다는 사실만으로 데이터 품질 개선을 주장하지 않습니다. 잘못 묶인 항목을 복구할 참조와 담당자가 있고, 영업 담당자가 현재 연결 규칙을 이해하는 상태가 운영 완료입니다. 정의를 바꾸면 과거 보고의 고객 수와 문의 수를 비교할 때 적용일도 표시합니다.
자주 묻는 질문
- 기존 이메일이 있으면 새 접수를 무시해도 되나요?
- 같은 사람이 다른 서비스를 문의하거나 다시 연락할 수 있습니다. 고객 항목의 중복과 새 상담 기회의 존재를 구분해 필요한 요청이 사라지지 않게 합니다.
- 회사명이 비슷하면 자동으로 합쳐도 되나요?
- 동명이거나 다른 조직일 수 있습니다. 자동 병합의 근거와 되돌리기, 사람의 확인 기준을 정하고 이름 유사도만으로 중요한 업무 기록을 합치지 않습니다.
공식 참고자료와 작성 기준
공식 문서는 도구·검색 기능의 근거이며, 위의 점검 순서와 완료 기준은 현랩의 실무 설계 제안입니다. 예시를 실제 고객의 성과나 검색엔진의 보장으로 해석하지 않습니다.