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

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

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

Что считать дублем, а что разными сущностями

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

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

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

Почему возникают повторные записи

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

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

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

Как задать правила совпадения

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

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

Пустые значения не совпадают друг с другом. Два контакта без телефона — не пара только потому, что оба поля пусты. Условия вида «телефон совпал И почта совпала» подходят для автоматического решения лучше, чем «телефон ИЛИ почта». Комбинированное правило можно дополнить типом сущности, компанией, источником или временным окном.

Точное и неоднозначное совпадение

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

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

Общий телефон не всегда означает дубль

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

Как провести безопасное объединение

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

Затем выполните dry-run — предварительный расчёт без записи изменений. Для каждой пары он должен показать основную и вторичную карточки, значения после объединения, переносимые связи, конфликты и причину решения.

Предварительный просмотр объединения

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

Учебный пример на вымышленных данных. В CRM есть контакты «Анна Соколова» и «Анна С.». После нормализации у них совпали телефон и почта. Первая карточка связана с двумя сделками и задачей, во второй записана новая должность. Dry-run выбирает первую основной, предлагает перенести должность и связи второй карточки, но не выполняет запись.

Журнал предварительного просмотра может выглядеть так:

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

Связанные сделки и история

До записи составьте перечень связей: сделки, задачи, звонки, письма, заметки, файлы, ответственные и пользовательские объекты. После объединения число и идентификаторы этих объектов должны совпасть с ожидаемым результатом dry-run.

В Microsoft Dataverse, согласно документации, объединение доступно для записей одного типа среди организаций, лидов и контактов; основная запись сохраняется, вторичная деактивируется, а связанные заметки и действия привязываются к основной. Это пример механизма конкретного продукта, а не общее свойство всех CRM. Перед работой проверьте документацию и поведение своей версии системы.

Конфликт полей и восстановление

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

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

Как настроить автоматическую обработку

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

В документации Microsoft Dataverse описаны правила обнаружения дублей при ручном создании или изменении записи. Пользователь может сохранить запись либо выбрать объединение; для конфликтующих полей интерфейс позволяет указать, какое значение оставить. Документация отдельно ограничивает новый сценарий ручным вводом и отмечает, что он не работает в автономном режиме. Эти условия нельзя переносить на другую CRM или считать подтверждением вашей настройки.

Для выбранной системы проверьте:

1. На каких сущностях работает поиск совпадений и можно ли сравнивать только записи одного типа.
2. Кто вправе просматривать кандидатов, выбирать основную карточку и запускать объединение.
3. Что происходит при повторной заявке: обновляется контакт, создаётся новая сделка или формируется задача менеджеру.
4. Какие связи переносит штатный механизм и что происходит со вторичной записью.
5. Где сохраняются результат, ошибки и решение пользователя.

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

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

Как проверить результат и предотвратить повторение

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

После каждого теста сравните ожидаемый и фактический результат:

• какая карточка стала основной;
• какие значения сохранились;
• на месте ли сделки, задачи, письма и заметки;
• доступна ли исходная история;
• появился ли журнал операции;
• попал ли спорный случай в ручную очередь;
• можно ли восстановить исходное состояние по подготовленному сценарию.

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

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

Когда подключать специалиста

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

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

Для начала подготовьте обезличенные примеры дублей, список источников, названия сущностей и ожидаемое действие при повторном обращении. Обсудить процесс со Switch On AI можно без передачи паролей и клиентских персональных данных. Цель разбора — определить правила, проверки и границы работ, а не обещать очистку всей базы одной кнопкой.