В CRM есть «Компания А», «А — закупки» и ещё одна запись, созданная после звонка. Один менеджер согласует поставку, второй предлагает тому же покупателю другой вариант. В отчёте появляются три клиента, а история переговоров распределена между карточками.
Удаление лишнего названия не решает проблему. За каждой записью могут находиться действующие сделки, задачи, письма, документы и связи с учётной системой. Сначала нужно доказать, что записи описывают одну сущность, затем определить судьбу данных и только после этого выполнять объединение.
Ниже — порядок для рабочей клиентской базы. Конкретные действия зависят от CRM: возможность объединения, состав переносимых данных и способ восстановления нужно проверить в вашей версии и настройках.
Начните с причины появления дублей
Зафиксируйте, откуда пришли несколько записей. Частые организационные сценарии: сотрудники создают клиента без поиска, импорт добавляет новые строки, канал обращений не распознаёт существующую запись, интеграция использует другой идентификатор.
Полезно разобрать десять последних случаев. Для каждого запишите дату появления, источник и действие, создавшее вторую карточку. Иначе очистка станет регулярной ручной работой: база будет снова пополняться теми же дублями.
Определите владельца клиентских данных. Он принимает решения по спорным совпадениям и правилам заполнения. Администратор CRM проверяет техническое поведение, а менеджер подтверждает контекст отношений. Эти роли могут совмещаться, но решение не должно зависеть только от того, кто первым заметил похожее название.
Отличайте дубль от связанной записи
Компания и человек — разные сущности. Два сотрудника одного покупателя не становятся дублями из-за общего домена почты. Общая приёмная может использовать один телефон для нескольких контактов. Одинаковый бренд тоже не означает одно юридическое лицо.
Для компаний сопоставляйте подтверждённые реквизиты, контекст договоров, площадки и принятую в CRM модель учёта. Совпадающий идентификатор юридического лица — сильный признак, но если филиалы ведутся отдельными карточками намеренно, их нельзя автоматически сводить в одну.
Для контактов проверяйте не только имя, но и подтверждённые рабочие данные, место работы и историю общения. Новый контакт вместо уволившегося сотрудника — не новая версия прежнего человека.
Разделите кандидатов на три группы:
- Подтверждённый дубль: есть достаточные доказательства одной сущности и понятная схема сохранения данных.
- Требует проверки: совпадает часть признаков, но остаются противоречия.
- Связанные, но разные записи: их нужно связать по модели CRM, сохранив самостоятельность.
Автоматический поиск должен помогать формировать кандидатов. Решение об объединении не следует подменять похожестью строки.
Подготовьте данные к сравнению
Для поиска полезно привести телефоны к согласованному формату, убрать случайные пробелы и проверить очевидные ошибки написания. Не меняйте исходные реквизиты массово только ради совпадения: сохраните их и отдельно сформируйте нормализованные значения для сравнения.
Сравнивайте несколько признаков. Совпадение названия даёт слабое основание; совпадение названия, подтверждённых реквизитов и истории открытого заказа — более сильное. При расхождении важных реквизитов направляйте пару на проверку, даже если остальные данные похожи.
В документации Microsoft потенциальные совпадения также рассматриваются отдельно от выбора основной записи и полей при объединении. Поиск и решение — разные этапы.
Составьте план сохранения до нажатия кнопки
Для каждой пары перечислите связанные данные: контакты, открытые и закрытые сделки, задачи, письма, заметки, вложения и внешние идентификаторы. Отдельно укажите активные автоматические действия и обмен с другими системами.
Выясните, что функция объединения делает именно в вашей конфигурации. Переносятся ли связи? Меняется ли владелец? Сохраняются ли даты и авторы? Какие поля выбираются вручную? Что произойдёт с внешней системой, которая продолжит присылать обновления на старый идентификатор?
Это не формальность. Например, руководство HubSpot указывает, что поведение зависит от типа записи и что прямой отмены объединения нет. В другой CRM порядок может отличаться. Экспорт списка клиентов не гарантирует восстановления переписки, вложений и всех связей.
До массовой обработки проверьте доступный способ резервирования и восстановления на тестовой копии или разрешённом пробном наборе. Если восстановить важные данные нельзя, согласуйте иной сценарий работы с подтверждёнными дублями.
Заполненный пример разрешения конфликтов
Возьмём учебную пару компаний. Проверяющий подтвердил, что это один покупатель, а отдельное ведение подразделения не требуется.
Карточка К-104 создана раньше, связана с учётной системой и содержит две открытые сделки. Её название — «Компания А», общий телефон устарел, менеджер — Анна. В карточке К-287 название — «Компания А — закупки», указан актуальный рабочий контакт Ольги и есть одна открытая сделка, две задачи и четыре заметки. Значимые даты и авторы заметок заполнены.
Основной выбирают К-104, чтобы сохранить принятый идентификатор компании. Это решение основано на связях, а не только на возрасте карточки. План по полям и связанным данным выглядит так:
- Название: оставить подтверждённое наименование «Компания А»; прежний вариант сохранить как источник поиска, если модель данных это позволяет.
- Телефон: использовать подтверждённый актуальный; старое значение сохранить в истории с причиной замены.
- Контакт: Ольгу связать с основной компанией, предварительно проверить, нет ли уже её отдельной карточки.
- Ответственный: Анна; передать ей контекст задачи коллеги и согласовать дальнейшую коммуникацию.
- Сделки: сохранить все три как самостоятельные продажи; объединение компании не означает объединение сделок.
- Задачи: сохранить обе с исполнителями, сроками и связью с соответствующей сделкой.
- Заметки: сохранить четыре исходные записи с доступными авторством и временем; не сводить их в одну фразу «история перенесена».
- Внешние связи: проверить обновление основной карточки и обработку старого идентификатора на стороне обмена.
Этот список — образец решения, а не обещание, что любая CRM выполнит все пункты автоматически. Если отдельный элемент нельзя перенести штатно, план надо скорректировать до объединения.
Выполните пробу и проверьте результат
На время операции договоритесь, кто работает с выбранными карточками. Параллельное редактирование и входящие обновления способны изменить данные между сравнением и объединением. Не отключайте все процессы компании без необходимости; ограничьте только затронутый участок согласованным способом.
После пробной операции проверьте результат с позиции сотрудника:
- По прежнему названию и актуальному контакту находится нужный клиент.
- Все три сделки из примера доступны и сохраняют свои состояния.
- Обе задачи имеют правильные сроки, владельцев и контекст.
- Четыре заметки доступны, а важные вложения открываются.
- Отправка нового обращения не создаёт прежний дубль заново.
- Обмен с учётной системой использует согласованное соответствие записей.
- У команды нет двух параллельных обещаний клиенту из-за старых задач.
Сверяйте не только количество объектов, но и содержание. Три сделки могут остаться, но одна окажется привязана к неверному контакту. Важные ссылки проверяйте переходом из карточки и обратным поиском.
Если штатного объединения нет
Можно организовать основную рабочую запись и явно связанный с ней архивный дубль, если такой способ поддерживается системой и не нарушает рабочие требования. В старой записи должно быть понятно, куда продолжать работу. Историю сохраняют, а создание новых задач по дублю ограничивают доступными средствами.
При этом одного комментария недостаточно, если интеграция продолжает создавать сделки в прежней карточке. Потребуется исправить правила обмена или настроить соответствие идентификаторов. Разбор таких связей есть в статье об интеграции бизнес-систем.
Не удаляйте старую запись до проверки зависимостей. И не оставляйте архивную карточку в активной отчётности, если она продолжает завышать количество клиентов.
Закрепите результат в регламенте
Используйте короткую карточку решения по каждой обработанной паре:
- Идентификаторы кандидатов и основание совпадения.
- Проверяющий и дата подтверждения.
- Основная запись и причина выбора.
- Решение по конфликтующим полям.
- Список связанных объектов до и после.
- Проверка интеграций и возможность восстановления.
- Исполнитель операции и результат контрольной проверки.
Для профилактики добавьте поиск перед созданием клиента, правила импорта и единое место проверки сомнительных совпадений. Периодически разбирайте новые дубли по источнику. Если основная причина — поток обращений, начните с организации работы с заявками.
ЧатПлюс включает CRM и единые входящие, но возможность и порядок объединения записей нужно уточнить на конкретном сценарии. Покажите ExtentLab обезличенную пару карточек, чтобы обсудить сохранение истории и предотвращение повторных дублей.