신규 사업자 영업 리드 수집·관리 시스템 구축

CHALLENGE

클라이언트가 필요로 한 이유

클라이언트는 신규 사업자 기본 정보를 확보한 뒤 연락처를 다시 검색하고, 영업 가능한 목록으로 정리하는 일을 반복하고 있었습니다. 공공 정보와 포털 검색 결과의 출처가 달라 같은 사업자가 중복되거나 연락처를 찾지 못한 이유가 남지 않는 문제가 있었습니다.

필요했던 것은 단순 수집기가 아니라 수집 결과가 실제 영업 활동으로 이어지는 운영 흐름이었습니다. 기본 정보와 연락처를 안전하게 병합하고, 실패 이유와 통화 결과를 남겨 다음 접촉 대상을 좁힐 수 있어야 했습니다.

신규 개업한 소상공인을 대상으로 아웃바운드 영업을 하는 고객사는 영업 리드를 수작업으로 확보하고 있었습니다. 공개된 신규 사업자 정보에는 상호와 사업장 주소, 업종, 등록일이 담기지만 사업장 전화번호는 포함되지 않아, 목록을 확보한 뒤 연락처를 따로 찾는 작업이 이어졌습니다.

공공데이터에는 사업장 전화번호가 포함되지 않아, 목록을 확보해도 영업에 착수하려면 연락처를 별도로 찾아야 하는 구조

요건으로 제시된 핵심 문제

구축의 과제는 출처가 다른 두 데이터를 하나의 레코드로 합치는 규칙과, 매칭에 실패한 건을 어떻게 남길지를 먼저 확정하는 것이었습니다.

클라이언트 요청사항과 기획 방향

SOLUTION

시온랩은 기본 정보 수집과 연락처 매칭을 하나의 수집 작업으로 묶고, 그 결과를 영업팀이 조회하고 내보내는 화면까지 끊기지 않게 연결하는 구조로 설계했습니다. 여기에 더해, 목록이 밖으로 나간 뒤 결과가 돌아오지 않는다는 점을 확장 과제로 제안했습니다.

시스템 구조

수집은 기본 정보를 먼저 확정한 뒤 연락처를 덧붙이는 2단 구조입니다. 연락처를 찾지 못해도 사업자 레코드는 남으며, 실패 사유가 함께 기록되어 다음 수집에서 재시도 대상이 됩니다.

흐름 1: 수집과 연락처 매칭

한 번의 수집 실행은 신규 사업자를 추가하는 단계와 연락처를 채우는 단계로 나뉘고, 각 단계의 결과가 작업 단위로 집계됩니다.

흐름 2: 조회와 권한 분리

발주 요건은 관리자 대시보드 하나였으나, 데이터를 쓰는 사람과 수집을 제어하는 사람이 다르다는 점을 반영해 역할을 둘로 나누는 안을 제안했습니다. 영업 담당은 목록을 조회하고 내보내며, 수집 실행과 데이터 수정은 관리자만 수행합니다.

흐름 3: 수집 이후의 영업 활용 (확장 제안)

발주 요건이 정의한 시스템의 출력 경계는 엑셀 내보내기까지였습니다. 그러나 검수 기준이 연락처 매칭률인 이상, 목록이 밖으로 나간 뒤 무엇이 일어났는지 시스템이 알지 못하면 다음 수집의 우선순위를 정할 근거가 없습니다. 통화 결과를 시스템으로 되돌려 받는 구간을 확장 범위로 제안했습니다.

같은 사업자에 두 종류의 상태를 둡니다. 하나는 시스템이 수집으로 갱신하는 연락처 상태이고, 다른 하나는 사람이 통화로 갱신하는 영업 상태입니다. 두 상태를 분리해 두어야 연락처 재매칭이 통화 이력을 지우지 않습니다.

데이터 구조

사업자를 중심에 두고, 연락처와 매칭 상태를 사업자 레코드에 함께 둡니다. 통화 기록만 별도 테이블로 분리하고, 수집 작업은 회차별 집계를 따로 남깁니다.

• 사업자는 사업자등록번호로 유일하게 식별: 같은 사업장이 여러 회차에서 다시 수집되어도 새 레코드를 만들지 않고 기존 레코드를 갱신합니다.
• 연락처는 별도 이력 테이블을 두지 않는다: 최종 연락처와 매칭 상태, 실패 사유를 사업자 레코드에 함께 두어, 목록 조회 한 번으로 영업 가능 여부를 판단합니다.
• 연락처 상태는 네 가지로 고정: 대기, 진행 중, 매칭 완료, 매칭 실패로 두어, 아직 시도하지 않은 건과 시도했으나 실패한 건을 구분합니다.
• 실패는 사유로 나눈다: 검색 결과 없음, 연락처 미표기, 동명 사업장으로 식별 불가를 각각 다르게 기록해, 재시도로 해결되는 건과 그렇지 않은 건을 분리합니다.
• 수집 상태와 영업 상태는 같은 레코드에 두되 서로 침범하지 않는다: 수집이 갱신하는 값과 통화가 갱신하는 값을 분리해, 재매칭이 담당자·통화 횟수·영업 단계를 덮어쓰지 않도록 규칙을 고정했습니다.
• 통화 기록만 이력 테이블로 분리: 한 사업자에 여러 건이 쌓이고 시간 순서가 의미를 가지므로 별도 테이블로 두고, 사업자가 병합되면 기록도 함께 이관합니다.
• 수집 작업은 집계만 남긴다: 회차마다 실행 시각과 수집, 매칭, 실패 건수를 기록해 매칭률 추이를 확인하되, 개별 사업자를 회차에 종속시키지 않습니다.
• 활용 범위는 내부 영업으로 한정: 연락처는 내부 영업 목적으로만 조회하고 제3자에게 제공하지 않는 것을 전제로 권한과 내보내기 경로를 설계했습니다.

수집 결과를 확인하는 사람과 수집을 제어하는 사람이 다르다는 점을 전제로, 조회 계열과 변경 계열을 화면 단위가 아니라 권한 단위로 분리했습니다.

BUILD

구축 방향과 데이터 처리 로직

사업자등록번호를 중심 식별값으로 두고, 기본 정보 수집과 연락처 매칭을 별도 단계로 구성했습니다. 재수집 시에는 연락처 관련 값만 갱신하고 담당자, 통화 횟수, 영업 단계는 보존해 자동 수집이 사람의 영업 이력을 덮어쓰지 않도록 했습니다.

VALIDATION

검증한 업무 범위

비슷한 업무에 적용할 수 있는 부분

신규 점포, 입점 후보, 협력사 발굴처럼 공개 정보와 연락 수단을 결합해야 하는 영업 업무에 적용할 수 있습니다. 수집량보다 식별 규칙, 실패 사유, 후속 활동의 연결 여부가 실제 활용도를 결정합니다.

RESULT

※ 본 프로젝트는 고객사 실제 업무 요건을 바탕으로 설계한 결과물이며, 보안 정책에 따라 일부 화면만 공개했습니다.