Дубли в CRM: как объединять карточки клиентов без потери истории

Почему простого совпадения имени мало

Одинаковое имя встречается часто, один человек может писать с рабочего и личного адреса, компания меняет название, а общий телефон может принадлежать отделу закупок. Постройте несколько уровней признаков: точное совпадение подтверждённого контакта, связь через организацию, совпадение истории заказов, похожее имя. Каждый уровень требует своего действия.

Пусть система показывает, какие поля совпали и какие конфликтуют. Не прячьте решение за процентом похожести без объяснения. Сотруднику нужно увидеть два исходных профиля и понять, не потеряется ли важная часть истории.

Правило слияния

Перед слиянием сохраните ссылку на обе исходные карточки и журнал того, кто подтвердил операцию. Если CRM умеет отменять объединение, проверьте это на тестовой базе. Если не умеет — права на массовое действие должны быть ещё уже.

Как тестировать ИИ-подсказку

Соберите обезличенные пары «один человек», «разные люди» и «неясно». Особое внимание уделите однофамильцам, филиалам и общим ящикам. Измеряйте не только число найденных дублей, но и ложные объединения. Последние редко встречаются, зато могут привести к раскрытию чужой истории или ошибочному обращению к клиенту.

Начните с подсказок в интерфейсе менеджера без автоматического изменения данных. Если качество устойчиво на новых парах, разрешите более сильные действия только для случаев с проверенными идентификаторами. NIST AI RMF предлагает учитывать контекст применения и последствия ошибки; для CRM цена ложного объединения должна быть видна в критериях приёмки.

Как сохранить историю после слияния

Перед операцией определите главную карточку, а затем проверьте, что перейдёт в неё: сделки, письма, согласия, задачи, комментарии и владельцы. В некоторых CRM техническое слияние сохраняет поля, но меняет порядок событий; поэтому тестируйте на копии данных. Не допускайте, чтобы информация одного человека стала видна другому сотруднику из-за ошибочной роли или общей организации. У менеджера должна быть возможность увидеть исходные идентификаторы и причину решения.

Два контрольных кейса

Кейс А: клиент сменил личный адрес на корпоративный и указал тот же подтверждённый телефон; покупки и организация совпадают. Вероятно, это один человек, но сотрудник всё равно проверяет конфликтующие поля. Кейс Б: два сотрудника одной компании используют общий телефон секретариата и пишут с разных адресов. Объединять их личные карточки нельзя. Если агент даёт одинаковое решение для обоих кейсов, его подсказка слишком груба для автоматического слияния.

Показатель, который нельзя спрятать

Считайте отдельно ложные объединения и пропущенные дубли. Первый тип обычно опаснее: он смешивает историю и может раскрыть данные. Порог для автоматического действия должен быть выше, чем для подсказки человеку. После каждого подтверждённого ошибочного слияния обновляйте тестовый набор и проверяйте, не затронуты ли другие карточки.

Когда похожесть обманывает

Один клиент может использовать разные транслитерации имени, а два разных клиента — один рабочий адрес вида sales@company. Если система сравнивает только строки, она пропустит первое и сольёт второе. Постройте признаки с учётом роли поля: подтверждённый личный контакт, организационный контакт, адрес доставки, история сделок. Для каждого признак имеет разную силу и ограничения. ИИ может объяснить «почему похоже», но не придумывать уникальный идентификатор там, где его нет.

Разбор ошибки после слияния

Если две карточки ошибочно объединили, восстановите исходные связи и проверьте, какие автоматические письма, назначения и отчёты уже использовали новую карточку. Простого нажатия «отменить» может быть недостаточно. Зафиксируйте сценарий в тестах, а для похожих случаев временно снизьте полномочие системы до подсказки. Это одна из причин начинать с интерфейса подтверждения, даже если модель на демонстрации почти всегда угадывает.

Можно ли сливать карточки полностью автоматически?

Только если система использует надёжные идентификаторы, цена ложного объединения приемлема и есть проверенный откат. В большинстве первых пилотов безопаснее показывать кандидатов сотруднику. Даже один подтверждённый телефон может быть общим корпоративным номером; организация может иметь несколько филиалов. Автоматизация полезна уже на этапе поиска возможных совпадений и сбора истории для решения. Расширение прав должно опираться на контрольные пары с похожими людьми и реальную статистику ошибок.