Дубли клиентов в CRM: как выбрать правило объединения и сохранить историю
Дубли клиентов возникают, когда система хранит несколько записей об одном участнике, но не знает надёжного правила их связи. Перед объединением важно установить, что записи действительно относятся к одной сущности и какие данные должны сохраниться. Совпавший телефон — основание проверки, а не универсальное разрешение слияния.
Один номер может использовать семья или организация. Один человек может писать с разных адресов. Кроме того, клиент, контакт, компания и сделка имеют разный смысл. Объединение контактов не должно незаметно объединять самостоятельные заказы.
Найти причину повторного создания
Сначала прослеживают источник: ручной ввод, импорт, форма или повторная доставка интеграции. Если причина остаётся, очистка базы будет временной. Для событий доставки полезен стабильный внешний идентификатор, но он не равен идентификатору клиента.
В конкретной CRM проверяют собственные правила поиска и объединения. Например, официальная справка HubSpot описывает отдельный механизм работы с потенциальными дублями. Его возможности зависят от подписки и доступа, а найденная пара требует оценки.
Определить основную запись и сохранение полей
Перед действием составляют карту: что остаётся в основной записи, как переносятся связи, история, файлы и идентификаторы внешних систем. У разных CRM эти последствия отличаются. Нельзя обещать универсальное восстановление после слияния без проверки продукта.
| Объект | Вопрос до объединения |
|---|---|
| Контактные данные | Как сохраняются разные рабочие адреса и номера |
| История | Видны ли сообщения и действия обеих записей |
| Сделки | Сохраняются ли самостоятельные заказы и владельцы |
| Интеграции | Какие внешние ссылки и ID продолжают работать |
| Права | Кто получит доступ к объединённым сведениям |
Для спорного поля фиксируют правило выбора и источник. «Более новая запись» не всегда содержит более достоверную информацию: импорт мог загрузить старый номер сегодня.
Проверить на контрольной паре
В тестовом или согласованном ограниченном сценарии сохраняют исходные значения и связи. Затем объединяют записи по документированным правилам и проверяют результат глазами читателя CRM и потребителя интеграции.
Если внешний сервис продолжает отправлять события на исчезнувший ID, история может снова разделиться. Поэтому контроль завершается новой доставкой и поиском клиента, а не только внешним видом карточки сразу после слияния.
Массовую операцию начинают после понятной проверки и плана восстановления, доступного для выбранной системы. Порог уверенности по похожести имени не стоит придумывать без фактической оценки ошибок на данных бизнеса.
Протокол для одной пары
Форма ниже помогает записать основание и ожидаемые последствия. Она не подключается к CRM и ничего не объединяет. Рабочие персональные сведения для учебной карточки не нужны.
В журнале сохраняют исходные ID, выбранную основную запись, время, исполнителя и итог проверки. Потенциальный дубль и завершённое объединение остаются разными состояниями.
Причины повторного создания на входе можно проверить по маршруту сайт — Telegram — CRM. Обсудить данные и интеграции CRM.