Где на самом деле теряются заявки с сайта
Разговор про интеграцию WordPress с CRM почти всегда начинается не с технологий, а с неприятного открытия: в отчёте отдела продаж заявок меньше, чем в статистике сайта. Разрыв в 20 — 30% — обычное дело для компаний, которые до сих пор принимают обращения на почту.
Стандартная связка выглядит так: посетитель заполняет форму, плагин отправляет письмо на общий ящик вроде info@, кто-то из менеджеров это письмо видит и вручную заводит клиента в CRM. Каждое звено здесь — потенциальная точка отказа, и почти все они молчаливые: система не сообщает, что заявка пропала.
Почтовая доставка. WordPress по умолчанию отправляет письма функцией wp_mail(), которая на большинстве хостингов опирается на локальный sendmail. Такие письма легко попадают в спам или отбрасываются принимающим сервером, особенно если у домена не настроены SPF, DKIM и DMARC. Самое коварное: на стороне сайта отправка считается успешной — плагин показывает посетителю «Спасибо, мы свяжемся с вами», а письма не существует.
Человеческий фактор. Даже если письмо дошло, дальше его должен обработать человек. В пятницу вечером, во время отпуска ответственного менеджера или в день, когда пришло 40 обращений вместо привычных пяти, часть писем просто останется непрочитанной. Общий ящик — это не очередь задач, у него нет статусов и нет контроля исполнения.
Потеря контекста. Письмо содержит имя и телефон. Оно не содержит, с какой рекламной кампании пришёл человек, какую страницу он читал перед обращением, какой была метка UTM. Через месяц, когда придёт время считать стоимость лида по каналам, восстановить эту информацию будет уже нечем.
Отсутствие фактов о скорости реакции. Пока заявки живут в почте, невозможно ответить на простой управленческий вопрос: сколько в среднем проходит от обращения до первого звонка. А это, как правило, самая дешёвая точка роста конверсии из всех имеющихся.
Интеграция сайта с CRM закрывает все четыре проблемы одним движением: заявка попадает в систему автоматически, вместе с контекстом, сразу назначается на ответственного и сразу начинает измеряться.
Четыре способа связать WordPress с CRM
Технически задача решается несколькими путями, и они заметно различаются по стоимости, гибкости и требованиям к поддержке. Выбор зависит от того, насколько сложен ваш сценарий продаж и сколько форм на сайте.
Способ 1. Встроенная форма самой CRM
Самый быстрый вариант: форма создаётся на стороне CRM, а на сайт вставляется готовый код. У Битрикс24 это CRM-формы — в настройках формы берётся код для размещения, и документация предлагает три варианта публикации на стороннем сайте: форма как блок на странице, форма во всплывающем окне по клику на кнопку и форма, появляющаяся через заданное время после загрузки страницы.
Плюсы очевидны: писать код не нужно, данные попадают в CRM гарантированно, потому что промежуточных звеньев просто нет. Поля формы редактируются в интерфейсе CRM без правки сайта.
Минусы тоже реальные. Внешний виджет тянет за собой сторонний скрипт, что влияет на скорость загрузки страницы и на показатели Core Web Vitals. Внешний вид формы настраивается в пределах того, что даёт конструктор CRM, и полностью попасть в дизайн сайта удаётся не всегда. И если у вас уже есть отлаженные формы на WordPress с валидацией, масками ввода и логикой показа полей, менять их на виджет — это шаг назад.
Способ 2. Вебхук из плагина форм
Более аккуратный путь: форма остаётся вашей, но плагин после отправки сам стучится в CRM. Часть популярных плагинов умеет это из коробки.
У Gravity Forms есть отдельное дополнение Webhooks: настраивается через Form Settings → Webhooks, поддерживает методы GET, POST, PUT, PATCH и DELETE, отправку данных в формате JSON или FORM, произвольные заголовки для авторизации и условную логику — то есть вебхук можно запускать только при выполнении заданных условий. Дополнение доступно на лицензии Elite или Nonprofit.
У WPForms аналогичное дополнение Webhooks включено в тариф Elite и настраивается в форме через Settings → Webhooks.
Это хороший выбор, когда у вас уже куплена соответствующая лицензия и сценарий простой: одна форма — один лид. Когда логика усложняется (разные формы должны создавать разные типы сущностей, нужна предварительная проверка данных, нужна дедупликация по телефону), настроек интерфейса начинает не хватать.
Способ 3. Собственный код на хуках плагина форм
Самый гибкий вариант и наш рабочий выбор для проектов, где заявки — основной источник выручки. Плагин формы даёт событие, на которое можно повесить свою функцию, а WordPress даёт стандартный HTTP-клиент для запроса в CRM.
В Contact Form 7 — плагине с более чем 10 миллионами активных установок — данные отправленной формы доступны через объект WPCF7_Submission: экземпляр получают вызовом WPCF7_Submission::get_instance(), значения полей — методом get_posted_data(). Прямое обращение к свойству с данными разработчик плагина закрыл, работать нужно через метод. Подключаться удобно к хуку wpcf7_before_send_mail. Важная деталь из документации: в $posted_data попадают не все данные из $_POST — служебные поля вроде идентификатора формы и ответа на капчу оттуда исключены.
Отправка наружу делается функцией wp_remote_post(). Она принимает URL и массив аргументов, где задаются body, headers, timeout и другие параметры запроса, а возвращает либо массив с ответом, либо объект WP_Error. Если URL хоть в какой-то степени формируется из пользовательского ввода, документация WordPress прямо рекомендует использовать wp_safe_remote_post().
Стоимость такого решения — часы разработчика и необходимость сопровождать код при обновлениях. Взамен вы получаете полный контроль: можно проверить данные до отправки, дописать любые поля, обработать ошибку CRM и не потерять заявку, если сервер CRM в этот момент недоступен.
Способ 4. Промежуточный сервис-коннектор
Zapier, Make, Albato и аналоги позволяют собрать связку мышкой: форма отправляет данные в сервис, сервис кладёт их в CRM. Разумно, когда у компании десяток разрозненных инструментов и нужно связать не только сайт с CRM, но и CRM с мессенджерами, таблицами, рассылками.
Ограничения — абонентская плата, зависящая от числа операций, дополнительная точка отказа между сайтом и CRM и вопрос о том, где физически обрабатываются персональные данные ваших клиентов. Для компаний, работающих в Казахстане с чувствительными данными, последний пункт стоит обсудить с юристом до внедрения, а не после.
Что передавать в CRM, кроме имени и телефона
Типичная интеграция передаёт три поля: имя, телефон, комментарий. Через полгода выясняется, что этого категорически мало для управления маркетингом. Список того, что стоит закладывать сразу:
- Метки UTM. Метод
crm.lead.addв Битрикс24 принимаетUTM_SOURCE,UTM_MEDIUM,UTM_CAMPAIGN,UTM_CONTENTиUTM_TERMкак отдельные поля — их не нужно складывать в текстовый комментарий. Чтобы метки дожили до момента отправки формы, их сохраняют в cookie или sessionStorage при первом заходе и подставляют в скрытые поля формы. - Страница обращения. Полный URL страницы, с которой ушла заявка. Заявка с карточки услуги и заявка из подвала главной — это разные по прогретости обращения, и менеджер должен видеть разницу до звонка.
- Источник. В Битрикс24 за это отвечает поле
SOURCE_IDс предустановленными значениями — CALL, WEB, ADVERTISING и другими. Проставленный источник избавляет от ручной разметки лидов и делает воронку по каналам достоверной. - Идентификатор формы. Если на сайте пять форм, в CRM должно быть видно, какая именно сработала. Это заодно спасает при отладке.
- Реферер и первый заход. Полезно для длинных циклов сделки, где человек приходит на сайт три-четыре раза перед обращением.
Правило простое: собирать данные надо в момент, когда они есть. Восстановить UTM-метку задним числом невозможно, а стоит она ноль, если предусмотрена в схеме с самого начала.
Как выглядит связка WordPress и Битрикс24 на практике
Разберём наиболее частый в нашей практике сценарий: сайт на WordPress с формами Contact Form 7, CRM — облачный Битрикс24.
Точка входа со стороны CRM — входящий вебхук. Это упрощённый способ обращаться к методам REST API в пределах одного портала. Его URL имеет структуру вида https://ваш-портал.bitrix24.kz/rest/{ID пользователя}/{секретный код}/{метод}.json, и он не имеет срока действия. Отсюда два практических следствия. Первое: секретный код в этом URL — это фактически ключ доступа к вашей CRM, его нельзя держать в открытом виде в теме сайта или в публичном репозитории. Второе: вебхук выполняется от имени того пользователя, который его создал, поэтому создавать его нужно под учётной записью с осмысленным набором прав, а не «под директором на всякий случай».
Метод, который создаёт лид, — crm.lead.add, ему требуется право crm. Он принимает TITLE, NAME, а телефон и почту — в множественном формате полей CRM. В документации Битрикс24 этот метод помечен как устаревший в пользу универсального crm.item.add, при этом остаётся рабочим. В crm.item.add тип создаваемой сущности задаётся числовым параметром entityTypeId: лид — 1, сделка — 2, контакт — 3, компания — 4, счёт — 31. Для новых интеграций мы закладываем универсальный метод: он же покрывает смарт-процессы, если позже понадобится складывать обращения не в лиды, а в отдельный процесс.
Дальше — вопрос архитектуры на стороне сайта, и здесь есть один принципиальный момент. Прямой синхронный запрос из обработчика формы означает, что посетитель ждёт ответа CRM. Если портал отвечает медленно, человек видит подвисшую форму. Если портал недоступен, заявка исчезает вместе с ошибкой.
Поэтому мы всегда делаем два дополнительных элемента. Первый — собственная таблица или пользовательский тип записи в базе WordPress, куда обращение пишется до попытки отправки в CRM. Второй — отложенная повторная отправка тех записей, по которым CRM вернула ошибку. Сайт в этой схеме становится буфером: даже если портал лежал полчаса, ни одна заявка не потеряна, они уедут следующей попыткой.
Пример из работы с производственной компанией в Алматы: на сайте стояли четыре формы, все отправляли на общий почтовый ящик. После настройки интеграции и сравнения журнала сайта с фактическими карточками в CRM выяснилось, что часть обращений с формы на странице прайса раньше вообще не доходила до менеджеров — письма отсекались фильтром принимающего сервера, и никто об этом не знал, потому что сайт исправно показывал сообщение об успешной отправке. Это типичная история, и находится она ровно в тот момент, когда появляется журнал обращений на стороне сайта.
Если вы планируете такую связку, но не хотите разбираться в вебхуках и правах доступа самостоятельно — это как раз то, чем мы занимаемся: разработка и доработка сайтов под ключ, включая интеграции с CRM и последующую поддержку.
Дубли и спам: две проблемы, которые приходят вместе с автоматизацией
Как только заявки начинают попадать в CRM без участия человека, всплывают два побочных эффекта.
Дубли. Клиент отправил форму, не получил быстрого ответа, отправил ещё раз. В CRM появились два лида, их взяли в работу два менеджера — и клиенту звонят дважды. Лечится проверкой перед созданием: ищем существующую запись по телефону или почте за последние сутки и, если находим, дописываем комментарий в существующую сущность вместо создания новой. Логика того, что считать дублем, — это бизнес-решение, а не техническое, и его нужно проговорить с руководителем отдела продаж до разработки.
Спам. Пока заявки шли на почту, спам отсеивал почтовый фильтр и глаз менеджера. В CRM он попадёт напрямую и начнёт портить статистику конверсии. Contact Form 7 поддерживает несколько механизмов защиты: reCAPTCHA от Google, Akismet и Turnstile от Cloudflare. Разработчик плагина отдельно предупреждает, что при включении этих механизмов данные отправителя формы уходят внешним сервисам — это стоит отразить в политике конфиденциальности сайта. Дополнительно помогают простые серверные проверки: скрытое поле-ловушка, которое заполняют только боты, и отсечение отправок, произошедших слишком быстро после загрузки страницы.
Как убедиться, что интеграция действительно работает
Настроенная интеграция — не то же самое, что работающая. Она ломается тихо: после обновления плагина форм, после смены структуры полей в CRM, после того как у пользователя, создавшего вебхук, отозвали права. Никакого сообщения об этом вы не получите — просто заявки перестанут приходить.
Минимальный набор мер, который мы закладываем в каждый проект:
- Журнал отправок на стороне сайта. Что отправили, когда, что ответила CRM, какой идентификатор сущности получили в ответ. Без этого любой разбор «была заявка или нет» превращается в спор без доказательств.
- Уведомление об ошибках. Если CRM вернула ошибку или запрос не прошёл — письмо или сообщение в мессенджер ответственному. Молчаливая ошибка страшнее громкой.
- Регулярная контрольная отправка. Раз в сутки автоматически создаётся тестовое обращение и проверяется, что оно доехало. Это ловит поломку в тот же день, а не через неделю по жалобе отдела продаж.
- Сверка цифр раз в месяц. Количество отправок формы по данным аналитики сайта против количества созданных сущностей в CRM. Расхождение больше нескольких процентов — повод разбираться.
Сверка полезна ещё и потому, что заодно находит проблемы за пределами техники: например, формы, которые давно ни разу не сработали, — их либо не видят посетители, либо они сломаны вёрсткой.
Типичные ошибки при интеграции
Отключить письма сразу после запуска интеграции. Первые две-три недели стоит оставить дублирующую отправку на почту. Это дешёвая страховка на период, когда интеграция ещё не проверена реальной нагрузкой.
Хранить секретный ключ в теме. Вебхук, лежащий в файле темы, уезжает в бэкап, попадает разработчику подрядчика и остаётся у бывшего сотрудника. Ключи должны храниться вне репозитория и вне публично доступных директорий, а при смене подрядчика — перевыпускаться.
Передавать всё одним текстовым полем. Слепить имя, телефон, UTM и страницу в комментарий — самый быстрый способ сделать интеграцию, которая не даёт ни автоматизации, ни аналитики. По полям CRM ничего не отфильтруешь и не построишь отчёт.
Не назначать ответственного. Лид без ответственного лежит в общем списке до тех пор, пока кто-нибудь случайно не заметит. Правило распределения нужно определить до запуска, даже если это простое «все на одного руководителя отдела».
Считать интеграцию разовой работой. Сайт живёт: добавляются страницы, меняются формы, запускаются посадочные под акции. Каждая новая форма должна попадать в ту же схему передачи данных, иначе через год половина обращений снова уйдёт мимо CRM.
Частые вопросы
Нужно ли переделывать существующие формы на сайте?
Обычно нет. Если формы сделаны на распространённом плагине, интеграция подключается к событию отправки, а сама форма и её внешний вид остаются прежними. Переделка требуется, если формы собраны нестандартно и не дают точки подключения.
Сколько времени занимает интеграция WordPress с CRM?
Простой вариант — одна-две формы, создание лида, передача UTM — делается быстро. Основное время уходит не на код, а на согласование: какие поля передавать, что считать дублем, кто ответственный за новую заявку. Чем чётче эти ответы даны до старта, тем короче работа.
Что произойдёт с заявкой, если CRM в этот момент недоступна?
В корректно спроектированной интеграции — ничего страшного: обращение сохраняется на стороне сайта и повторно отправляется, когда CRM ответит. В интеграции без буфера заявка будет потеряна. Это ключевой вопрос, который стоит задать подрядчику до начала работ.
Можно ли обойтись без программиста?
Да, если вас устраивает виджет формы самой CRM или у вас есть лицензия плагина форм с поддержкой вебхуков и простой сценарий. Как только появляются проверка дублей, разная логика для разных форм и защита от потери данных — нужен разработчик.
Куда лучше складывать обращения с сайта — в лиды или сразу в сделки?
Это зависит от того, как устроены ваши продажи. Если обращения нужно квалифицировать перед работой — в лиды. Если каждое обращение сразу считается потенциальной продажей и цикл короткий — можно сразу в сделку. Универсальный метод создания сущностей в Битрикс24 позволяет выбрать тип, так что технически это вопрос одного параметра, а не переписывания интеграции.
Сохранится ли интеграция после обновления WordPress?
Обновление ядра WordPress на такую связку обычно не влияет. Риск создают крупные обновления самого плагина форм, где меняются хуки. Поэтому обновления форм на боевом сайте стоит проводить с проверкой отправки после установки — это пять минут работы, которые экономят недели непойманных потерь.
Пока заявки живут в почте, отдел продаж работает вслепую: непонятно, сколько обращений было на самом деле, откуда они пришли и как быстро на них ответили. Как только данные начинают попадать в CRM автоматически и с контекстом, эти цифры появляются, и можно решать, что улучшать в первую очередь. Начинать имеет смысл с малого: подключить одну самую конверсионную форму, проверить, что она стабильно работает неделю, и только потом распространять схему на весь сайт.