Объединять клиентов без единого идентификатора следует в два этапа: сначала находить кандидатов на совпадение, затем принимать решение о связи или слиянии. Похожее имя и одинаковый телефон не всегда означают одного человека или одну компанию. Чем выше цена ошибочного объединения, тем больше подтверждений требуется перед изменением базы.
Определите сущность и подготовьте признаки
Компания, юридическое лицо, филиал, сотрудник и покупатель — разные сущности. Два филиала могут пользоваться общей почтой, а одна компания — несколькими юридическими лицами. До поиска дублей договоритесь, что именно представляет строка клиентского справочника.
Иногда физическое слияние карточек вообще не нужно. Достаточно связать их с общим аналитическим клиентом, сохранив исходные записи и права доступа. Такой подход полезен, когда системы работают с разными уровнями детализации или историческими документами, которые нельзя бездумно перепривязать.
Телефоны приводят к согласованному виду с учётом страны, почту очищают от случайных пробелов, названия сравнивают без технических различий оформления. Исходное значение сохраняют: нормализация может оказаться ошибочной, особенно для неоднозначных коротких номеров.
Не удаляйте значимые части названий автоматически. Слова, похожие на организационно-правовую форму или обозначение филиала, могут отличать реальные компании. Отдельно контролируйте пустые строки и служебные значения: сотни карточек с «не указан» не должны становиться одной группой совпадений.
Разделите точные и вероятностные связи
Точное совпадение проверенного внешнего идентификатора обычно сильнее сходства названия. Но даже точный телефон может быть общим. Составьте правила с уровнями уверенности: автоматическая связь, кандидат на проверку и недостаточно данных.
Вероятностная оценка помогает приоритизировать разбор, но её число не превращается автоматически в доказанную вероятность. Проверяйте качество на вручную размеченной выборке. Особенно полезны сложные отрицательные примеры: однофамильцы, общие номера, соседние филиалы и переименованные организации.
Условный пример двух похожих компаний
Предположим, в CRM есть «Север, отдел закупок» и «Север, сервис». У обеих записан телефон общей приёмной. В учётной системе находятся два разных юридических лица. Автоматическое слияние по телефону смешало бы договоры и историю оплат.
Аналитик сохраняет две организации и связывает их с общей группой только при подтверждении структуры бизнеса. Для другой пары совпадают проверенный регистрационный идентификатор и адрес, а название отличается сокращением. Такую пару можно обрабатывать по более строгому правилу, предусмотрев журнал соответствий и возможность отменить решение.
Оцените ошибки до массового запуска
Проверяйте отдельно ложные объединения и пропущенные совпадения. Первая ошибка искажает историю клиента и может открыть чужие данные, вторая оставляет раздробленную аналитику. Их нельзя скрывать одним показателем «точности», особенно если большинство записей заведомо различны.
Для массовой обработки сначала используйте режим предложений без изменения источников. Ведомость кандидатов должна показывать признаки решения и исходные карточки. Практические причины дублей рассмотрены в статье о поиске дублей amoCRM; аналитическое сопоставление дополняет эту работу, а не заменяет её.
Примите управляемый процесс
Перед объединением проверьте связи со сделками, документами, ответственными и ограничениями доступа. Сохраните, какая запись стала основной, какие значения перенесены и кто утвердил решение. Для спорных пар используйте очередь ручной проверки с понятным владельцем.
Критерии приёмки: одинаковые исходные данные дают воспроизводимое решение, оператор видит его основания, ошибочную связь можно отменить, а контрольная выборка не содержит необъяснимых слияний. После запуска отслеживайте новые источники данных: добавление формы или филиала может изменить распределение признаков и качество прежних правил.
Применить в вашей компании
Обсудим вашу задачу?
Поможем разобраться с процессом, данными и настройками. Работаем удалённо с компаниями по всей России.