Дубли клиентов объединяют с сохранением истории: агенты готовят совпадения, бизнес подтверждает спорные

Нужно ли заказывать разработку ради дублей? Сначала стоит проверить штатное объединение в действующей CRM. Переход на свою CRM вместо коробки решает другой вопрос; для чистки карточек менять всю систему не требуется.

Битрикс24 уже разделяет автоматическое и ручное объединение. По инструкции, проверенной 08.10.2026, различающиеся поля требуют ручного решения; для автоматики важен и общий ответственный.

Наличие кнопки ещё не отвечает на вопрос, что станет с данными. RetailCRM переносит заказы и коммуникации, но при заполненном источнике привлечения у обеих карточек оставляет источник основной.

Что считать дублем клиента? Нужен признак одного покупателя, которому доверяет компания. В нашей CRM заявленное имя служит подсказкой, а связь между источниками требует подтверждённого идентификатора.

Поиск вправе быть шире правил объединения. Unisender предлагает кандидатов даже по части email до домена, а конфликтующие значения показывает человеку. Такая пара сама по себе не доказывает личность.

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

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

Мы строим карточку человека из фактов нескольких источников. Публичный счётчик машины показывает работу над своим сайтом. В нашей CRM исходные факты сохраняются отдельно от короткой ленты на экране.

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

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

Финансовые события сохраняют исходные номера. Один платёж из разных источников нельзя посчитать дважды после слияния. Сумма в новой карточке должна объясняться теми же покупками.

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

Что заказать у разработчика? Поиск совпадений, список спорных пар и перенос со сверкой результата. Задачу для ИИ-агента формулируют через эти результаты, а не через просьбу «почистить базу».

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

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

Как понять, что разработка готова? На проверочных карточках должны работать согласованные правила, включая отказ от объединения. Число найденных дублей само по себе качества не показывает.

Нужны и пары, которые система обязана оставить раздельными. Общий телефон, конфликт покупателя и отписка на одном адресе проверяют разные ошибки. Без таких примеров список совпадений ещё может склеить разных людей.

Повторный запуск проверяют отдельно. Unisender предупреждает о повторном попадании контакта в цепочку писем. В своей операции проверяют, что повтор не переносит событие ещё раз и не запускает лишнюю отправку.

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

Для продолжающейся работы у нас есть разработка по подписке. «Один проект» стоит 250 000 ₽ в месяц, на 08.10.2026: одна задача в работе, изменения в репозитории клиента, пауза в любой месяц.

В поток можно поставить поиск, спорные пары и безопасное объединение. Цена подписки не обещает очистить любую базу за месяц. Если нужен разбор своей базы, следующий шаг — обсудить задачу.

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