Убираем дубли в CRM с нейросетью

Менеджер открывает карточку клиента и не видит прошлый заказ. Зато рядом есть ещё две записи с похожим именем: в одной сохранилась переписка, в другой указан новый телефон. Нейросеть помогает найти такие пары и объяснить, почему они похожи. Но безопасная очистка CRM заканчивается не удалением строк, а проверкой: сделки, контакты и договорённости должны остаться у нужного человека.

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

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

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

Начните с участка, где ошибка уже мешает работе: повторные звонки одному клиенту, раздвоенная история обслуживания, несколько карточек после импорта. Так появится понятный критерий результата. Что важнее в вашей ситуации: перестать беспокоить клиента дважды или восстановить потерянную историю? От ответа зависит, какие поля проверять первыми.

Что умеет сама CRM, а где пригодится ИИ

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

Поведение объединения зависит от системы и настроек. В Битрикс24 автоматическое объединение учитывает не только совпадение данных, но и дополнительные условия, включая ответственного. В HubSpot документация отдельно предупреждает, что готовое объединение нельзя просто отменить. Поэтому инструкцию для своей CRM нужно прочитать до обработки, а не после пропавшей сделки.

• Точные совпадения и поиск по устойчивым идентификаторам поручите CRM или таблице.
• Неоднозначные пары предложите нейросети: пусть перечислит совпадения, различия и недостающие сведения.
• Выбор основной записи, перенос связей и само объединение оставьте сотруднику с нужными правами.
• Большую базу обрабатывайте по правилам и группам, а не одним сообщением в чат.

Не просите ИИ подключиться к CRM, если такого подключения у вас нет. Обычный чат анализирует переданный текст, но не видит карточки, вложения и события за пределами сообщения. Фраза «проверь всю историю» ничего не даст, когда в примере есть только имя и телефон.

Подготовьте копию данных, с которой не страшно работать

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

Полная выгрузка не всегда является резервной копией CRM. В ней могут отсутствовать файлы, комментарии, настройки автоматизации и часть связей. Узнайте у администратора, что реально восстановится после ошибочного объединения. Там, где откат неполный, безопаснее сначала только помечать кандидатов.

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

Для внешней нейросети подготовьте обезличенную выборку по правилам своей компании. Одинаковые телефоны заменяйте одинаковыми обозначениями вроде PHONE_A, адреса почты обозначайте EMAIL_A. Таблицу соответствий храните отдельно. Такая замена сохраняет точные совпадения, но не позволяет исследовать опечатки внутри скрытых полей. Эти проверки проводите в разрешённой среде на исходных данных.

Что похоже на дубль, но им не является

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

Рассмотрим учебный пример. В карточках C-14 и C-82 одинаковые фамилия и PHONE_A; вторая появилась после формы сайта. Это кандидат на проверку. В C-29 и C-30 совпадает EMAIL_OFFICE, но различаются имена и добавочные номера. Здесь общий контакт организации, а не доказательство одного человека. Названия «Север» и «Север-Сервис» без реквизитов вообще недостаточны для решения.

Совпадение помогает найти пару для проверки. Оно не даёт разрешения объединить карточки.

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

Попросите нейросеть объяснить каждую спорную пару

Передавайте небольшой набор кандидатов с понятными заголовками полей. Пусть модель не просто назначает процент сходства, а показывает основание решения. Число «98%» в ответе чата само по себе не является измеренной вероятностью: без проверенной методики оно только выглядит убедительно.

В ChatGPT на MashaGPT можно сначала проверить правила на вымышленных карточках. Дайте несколько намеренно похожих, но разных контактов. Если модель объединяет их без вопросов, уточните условия до работы с настоящей выборкой. Вы передаёте текст сами: это не автоматическая интеграция с вашей CRM.

Хороший ответ можно проверить по исходным строкам. Например: «C-14/C-82: PHONE_A совпал, фамилия совпала, источник второй записи форма; имя сокращено; проверить историю обращения». Плохой ответ: «вероятно один клиент, объединить». Во втором случае модель переложила на вас работу, но спрятала неопределённость.

Не выбирайте основную карточку только по дате

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

1. Сверьте активные сделки, обращения и связанные организации обеих карточек.
2. Для конфликтующих телефонов, адресов и должностей найдите подтверждение, а не просто самую позднюю дату.
3. Отдельно проверьте ответственного, сегменты, согласия и запреты на коммуникацию.
4. Запишите старые ID, выбранную основную карточку, решение по полям и имя проверяющего.
5. Уточните влияние объединения на интеграции, отчёты и автоматические действия CRM.

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

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

Объединение проверяют не по числу исчезнувших карточек

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

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

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

Чтобы через месяц не начинать заново

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

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

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