Суть задачи

Сначала определите, что считать дублем

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

Исходные данные

Подготовьте ограниченную выгрузку

Для первого теста достаточно внутреннего ID, нормализованного телефона или домена, названия и даты последнего обновления. Уберите заметки менеджера, переписку, платёжные поля и данные, которые не нужны для поиска совпадений. Не передавайте пароли и полные карточки «на всякий случай». Проверьте, разрешено ли выбранному сервису обрабатывать клиентскую информацию; если нет, используйте утверждённую корпоративную среду или синтетические записи.

Рабочий маршрут

Разделите совпадения на уровни

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

Проверка

Попросите показать доказательство

Для каждой пары задайте формат: ID первой карточки, ID второй, совпавшие поля, различия, причина ручной проверки и статус «недостаточно данных». Запретите модели придумывать общий адрес или считать пустое поле подтверждением. Если сведения расходятся, пусть результат указывает конфликт, а не выбирает более новый текст автоматически. Так специалист может открыть две исходные записи и понять, что именно нужно проверить.

Практический пример

Проверьте ложные совпадения

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

Риски

Не объединяйте записи автоматически

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

После запуска

Запустите тест на ограниченной группе

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

Внедрение

Сохраните аккуратный журнал

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

План на день

Настройте очередь так, чтобы её можно было разобрать

Не выдавайте специалисту сплошной список пар без приоритета. Сначала покажите точные совпадения проверенных идентификаторов, затем вероятные пары с несколькими независимыми признаками, а сомнительные вынесите в отдельную вкладку. Для каждого кандидата нужны две ссылки на карточки и короткая причина: общий домен, телефон или нормализованное название. Не скрывайте различающиеся поля за общей оценкой. Менеджер должен иметь возможность выбрать «это филиалы», «это один клиент» или «недостаточно данных» и оставить комментарий, который затем можно учесть в настройке правил.

Вывод

Проверьте, что исправление не портит соседние процессы

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

Раздел материала

FAQ: можно ли сразу объединять точные совпадения?

Не без проверки владельца базы. Даже одинаковое поле может относиться к филиалу или общему контакту; сначала подтвердите назначение идентификатора и сохраните возможность отката.

Раздел материала

FAQ: какие данные лучше не передавать?

Не загружайте переписку, платёжные сведения и лишние персональные данные. Оставьте только поля, необходимые для сопоставления, и соблюдайте внутренние правила обработки.

Раздел материала

FAQ: что делать с парой, где не хватает полей?

Оставить её в статусе «недостаточно данных» и запросить ручную проверку. Уверенный ответ модели не заменяет отсутствующее подтверждение.