Дублирование лидов в Битрикс24: 5 стратегий борьбы

Откуда берутся дубли

Лид — это первый контакт с клиентом: заявка с сайта, звонок через телефонию, письмо на корпоративную почту. Когда каналов несколько, один и тот же человек легко попадает в CRM дважды и больше: оставил заявку, потом позвонил, потом написал — и вот уже три карточки вместо одной.

Откуда это берётся чаще всего:

• Несколько источников лидогенерации — сайт, телефония, почта, открытые линии создают лиды независимо, не зная друг о друге.
• Разные форматы телефона — «89991234567» и «+7 (999) 123-45-67» без нормализации система считает разными значениями.
• Отсутствие проверки перед созданием — вебхуки и API-интеграции вызывают метод crm.lead.add вслепую, без предварительного поиска существующей карточки.
• Ручной ввод — оператор просто не видит, что карточка уже есть, и создаёт новую.
• Миграция данных — перенос базы из другой CRM или загрузка Excel-файла без дедупликации.

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

---

Стратегия 1. Нормализация телефона и поиск перед созданием

Самый частый источник дублей — разные форматы одного номера. Решение простое: привести все телефоны к единому виду +79999999999 ещё до того, как лид попадёт в базу.

Алгоритм:

1. Входящий номер очищается от пробелов, скобок, дефисов.
2. Приводится к формату +7XXXXXXXXXX.
3. Выполняется поиск по полю телефона в CRM.
4. Если совпадение найдено — обновляются поля существующей карточки.
5. Если не найдено — создаётся новый лид.

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

Важный нюанс: если один номер закреплён за несколькими контактами, заранее определите правило приоритета — какую карточку считать «главной».

---

Стратегия 2. Встроенный контроль дублей по ИНН и названию компании

Для корпоративных клиентов телефон — ненадёжный идентификатор: один номер колл-центра может принадлежать тысячам контрагентов. Здесь надёжнее работают ИНН и название компании.

В одном из наших проектов реализован такой механизм контроля дублей в карточке компании:

1. Пользователь заполняет поля карточки и нажимает «Сохранить».
2. Запускается скрипт, который ищет компании с полностью совпадающим ИНН или названием — сравнение регистронезависимое, приведение к нижнему регистру.
3. Если дубликат найден — появляется всплывающее окно «Найден дубликат» с ID карточки. Сохранение блокируется.
4. Если дублей нет — карточка сохраняется в штатном режиме.

Это закрывает и ручной ввод, и массовую загрузку данных.

Поле для сравнения	Применимость	Надёжность
Телефон (нормализованный)	Физлица, B2C	Высокая при нормализации
Email	Любые	Средняя (один клиент — несколько адресов)
ИНН	Юрлица	Очень высокая
Название компании	Юрлица	Средняя (зависит от написания)
Комбинация: ИНН + телефон	Юрлица	Максимальная

---

Стратегия 3. Правило «повторный лид → прежний менеджер»

Даже если дубль всё-таки создался — правильная маршрутизация не даст двум менеджерам одновременно работать с одним клиентом.

В нескольких проектах мы настраиваем очередь распределения входящих лидов с почты по такому принципу:

• Новый клиент — назначается менеджеру по кругу, равномерно.
• Повторный клиент — возвращается тому, кто уже вёл этого клиента.

Дубль как запись никуда не пропадает, зато операционный конфликт снят: оба лида уходят к одному человеку. Система при этом проверяет дополнительные условия — начат ли рабочий день у сотрудника, не превышен ли лимит активных лидов.

На схеме ниже — как входящий лид проходит проверку «новый / повторный» и попадает к нужному менеджеру.

flowchart TD
    A[Входящий лид] --> B{Клиент уже есть в CRM?}
    B -- Нет --> C[Назначить по кругу]
    B -- Да --> D[Вернуть прежнему менеджеру]
    C --> E{Менеджер доступен?}
    D --> E
    E -- Да --> F[Лид назначен]
    E -- Нет --> G[Перейти к следующему / резервный ответственный]

Подробнее о механике назначения читайте в статье про роботы и триггеры в воронке Битрикс24.

---

Стратегия 4. Контроль дублей через бизнес-процессы

Когда встроенных инструментов не хватает, в ход идут бизнес-процессы. Это актуально при нестандартной логике: например, лид считается дублем только в течение определённого периода, или проверка нужна только по конкретным источникам.

Типовая схема:

1. При создании лида автоматически стартует бизнес-процесс.
2. БП ищет совпадения по заданным полям — телефон, email, название.
3. При совпадении — переводит лид в стадию «Возможный дубль» и создаёт задачу ответственному.
4. Менеджер или администратор вручную решает: склеить карточки или оставить оба лида.

Гибкость есть, но человек нужен. Хорошо работает там, где автоматическое объединение рискованно: один телефон — несколько разных людей, семья, коллеги.

По нашему опыту, бизнес-процессный контроль лучше использовать как второй уровень защиты — после нормализации и автоматической проверки на этапе создания.

---

Стратегия 5. Предотвращение дублей на уровне интеграций с сайтом

Большинство дублей рождается не в CRM — они приходят с сайта. Форма отправляет заявку, Битрикс24 вызывает crm.lead.add и создаёт карточку, не проверив, есть ли такой клиент в базе.

Правильная архитектура интеграции:

1. Форма на сайте отправляет данные не напрямую в crm.lead.add, а сначала запускает поиск — crm.duplicate.findbycomm или аналогичный метод.
2. Клиент найден — данные формы обновляют существующую карточку.
3. Не найден — создаётся новый лид с передачей всех нужных полей: UTM-меток, адреса страницы, ClientID Яндекс Метрики.

Маркетинговые атрибуты при этом важно передавать с первого обращения — иначе при объединении дублей теряется информация об источнике.

Отдельная история — «фантомные» лиды из корзины сайта: интеграция передаёт некорректные CATEGORY_ID / STAGE_ID, обращается к удалённой стадии и порождает технические дубли. Здесь нужен аудит интеграции и прав доступа.

Логику дедупликации лучше описать заранее, ещё в техническом задании — о том, как правильно его структурировать, читайте в статье Структура ТЗ на доработку Битрикс24.

---

Как выбрать стратегию: сводная таблица

Стратегия	Когда подходит	Сложность реализации
Нормализация телефона + поиск перед созданием	Массовые входящие лиды, B2C	Средняя
Контроль по ИНН / названию компании	Корпоративные клиенты	Средняя
Правило «повторный → прежний менеджер»	Снятие конфликта без склейки	Низкая
Контроль через бизнес-процессы	Сложная логика, ручное решение	Высокая
Предотвращение на уровне интеграции с сайтом	Основной канал — сайт	Средняя/Высокая

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

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