Лиды с сайта в Битрикс24: вебхук, дубли и распределение по менеджерам

Два самых частых разговора про CRM на сайте звучат противоположно. Первый: «форму отправили, в Битрикс24 ничего нет». Второй: «один и тот же человек лежит четырьмя лидами, потому что заполнил формы на четырёх страницах». Оба случая — не про сайт и не про CRM по отдельности, а про то, как между ними устроена передача данных. Ниже — механика целиком: чем подключаться, что именно отправлять, как не плодить дубли и почему отправлять лид в момент нажатия кнопки — плохая идея.

У Битрикс24 два способа пустить сайт внутрь портала. Первый — входящий вебхук: в портале создаётся ссылка вида https://portal.bitrix24.ru/rest/1/абвгд.../crm.lead.add.json, сайт шлёт на неё POST, и лид появляется. Второй — локальное приложение с OAuth: сайт получает access_token и refresh_token и обновляет их сам.

Для передачи заявок с одного сайта в один портал вебхука достаточно, и девяносто процентов интеграций делаются на нём. Но у него есть две особенности, которые стоит знать до запуска. Первая: вебхук привязан к конкретному сотруднику и работает с его правами. Если этого сотрудника уволят и отключат от портала, интеграция умрёт вместе с ним — поэтому создавать вебхук нужно от служебного пользователя, а не от руководителя отдела продаж. Вторая: токен в ссылке — это и есть вся авторизация. Утёк токен — у человека появился доступ к CRM.

Приложение на OAuth нужно, когда порталов несколько, когда интеграция тиражируется на разных клиентов или когда требуются права шире, чем у одного пользователя. Это ощутимо больше работы, и на этапе внедрения Битрикс24 выбор между этими двумя вариантами стоит сделать осознанно, а не по умолчанию.

Технически сайт может создать что угодно: crm.lead.add, crm.contact.add, crm.deal.add. Решение зависит не от сайта, а от того, как устроена работа отдела продаж.

Ошибка, которую мы видим чаще всего: сайт создаёт лиды, а портал работает в «простом» режиме без лидов. Метод отвечает успехом, запись создаётся, но в интерфейсе её никто не видит, потому что раздел лидов в меню отключён. Поэтому до написания кода нужно открыть портал и посмотреть, какой режим CRM включён.

Минимум, который делает лид рабочим, а не строкой в списке:

Телефон и почта требуют аккуратности: это не строки, а мультиполя. Передали телефон строкой — он молча не запишется, лид появится без контактов, и менеджеру некуда звонить. Проверить формат проще всего через метод crm.lead.fields: он возвращает описание всех полей портала вместе с типами и списками значений, включая пользовательские поля с именами вида UF_CRM_....

Отдельная строка — идентификатор посетителя. Если в лид положить ClientID Яндекс.Метрики (он лежит в куке _ym_uid и достаётся через API счётчика), потом можно связать сделку в CRM с источником визита и передать офлайн-конверсию обратно. Без этого поля сквозной аналитики не будет, и собирать его нужно с первого дня, а не когда понадобится отчёт. Подробнее про то, что настроить заранее, мы писали в разборе веб-аналитики.

Битрикс24 умеет искать дубли сам, но только в интерфейсе и только по собственным правилам. Через REST это отдельный вызов — crm.duplicate.findbycomm: передаёте тип (PHONE или EMAIL), значение и список сущностей, где искать, получаете массив найденных идентификаторов.

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

Ключевое место, где этот механизм ломается, — формат телефона. +7 (999) 123-45-67, 8 999 123 45 67 и 79991234567 для поиска по совпадению разные строки. Поэтому номер нормализуется до отправки: убираем всё кроме цифр, приводим ведущую восьмёрку к семёрке, добавляем плюс. Эта пятистрочная функция убирает больше дублей, чем любая настройка в самой CRM.

Здесь важно договориться, кто принимает решение. Вариант первый: сайт ставит ASSIGNED_BY_ID сам — по региону, по типу услуги, по очереди. Вариант второй: сайт не ставит ответственного вообще, а распределение делают правила и роботы внутри CRM.

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

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

Самая распространённая и самая дорогая ошибка в таких интеграциях: обработчик формы вызывает REST Битрикс24 прямо в запросе и только после ответа показывает человеку «спасибо». Пока портал отвечает за сто миллисекунд, всё выглядит нормально. Но портал может отвечать две секунды, уйти на техобслуживание, вернуть ошибку лимита или просто не ответить.

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

Правильная последовательность такая:

У REST Битрикс24 есть ограничение по частоте запросов, и при превышении приходит ошибка о лимите. Для формы на сайте это неактуально, а вот для массовой выгрузки заказов или ночной синхронизации — очень. Очередь с паузами решает это сама, прямые вызовы в цикле — нет.

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

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

Мы подключаем сайты к Битрикс24 — формы, корзину, личный кабинет, обратную передачу статусов, — и чиним интеграции, которые делали до нас. Что входит в работу и как считается, смотрите на странице внедрения Битрикс24. Если CRM подключается к новому проекту, это считается частью разработки сайта, а не отдельной доработкой после запуска.