요약

  • 지정된 기본 ID 보존 베타에 참여하지 않은 계정에서는 연락처 병합 시 두 레코드 모두 진행 중인 워크플로에서 빠진다. 베타에서는 기본 레코드만 기존 진행 상태를 유지한다.
  • 일괄 병합의 최신 업데이트 기준에는 숨겨진 내부 속성도 포함된다. 가장 최근에 바뀐 레코드가 가장 중요한 후속 업무를 품고 있다는 보장은 없다.
  • 워크플로 재등록은 처음부터 다시 시작한다. 병합 취소도 지원되지 않으므로, 완료 기준은 중복 수 감소와 남은 업무의 처리 여부를 함께 봐야 한다.

정리 실적을 보고하는 화면에는 중복 연락처가 하나 줄었다고 나온다. 고객은 그런 숫자를 보지 않는다. 고객이 기다리는 것은 제품 시연 뒤에 오기로 한 안내, 또는 체험 사용을 시작한 뒤의 연락이다. 두 화면 사이에 데이터 정리 프로젝트의 맹점이 있다.

가령 같은 고객의 진짜 중복 레코드 두 개가 있다고 하자. 하나는 시연 후속 안내를 기다리는 워크플로에, 다른 하나는 체험 이용 점검을 기다리는 워크플로에 들어 있다. 둘을 합친 뒤에도 두 약속은 남아 있다. 레코드 하나를 없앴다고 약속 하나가 자동으로 사라지는 것은 아니다. 그런데 소프트웨어에서 그 약속을 실행하던 경로는 달라질 수 있다.

과거를 합치는 기능과 미래를 잇는 기능

HubSpot의 레코드 병합 문서는 활동과 연결 정보, 속성 이력을 최종 레코드에 모으는 동작을 설명한다. 그래서 병합된 고객 화면은 상당히 그럴듯하다. 지난 대화가 보이고, 예전 활동도 남는다. 사람이 읽기에는 연속된 관계처럼 보인다.

실행 대기 중인 일에는 다른 규칙이 적용된다. 워크플로가 지원되는 Professional 또는 Enterprise 계정에서 Primary ID Preservation for Merged Records 공개 베타 참여 여부가 갈림길이다. 참여하지 않았다면 병합 당시 두 레코드 모두 활성 워크플로에서 해제된다. 베타에 참여한 계정은 기본 레코드의 지연, 분기, 대기 중 작업을 이어 간다. 보조 레코드는 진행 중이던 모든 워크플로에서 빠진다.

기본 레코드를 고르는 일이 단순히 어느 이름표를 앞에 붙일지의 문제가 아닌 이유다. 베타에서는 어느 실행 경로가 살아남을지도 함께 고른다. 다른 쪽의 옛 활동이 이력에 들어왔다고 그쪽에서 기다리던 다음 작업까지 옮겨 오는 것은 아니다.

이 차이는 조직 안에서 잘 보이지 않는다. 관리자는 병합 결과를 확인하고, 영업 담당자는 고객의 과거 대화를 읽는다. 두 사람 모두 자기 화면에서는 정상적인 결과를 본다. 그 사이에서 아직 일어나지 않은 행동만 주인을 잃을 수 있다. 과거가 너무 잘 정리돼 있어서 미래의 빈자리가 가려지는 셈이다.

타임스탬프에 인사권을 주면

일괄 병합에는 누가 남을지 정하는 기준이 필요하다. HubSpot의 중복 관리 도구는 최근 상호작용, 생성 시점, 최근 업데이트 같은 기준을 제공한다. 최근 업데이트 방식은 숨겨진 내부 속성을 포함한 모든 속성을 살핀다.

컴퓨터가 순서를 정하기에는 충분한 정보다. 영업팀이 고객에게 한 약속의 우선순위를 정하기에는 다른 정보가 필요하다. 가장 최근에 수정된 레코드와 중요한 안내를 보내기 직전인 레코드는 서로 다를 수 있다. 타임스탬프는 시간을 말해 줄 뿐, 그 안내를 놓쳤을 때 누가 고객에게 설명해야 하는지까지 알지는 못한다.

따라서 베타 계정에서 이 기준으로 기본 레코드를 정한다면, 업데이트 순서가 업무 연속성 선택에 끼어든다. 데이터 정리 담당자가 의도하지 않아도 그런 권한은 생긴다. 병합을 누르는 사람이 결과를 설명할 팀과 다를 때 비용은 더 늦게 드러난다.

그렇다고 모든 중복 후보를 회의 안건으로 만들 필요는 없다. 먼저 같은 사람의 기록이 맞는지 확인하고, 그다음 활성 업무를 가진 후보만 따로 보는 편이 낫다. 아무 일도 기다리지 않는 두 기록과 중요한 고객 행동이 걸린 두 기록에 같은 처리 속도를 요구할 이유가 없다.

다시 넣는다고 이어지는 것은 아니다

문제를 알아챈 뒤 가장 손쉬운 대응은 고객을 워크플로에 다시 넣는 것이다. 여기에도 한 번 더 확인할 문이 있다. HubSpot의 등록 설정상 병합으로 생긴 데이터 변화만으로 새 워크플로에 자동 진입하는 동작은 기본적으로 꺼져 있다. 병합된 연락처의 등록을 허용하는 설정을 켤 수 있지만, 이것이 원래 작업 위치를 보존해 주지는 않는다.

재등록 규칙은 시작점으로 돌아간다. 앞서 지나온 작업도 다시 거친다. 중단된 후속 안내를 되살리려다 이미 했던 안내까지 다시 잡을 수 있는 구조다. 개별 작업의 조건에 따라 실제 실행은 달라지므로, 재등록을 무조건 이메일 중복 발송으로 계산해서도 안 된다.

수동 등록도 처음부터 시작한다. 특정 뒷부분만 실행하려면 원하는 작업부터 시작하는 별도 워크플로를 만들거나 복제해 수동으로 넣으라고 HubSpot은 안내한다. 복구 담당자에게 필요한 정보는 기존 워크플로 이름 하나가 아니라, 고객에게 이미 한 일과 아직 해야 할 일의 경계다.

전철을 다시 탄다고 방금 내린 역부터 출발하는 것은 아니다. 업무 복구에서 이런 차이를 무시하면 중복을 지우는 프로젝트가 중복 작업을 만드는 프로젝트로 바뀐다. 줄어든 것은 데이터 행뿐이고, 사람의 확인 업무는 늘어난다.

끝났다는 말의 기준

검증은 기록의 외관에서 다음 행동으로 옮겨가야 한다. 워크플로 상세 화면에는 작업, 이벤트, 발생 시각을 확인할 수 있는 기록이 있다. 병합 시각과 등록 해제, 재진입, 실제 실행을 연결해 봐야 한다. 특정 고객의 손실을 판단하려면 병합 전 위치와 병합 후 실행 기록이 필요하다.

잘못된 선택을 뒤늦게 알았을 때 병합을 취소해 두 레코드를 원상복구하는 기능도 없다. 추가 이메일 주소를 분리해 새 연락처를 만들 수는 있지만, 그것은 새 기록이다. 예전 ID를 찾을 수 있다는 것과 두 개의 진행 상태를 되돌리는 것은 다른 능력이다.

좋은 데이터 정리는 고객이 같은 설명을 두 번 하지 않게 한다. 더 좋은 데이터 정리는 약속한 다음 연락이 빠지지 않게 한다. HubSpot에서 병합 버튼을 누른 뒤 확인할 것은 그 두 번째 결과다. 연락처 숫자가 줄었다는 사실만으로는 고객의 오후가 나아졌는지 알 수 없다.