Для кого
Для сайта, который передаёт неполные заявки, теряет источники или создаёт дубли.
BITRIX24 И ПРОДАЖИ
Интеграция сайта с Битрикс24 без потери заявок
Интеграция должна доставить не только телефон, но и контекст обращения, а при сбое оставить проверяемый след. Для этого до разработки согласуются поля, идентификаторы, дубли, ответственные и обработка ошибок.
Что входит
Mapping, атрибуция, идентификация, назначение, журнал ошибок, повторы и тестовые сценарии.
Что получите
Документированную передачу заявок и способ обнаружить сбой до потери обращения.
Что нужно для старта
Формы сайта, поля Bitrix24, воронка, ответственные и доступ к журналам интеграции.
Какие данные передаются
Состав зависит от формы и процесса: контакты, компания, продукт, комментарий, страница, согласия и технический идентификатор. Маркетинговый контекст включает доступные UTM, yclid и источник. Для каждого значения указываем, вводит ли его пользователь, определяет сайт или добавляет сервер. Передаём только необходимые данные и не размещаем секреты в публичном коде. Сущность Bitrix24 — лид, сделка, контакт или компания — выбирается по принятой архитектуре CRM.
Mapping полей
Таблица сопоставляет поле формы, формат, обязательность и правило преобразования с конкретным полем CRM. Отдельно описываются справочники, множественные значения, файлы и значения по умолчанию. Mapping согласуют владелец сайта и администратор Bitrix24, чтобы изменение названия не нарушило обмен. Версия документа хранится вместе с кодом интеграции и контрольными примерами. Так ошибка может быть найдена по конкретному переходу, а не по общему сообщению «заявка не пришла».
UTM, yclid и источник
Рекламные параметры сохраняются при переходах до отправки формы по согласованному сроку. Правила first-touch и last-touch разделяются, если оба значения нужны отчётности. В CRM передаётся не произвольная строка, а согласованный набор полей, понятный маркетингу и продажам. Контрольный переход из объявления проверяет URL, cookie или серверное хранилище, событие формы и итоговую карточку. Отсутствующий идентификатор не заменяется вымышленным источником.
Правила дублей
Повторная заявка может дополнять существующий контакт, создавать новую сделку или возвращаться ответственному — решение зависит от продукта и интервала. Определяем ключ поиска, приоритет телефона и email, поведение при нескольких совпадениях и одновременных отправках. История обращения не должна исчезать при объединении. Сценарии дубля тестируются отдельно, включая повтор с другой услугой и изменение контакта. Правило документируется, чтобы сотрудники понимали ожидаемое поведение.
Назначение ответственного
Ответственный определяется по продукту, географии, расписанию, очереди или существующему клиенту. Если правило не сработало, карточка попадает в безопасную группу с уведомлением владельца процесса, а не остаётся без контроля. Интеграция создаёт задачу только после успешной записи и учитывает рабочие часы, если это требуется. Проверяем права назначенного сотрудника и его доступ к воронке, иначе технически созданная заявка всё равно не будет обработана.
Ошибки API и retry
До внешнего запроса сервер сохраняет обращение и UUID. Ответ API, код ошибки, время и число попыток попадают в защищённый журнал без лишних персональных данных. Повтор ограничен по количеству и задержке, чтобы не создать дубли или бесконечную нагрузку. Постоянная ошибка требует уведомления ответственного и ручного решения. Пользователь получает подтверждение только после безопасного сохранения, а не по факту нажатия кнопки.
Тестирование интеграции
Матрица охватывает формы, устройства, обязательные поля, разные источники, дубль, назначение, недоступность API и повтор. В каждой цепочке сверяем запись сайта, журнал, сущность CRM, значения полей, ответственного и задачу. После выпуска и очистки кэша повторяем публичный smoke, потому что локальная проверка не подтверждает работу производственного домена. Результат фиксируется с идентификаторами тестовых обращений, после чего их можно удалить по согласованному регламенту.
Эксплуатация и контроль после запуска
Интеграция получает владельцев со стороны сайта и CRM, описание журналов и порядок реакции на ошибку. После обновления формы, поля, вебхука или прав выполняется сокращённый набор контрольных заявок. Периодически проверяется свежесть успешных событий и наличие постоянных отказов API. Изменение mapping оформляется версией, чтобы старые и новые записи можно было интерпретировать. Если обращение содержит чувствительные данные, доступ к журналу и срок хранения ограничиваются. Такой регламент позволяет обнаружить нарушение обмена до того, как проблему заметит клиент или руководитель по отсутствующим продажам.
Границы ответственности сайта и CRM
Сайт отвечает за валидацию, безопасное сохранение, формирование контекста и документированный запрос. Bitrix24 — за приём, сущности, права, правила назначения и дальнейший процесс. Между ними остаётся API с кодами ответа и ограничениями. В матрице ответственности указано, кто реагирует на изменение поля, токена, формы или воронки. Благодаря этому ошибка локализуется по журналам, а команды не перекладывают её друг на друга без проверки конкретного идентификатора. Контрольная заявка подтверждает обе стороны перехода и назначенного владельца. Проверка завершается записью UUID.
КАК ПРОХОДИТ РАБОТА
Этапы работы
Этапы соответствуют задаче этой услуги. Состав и точки согласования уточняются до начала проекта.
- 01Форма
Определяем поля, валидацию и безопасное серверное сохранение обращения.
- 02Mapping
Сопоставляем данные сайта с сущностями и полями Bitrix24.
- 03UTM и yclid
Передаём доступный рекламный контекст вместе с обращением.
- 04Запись в CRM
Создаём или обновляем лид, контакт и сделку по согласованным правилам.
- 05Ответственный
Настраиваем распределение, задачу и срок первой реакции.
- 06Повтор и журнал
Сохраняем ошибку и безопасно повторяем передачу без дублей.
- 07Тесты
Проверяем формы, источники, повторные обращения и недоступность API.
РЕЗУЛЬТАТ
Что передаём по итогам работы
Состав результата фиксируется до старта и передаётся в формате, которым сможет пользоваться команда клиента.
Данные формы и их назначение в Bitrix24.
Запись, распределение, задача и уведомление.
Причина сбоя, повтор и защита от дублей.
Проверенные формы, метки и карточки CRM.
ВОПРОСЫ
FAQ
01Какие данные формы передаются в Bitrix24?
Контакты, услуга, страница, комментарий, UTM, yclid и технический идентификатор — только в согласованные поля.
02Как интеграция защищается от дублей?
Определяем ключ поиска клиента, правила повторного обращения и поведение при одновременной отправке нескольких форм.
03Что происходит при недоступности API?
Запись остаётся в локальном журнале, ошибка фиксируется, а повтор выполняется по ограниченному безопасному сценарию.
04Как проходит приёмка передачи заявок?
Отправляем формы с разных страниц и устройств, сверяем поля, источник, ответственного, статус и запись об ошибке.
СЛЕДУЮЩИЙ ШАГ
Получить схему передачи данных
Опишите процесс продаж и текущий портал. Уточним границы настройки, внедрения или сопровождения Bitrix24.