Дублирование лидов в Битрикс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. Если дублей нет - карточка сохраняется в штатном режиме.

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

Стратегия 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.

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

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

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

Частые вопросы