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