Менеджеры открывают разные карточки одного клиента: в одной осталась переписка, в другой — сделка и следующий звонок. Безопасный порядок такой: подтвердить, что записи относятся к одному человеку, согласовать итоговые поля, проверить перенос связей и только затем объединять. Простое удаление «лишнего» контакта не заменяет эту процедуру.
Кому это актуально
Разбор предназначен руководителю, который отвечает за порядок в действующей CRM — системе управления отношениями с клиентами. Он поможет поставить задачу администратору или разработчику и принять результат без потери истории.
Речь о дублях контактов. Два обращения или две сделки одного человека могут быть самостоятельными событиями: объединение клиента не должно автоматически склеивать его заказы. Выбор системы и первого этапа автоматизации разобран отдельно в статье о процессах для CRM на заказ.
Как отличить дубль от случайного совпадения
Сначала нужен список кандидатов, который ничего не меняет. Не запускайте незнакомый «поиск дублей» в рабочей базе, пока не выяснено его поведение: в Битрикс24 проверка при определённых условиях может сразу объединять совпадения. Это описано в официальной справке «Automatic duplicate merging in CRM», обновлённой 6 октября 2026 года; доступность функции зависит от тарифа.
Разделите найденные пары на три группы:
- Подтверждённый дубль. Известно, что это один человек: совпадают проверенные данные и контекст обращений, противоречий нет.
- Спорное совпадение. Совпал телефон или адрес почты, но различаются имя, организация либо история. Решение откладывается до проверки ответственным.
- Разные люди. Общий номер офиса, семейный телефон или почтовый ящик отдела объясняют совпадение. Карточки остаются раздельными.
Для сравнения можно привести телефоны к согласованному формату, сохранив исходное значение. Нельзя без разбора отбрасывать код страны или добавочный номер. У почтовых адресов не следует автоматически удалять точки и части после знака плюс: такие преобразования не универсальны. Фамилия, похожее название компании и домен почты сами по себе не подтверждают личность.
Учебный пример. У карточек А и Б совпал номер офиса, но указаны разные сотрудники. Их объединение смешает истории двух людей. У карточек В и Г совпали подтверждённые личные контакты, а ответственный подтвердил одного человека; это кандидат на объединение, но сначала надо сравнить сделки и условия связи с клиентом.
Что сохранить до объединения
Основная карточка — та, которая останется после операции. Выбирать её только по возрасту или заполненности рискованно: важны связи с учётной системой, действующие сделки и подтверждённая актуальность данных. Конкретные правила сохранения идентификатора зависят от CRM.
До изменения составьте карту результата:
- Поля. Для имени, телефонов, почты, компании и ответственного укажите итоговое значение и основание выбора. Новая дата изменения не всегда означает более достоверную информацию.
- Связи. Перечислите сделки, задачи, обращения, документы и другие связанные объекты. Зафиксируйте их идентификаторы, чтобы сравнить состав до и после.
- История. Уточните, что будет с письмами, звонками, заметками, вложениями и авторами записей. Обычная выгрузка контактов может не содержать этих данных.
- Ограничения. Отдельно проверьте отписки, запреты на коммуникацию и права сотрудников. Объединение не должно превращаться в разрешение рассылки или открывать историю чужому отделу.
- Интеграции. Запишите, какие внешние системы используют идентификаторы обеих карточек и как они найдут итоговую запись.
Это требования к проверке, а не обещание возможностей любой CRM. Если штатная функция не переносит нужную связь, до объединения надо выбрать поддерживаемый способ её сохранения. Прямое удаление строк базы данных обходит прикладную логику и для такой задачи не подходит.
Список кандидатов, экспорт и резервная копия решают разные задачи. Наличие файла с контактами ещё не доказывает, что из него можно восстановить переписку, связи и состояние автоматизаций.
Как проверить результат и возможность восстановления
Начните с учебной пары в разрешённой тестовой среде. Реальные персональные данные не нужно переносить в открытые таблицы или сторонние сервисы проверки дублей. На тестовом контуре внешние отправки должны быть изолированы: проверка не должна посылать клиентам письма, сообщения или документы.
Перед опытом сохраните доступное состояние карточек и их связей. После объединения сравните не только число объектов, но и их состав: одинаковое количество сделок не исключает замену одной связи другой.
Результат можно принимать, когда:
- каждое согласованное поле получило ожидаемое значение;
- нужные сделки, задачи и история доступны у итогового контакта, без лишних связей;
- права доступа и ограничения коммуникаций сохранены;
- интеграция находит итоговую карточку, а повторная обработка того же тестового события не создаёт нового клиента;
- в журнале понятно, какие записи объединили, кто принял решение, когда и по какому основанию.
В журнале достаточно идентификаторов и необходимых сведений в защищённой системе. Не стоит дублировать в нём всю переписку или распространять клиентскую базу вместе с отчётом.
Отмена требует отдельной проверки. Например, официальная документация HubSpot «Merge records», обновлённая 5 сентября 2026 года, прямо указывает, что разделить объединённые записи обратно нельзя. Создание нового контакта вручную не равнозначно восстановлению исходной истории.
Для вашей CRM администратор должен показать, что именно восстанавливается штатно, что потребует ручной работы и что восстановить не получится. Если приемлемого сценария нет, спорную пару безопаснее оставить раздельной. Восстановление всей рабочей базы ради одной ошибки тоже нельзя считать простым откатом: после копии могли появиться новые сделки и обращения.
Какие риски закрывает такой порядок
Главный риск — склеить разных людей и показать менеджеру чужую историю. Другой риск — сохранить контакт, но потерять его связь с заказом, задачей или внешней системой. Наконец, после очистки дубли могут появиться снова, если источник продолжает создавать новую запись при каждом повторе.
Поэтому очистку и устранение причины стоит принимать отдельно. Разработчик должен проверить, по какому устойчивому признаку источник узнаёт существующего клиента и как обрабатывает повторную доставку события. Если система не может уверенно сопоставить человека, лучше отправить случай на ручную проверку, чем автоматически назначить чужую карточку.
После первой согласованной партии повторите проверку в следующем штатном цикле обмена. Отсутствие дублей сразу после удаления ещё не подтверждает исправление причины.
Что запросить у подрядчика
До массового запуска нужны конкретные материалы:
- правила совпадения и список исключений, включая общий телефон и разные организации;
- образец карты «исходные карточки → итоговая карточка» с выбором конфликтующих полей;
- перечень сохраняемых связей, проверок доступа и поведения автоматизаций;
- протокол тестового объединения и восстановления с честным списком ограничений;
- план небольших партий, условие остановки и проверка источника повторных дублей.
Условие остановки можно задать заранее: обнаружена потерянная связь, неверный получатель, лишнее уведомление или изменение доступа — следующую партию не запускают до разбора. Приёмка должна показывать сохранённый рабочий сценарий, а не только уменьшившееся число контактов.
Частые вопросы
Можно ли объединять всех с одинаковым телефоном?
Нет. Общий номер организации или семьи может относиться к разным людям. Совпадение — повод проверить пару; для решения нужны контекст и отсутствие противоречий.
Достаточно ли выбрать самую заполненную карточку?
Нет. Заполненные поля могут быть устаревшими, а менее полная карточка — хранить актуальную связь с учётной системой. Итог выбирают по полям и связям, а не по общей заполненности.
Что делать, если дубль уже удалили?
Приостановить дальнейшую очистку и проверить доступные средства восстановления вместе с администратором. Не создавать замену наугад: сначала выяснить, где остались связанные объекты и какие новые изменения произошли после удаления.
Когда можно обойтись без разработки?
Когда штатная функция покрывает необходимые поля и связи, совпадения однозначны, а администратор проверил последствия на тестовых записях. Если сомнения касаются самого выбора между настройкой и кодом, полезны критерии доработки существующей CRM.
Как это решает OpenStart
Если дубли возникают на границе сайта, CRM и учётной системы или штатное объединение не сохраняет нужный сценарий, задача переходит к разбору интеграций и доработке. OpenStart занимается разработкой, доработкой и интеграциями CRM: начинает с текущего процесса и согласуемого этапа работ.
Для обсуждения достаточно назвать систему, источник дублей и описать, что должно сохраниться. Примеры можно обезличить; клиентскую базу и доступы в первичное обращение передавать не нужно. После разбора вводных можно согласовать объём, ограничения и критерии проверки — без обещания универсальной кнопки очистки.