Дубли в Битрикс24 появляются почти в любой рабочей базе: заявки идут с сайта, из звонка, из мессенджера и через повторную заявку на лендинге, и CRM создаёт под каждый источник новую карточку. Я веду интеграции Битрикс24 с сайтами на Tilda и WordPress и вижу одну и ту же картину на разных проектах: через полгода в базе десятки контактов с одинаковым телефоном в разных написаниях и по три-четыре карточки одной компании. Ниже разбираю, как работает штатный поиск дублей в Битрикс24, как объединять карточки без потери истории сделок и звонков, и что настроить, чтобы новые дубли не появлялись.
Откуда берутся дубли контактов и компаний в CRM
На практике дубли в базе появляются по одной из нескольких причин.
Первая, самая частая: несколько источников лидов льют заявки в CRM без проверки по телефону или email. У меня был проект, где интернет-магазин на WooCommerce слал заказы через один вебхук, а квиз на Tilda через другой, и оба создавали новый контакт при каждом обращении, даже если человек уже был в базе.
Вторая причина: менеджеры создают контакт вручную во время звонка, не проверив, есть ли такой человек в системе. Разные написания телефона, с плюсом и без, с пробелами и без них, поиск по номеру не всегда сопоставляет как одно и то же значение.
Третья: импорт из Excel или из другой CRM при переезде. Импорт почти никогда не проходит идеально, часть контактов заводится заново, потому что в исходном файле email указан не для всех строк.
Четвёртая: у компании несколько юрлиц или она меняла название, и менеджер заводит новую карточку компании вместо того, чтобы найти старую и добавить в неё новый реквизит.
Как Битрикс24 ищет дубли контактов и компаний
В Битрикс24 есть два механизма проверки, и они решают разные задачи.
Первый работает в момент создания карточки: когда менеджер сохраняет новый контакт или лид, CRM сверяет телефон и email с уже существующими записями и показывает предупреждение о возможном совпадении прямо в форме. Это ловит основную часть дублей на входе, но не помогает с базой, которая уже накопилась за годы работы.
Второй, инструмент поиска дублей в настройках CRM, сканирует всю базу контактов и компаний по выбранным полям, обычно это телефон, email, ФИО или название и ИНН. Инструмент группирует найденные совпадения и предлагает объединить их прямо из списка, без перехода в каждую карточку по отдельности.
Ограничение у обоих механизмов одинаковое: они находят точные совпадения по значению поля. Если один телефон записан как «+7 999 123-45-67», а второй как «89991234567», система не всегда сопоставит их автоматически, разные разделители и коды страны читаются как разные строки. Поэтому перед большим сканированием я сначала привожу телефоны в базе к одному формату через групповое редактирование списка контактов, а на объёмах в несколько тысяч записей делаю это скриптом через REST API.
| Способ поиска дублей | Что делает | Когда использую |
|---|---|---|
| Штатный инструмент поиска дублей в CRM | Сканирует контакты и компании по точным совпадениям телефона, email, ИНН или названия | Разовая чистка базы, до 5-10 тысяч записей |
| Автоматическая проверка при создании карточки | Показывает предупреждение, если телефон или email уже есть в базе, до сохранения новой записи | Ежедневная работа менеджеров с новыми лидами |
| REST API: crm.duplicate.findbycomm, crm.duplicate.findbyentity | Ищет совпадения по значению из внешней системы или сценария, без захода в интерфейс | Синхронизация с сайтом, магазином, сценариями n8n |
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Как объединить дубли вручную: пошаговый процесс
Объединение карточек в Битрикс24 работает так: выбираю в списке контактов или компаний две и больше записей чекбоксами слева, запускаю действие объединения и получаю экран сравнения полей.
На этом экране Битрикс24 показывает значения по каждому полю у всех выбранных карточек и просит выбрать, какое из них станет итоговым. Например, если у одного контакта указан email, а у второго нет, оставляю тот, где поле заполнено. Отдельно выбирается основная карточка, именно к ней привяжутся все сделки, звонки, письма и задачи от объединяемых дублей.
Порядок действий у меня обычно такой:
- Открываю список контактов, фильтрую по подозрительному телефону или фамилии.
- Отмечаю дубли чекбоксами и запускаю объединение.
- Сверяю поля построчно, оставляю более свежие и более полные данные.
- Проверяю, что все сделки после объединения видны в истории основной карточки.
- Если у дублей были разные ответственные менеджеры, отдельно решаю, кто останется ответственным за объединённую карточку.
Для компаний процесс тот же, но добавляется ещё один момент: если у двух карточек компании разные привязанные контакты, после объединения все они окажутся в одной карточке. Это стоит проговорить с отделом продаж заранее, иначе менеджер увидит в своей компании чужих контактов и не поймёт, откуда они взялись.
Поиск дублей через REST API и автоматизацию
Ручной поиск дублей нормально работает, пока база на несколько тысяч записей и обновляется нечасто. Как только заявки идут потоком с нескольких сайтов, я перехожу на проверку через REST API прямо в момент создания лида, до того как контакт попадёт в CRM.
Метод crm.duplicate.findbycomm принимает тип связи, телефон или email, и список значений, а возвращает ID контактов, лидов и компаний, где такое значение уже встречается. Логика в интеграции такая: перед созданием контакта сценарий сначала спрашивает у Битрикс24, нет ли уже такого телефона в базе, и только если ответ пустой, создаёт новую карточку. Если совпадение нашлось, вместо нового контакта обновляется существующий, а к нему привязывается новая сделка.
Похожий метод crm.duplicate.findbyentity ищет дубли для уже существующей карточки по её ID, это удобно, когда нужно проверить конкретный контакт, а не искать по значению вручную.
Пример запроса к вебхуку для поиска дублей по телефону:
curl -X POST \
"https://your-domain.bitrix24.ru/rest/1/webhook_code/crm.duplicate.findbycomm" \
-H "Content-Type: application/json" \
-d '{
"entity_type": ["CONTACT", "LEAD"],
"type": "PHONE",
"values": ["+79991234567"]
}'Если в ответе приходят непустые массивы CONTACT или LEAD, значит контакт с таким телефоном уже есть, и сценарий обновляет найденную запись вместо создания дубля. Такую проверку я обычно встраиваю в автоматизацию в n8n, которая забирает заявки из форм на сайте и решает, создавать новую карточку в CRM или обновить существующую, прежде чем сделка попадёт к менеджеру.
Как настроить формы и процессы, чтобы дубли не появлялись заново
Разовая чистка базы решает проблему на один день, дубли продолжат появляться, если источник остался прежним. Из того, что реально помогает на моих проектах:
В настройках CRM-форм и в правилах обработки лидов стоит включить проверку по телефону и email перед созданием новой записи, тогда повторное обращение того же человека обновляет существующий контакт вместо создания нового.
Если заявки идут из нескольких каналов, сайт, телефония, мессенджер, лучше свести их через один сценарий обработки, а не подключать каждый канал к CRM отдельным вебхуком напрямую. Тогда проверка на дубли применяется одинаково для всех источников, а не только для части из них.
Стоит закрепить за менеджерами правило: искать контакт по телефону перед созданием нового, а не полагаться только на память. В форме создания лида или сделки есть быстрый поиск по номеру прямо на месте.
При интеграции с несколькими системами, сайтом на Tilda, магазином, телефонией, я обычно завожу единую точку входа для лидов через n8n или скрипт на Python, которая сначала проверяет дубли через REST API и только потом решает, в какую карточку писать. Разработка такого скрипта под конкретную задачу у меня начинается от 20 000 ₽, и она снимает большую часть ручной работы с базой в будущем.
Частые ошибки при объединении карточек
За несколько лет работы с Битрикс24 регулярно вижу одни и те же ошибки при объединении дублей.
Объединяют карточки с разными ответственными менеджерами, не разобравшись заранее, кто останется ответственным. В результате часть сделок перестаёт кому-либо принадлежать, и клиент неделю ждёт ответа.
Выбирают основной карточкой более старую запись просто потому, что она была создана первой, хотя в более новой карточке данные полнее и актуальнее. Я сверяю обе карточки по дате последнего изменения, а не по дате создания.
Объединяют компании без проверки привязанных контактов и сделок, а потом обнаруживают, что к одной компании привязаны два разных юрлица с разными реквизитами, и это ломает документооборот и счета.
Запускают массовое объединение по всей базе сразу, без выборочной проверки первых результатов. Я всегда сначала объединяю 5-10 пар вручную, смотрю, что получилось, и только потом иду дальше или пишу скрипт для остальных.
Условия и возможности Битрикс24 меняются, поэтому перед запуском я уточняю их у самого сервиса.
Частые вопросы
Как Битрикс24 определяет, что это дубли, а не просто похожие карточки?
Штатные механизмы сравнивают точные значения выбранных полей, обычно телефон, email, ИНН или название компании. Если значения совпадают полностью, карточки помечаются как возможный дубль. Похожие, но не идентичные записи, например, разное написание одного и того же телефона, система может не связать между собой, поэтому перед сканированием я привожу формат номеров к единому виду.
Можно ли отменить объединение дублей, если объединили не то?
Полной кнопки «отменить объединение» я не встречал. Часть данных можно восстановить по истории изменений карточки, но это ручная работа, а не одно действие. Поэтому перед массовым объединением я всегда проверяю результат на небольшой группе карточек, 5-10 пар, и только потом продолжаю на всей базе.
Как часто нужно чистить базу от дублей?
Зависит от того, сколько источников льёт лиды в CRM. Если это один сайт с одной формой, беглой проверки раз в квартал обычно достаточно. Если заявки идут из нескольких каналов без единой точки входа, я рекомендую сканировать базу штатным инструментом хотя бы раз в месяц, иначе объём дублей нарастает быстрее, чем кажется.
Что делать, если дублей в базе тысячи и вручную объединять долго?
На таком объёме ручное объединение не имеет смысла. Логичнее сначала прогнать базу через REST API скриптом, который группирует записи по точным совпадениям телефона и email и готовит список пар для объединения, а вручную потом разбирать только спорные случаи, где автоматика не уверена.