Кейс

Формы WordPress → Битрикс24: заявки перестали теряться в почте

Производитель кровельных материалов, Минск. Проект опубликован
обезличенно: разрешения на упоминание имени мы пока не спрашивали.

Что было

Сайт на WordPress, четыре формы: расчёт стоимости, вызов замерщика, вопрос
и заявка на обратный звонок. Все четыре отправляли письмо на общий ящик отдела
продаж. Дальше начиналось то, что на таких проектах происходит всегда:

  • письмо приходило троим, отвечал тот, кто первым увидел, — или никто;
  • часть писем оседала в «Промоакциях», потому что отправителем был
    wordpress@домен, за которым не стояло ни SPF, ни DKIM;
  • когда почтовый сервер отклонял письмо, форма всё равно показывала
    «спасибо» — заявка исчезала бесследно, и никто об этом не узнавал;
  • откуда пришёл клиент — из контекста, из поиска или по визитке —
    не знал никто.

Первое, что мы сделали, — посчитали масштаб. Сравнили количество отправок
формы в Яндекс.Метрике с количеством писем в ящике за тот же месяц. Разница
была двузначной.

Что сделали

Журнал заявок в базе сайта

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

Сделка в Битрикс24 вместо письма

Из журнала заявка уходит в портал как сделка: с источником, названием формы,
адресом страницы и UTM-метками кампании. Телефон заводится контактом
и привязывается к сделке — менеджер набирает прямо из карточки.

Метки, которые доживают до сделки

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

Антидубль по телефону

Один и тот же телефон за сутки не плодит новые сделки: повторное обращение
дописывается комментарием в уже открытую. Менеджер видит, что человек написал
второй раз, а воронка не забивается дублями одного клиента.

Повторная отправка

Если портал недоступен, заявка остаётся в журнале со статусом «не доехала»,
и раз в пятнадцать минут делается новая попытка. Параллельно уходит письмо —
уже с настроенной подписью домена, а не от wordpress@.

Что получилось

Мы не станем показывать «рост заявок на 40%»: количество обращений зависит
от рекламы и сезона, а не от нашей работы. Что действительно изменилось
и что можно проверить:

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

Что использовали

WordPress, собственный плагин приёма заявок, REST API Битрикс24
(crm.deal.add, crm.contact.add,
crm.timeline.comment.add), SPF, DKIM и DMARC на домене отправителя.

Другие работы

Проекты названы обезличенно там, где клиент не давал разрешения на публикацию.

Похожая задача?

Расскажите, что происходит с вашим сайтом. Посмотрим и скажем, наша это работа или нет.

+375