Дубли в CRM: почему AI не заменяет правила учёта

Отделите человека от обращения и сделки

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

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

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

Сохраните историю источников до объединения карточек

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

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

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

Разберите неоднозначность до включения автоматической склейки

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

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

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

Проектная работа MR·H

Проверьте повторную доставку одного события

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

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

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

После очистки проверьте, что работа стала точнее

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

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

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