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