Не приходят заявки с сайта: форма отправлена, а в CRM пусто

Содержание

• Тестовая заявка: что сделать и что искать
• Что должно быть в сделке
• Почему не приходят заявки с сайта: пять мест, где заявка теряется молча
• Защита от спама отбросила заявку и ответила «успешно»
• CRM не ответила, и запасной путь мёртв
• Переадресация съела данные
• Вебхук отозван, права сменились, настройка пропала
• Телефон короче нужного и форма, которая молчит
• Цели Метрики считают нажатия кнопки, и целей больше, чем заявок
• Сверка потока: каждый день и по часам в день перемен
• Как сменить канал заявок и ничего не потерять
• Двойники и повторные заявки - разные вещи
• Оповещение в Telegram: второй взгляд на поток
• Что сделать сегодня

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

Речь здесь только о первом отрезке пути: от кнопки на сайте до карточки в Битрикс24. Как заявки теряются внутри компании, когда они уже в CRM, разобрано в статье про потерянные заявки. Как подключить к CRM телефон, мессенджеры и другие каналы, - в обзоре интеграций для заявок.

Тестовая заявка: что сделать и что искать

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

1. Откройте сайт как посетитель, без входа в админку. Если проверяете и привязку к рекламе, зайдите по адресу с метками, например ?utm_source=test&utm_medium=cpc. Подождите несколько секунд и только потом жмите кнопку: слишком быструю отправку защита может принять за бота.
2. Заполните форму как тест: имя вроде «ТЕСТ - не звонить», заведомо выдуманный телефон, галочка согласия. Выдуманный номер нужен, чтобы тест не прилип к настоящему клиенту.
3. Если на сайте стоит Метрика, попросите разработчика на время проверки отключить отправку целей. Иначе тестовая заявка попадёт в статистику рекламы как настоящая.
4. Засеките, сколько форма думает перед ответом. Если форма ждёт подтверждения от CRM, ответ приходит через пару секунд. Мгновенный ответ - повод спросить, ждёт ли форма хоть чего-то или показывает «успех» по умолчанию.
5. Найдите сделку в CRM и сверьте с таблицей ниже.
6. Удалите тест. Сначала выгрузите карточки сделки и контакта, потом удалите оба. Контакт удаляйте, только если его создала эта же заявка: сверьте дату создания.

Пройти придётся все формы. Их на сайте обычно не одна: всплывающие окна, форма в подвале, подписка, резюме, квиз, калькулятор. Даже если все они устроены одинаково, убедиться в этом можно только тестом.

Что должно быть в сделке

Если CRM работает в классическом режиме, заявка с сайта может прийти лидом, а не сделкой: тогда ищите её в разделе лидов. В простом режиме лидов нет, и обращение сразу становится сделкой. Не зная режима, легко решить, что заявка пропала, хотя она лежит в соседнем разделе.

Почему не приходят заявки с сайта: пять мест, где заявка теряется молча

У всех пяти случаев общая черта: посетитель видит «Спасибо», а ошибки нет нигде.

Защита от спама отбросила заявку и ответила «успешно»

Типичная защита ловит ботов несколькими способами: скрытое поле, которое человек не видит и не заполняет, слишком быстрая отправка, проверка, что в браузере работает скрипт. Нарушил правило - заявка отброшена. Ответ при этом делают «успешным», чтобы бот не понял, что его раскусили.

Беда в том, что под эти правила иногда попадает и живой человек. У него отключены скрипты, браузер сам заполнил скрытое поле, страница пришла из кэша. Он видит «Спасибо», менеджер не видит ничего.

Что делать: пусть каждое отбрасывание пишется в журнал с причиной и временем, а журнал хранится там, куда посторонним не добраться. Раз в неделю его стоит просматривать глазами. Если там похожие на настоящие заявки (осмысленное имя, нормальный телефон), правило срабатывает не на тех. Второй нужный журнал - копия каждой принятой заявки на стороне сайта. Если CRM не ответила, это единственная копия.

CRM не ответила, и запасной путь мёртв

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

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

Переадресация съела данные

Самый неочевидный случай. Внешний сервис отправляет данные на ваш адрес, а в ответ получает «перейдите по другому адресу» вместо «принято». Обычно так бывает, когда в настройках сервиса стоит адрес без www, а сайт сам переводит на адрес с www. Или стоит http вместо https.

Что при этом происходит с данными, описано в справке MDN: получив ответ 301 на запрос POST, клиент отправляет следующий запрос методом GET, и спецификация HTTP это разрешает. У GET нет тела, поэтому данные заявки остаются в первом запросе и пропадают. Метод сохраняется только при переадресации 308.

В настройках любого внешнего сервиса указывайте окончательный адрес, по которому ответ приходит без единой переадресации. Разработчик проверит это одной командой.

Вебхук отозван, права сменились, настройка пропала

Сайт обычно отправляет данные в Битрикс24 через входящий вебхук. По справке Битрикс24, в адресе вебхука зашит идентификатор сотрудника, который его создал, секретный код видит только создатель, а указывать этот код в коде страницы или скрипта нельзя. Созданные вебхуки перечислены в разделе «Разработчикам» на вкладке «Интеграции». Обычный сотрудник видит там только свои.

Раз вебхук связан с конкретным сотрудником, после его увольнения или смены прав стоит проверить, работает ли вебхук. Справка прямо об этом не пишет, но проверка занимает минуту. Вторая ловушка - настройки сайта. Файл с адресом вебхука могут перезаписать при выкладке новой версии или при обновлении. Тогда перестают доходить сразу все заявки со всех форм, и снаружи это ничем не видно.

Телефон короче нужного и форма, которая молчит

Если искать клиента по неполному номеру, заявка может прилипнуть к чужой карточке. Поэтому при обрезанном номере сайт разумнее не искать клиента вовсе. Но тогда менеджер видит сделку без клиента и без номера, по которому можно позвонить. Помогает маска ввода телефона прямо в форме: человек просто не сможет отправить половину номера.

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

Цели Метрики считают нажатия кнопки, и целей больше, чем заявок

Цель в Яндекс Метрике на форму обычно привязывают к моменту отправки. Справка Метрики показывает именно такой пример: вызов цели стоит в атрибуте onsubmit формы. Цель сработает, даже если сервер потом отбросит заявку, поэтому целей почти всегда больше, чем сделок.

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

Для проверки доставки Метрика полезна как раз тем, что считает независимо от CRM. Что сломалось на сайте между нажатием кнопки и сделкой, она покажет разницей.

Сверка потока: каждый день и по часам в день перемен

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

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

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

Ещё два замечания. Журналы на хостинге хранятся недолго, часто всего несколько суток. Узнайте срок у своего и не откладывайте разбор, иначе причину уже не найти. И проверку тоже надо проверять. Скрипт сверки может читать не тот журнал, в который пишет сайт, и неделями честно отвечать «ошибок нет». Запишите в журнал заведомую ошибку и убедитесь, что скрипт её видит.

Как сменить канал заявок и ничего не потерять

Так в той компании переводили заявки с внешнего сервиса сквозной аналитики на прямую отправку в Битрикс24. Порядок подойдёт для любой смены канала.

1. Сначала параллельно. Новый путь включают рядом со старым, но он пишет в отдельную тестовую воронку. Боевые сделки по-прежнему создаёт старый. В нашем случае так прожили почти три недели.
2. Сверяют двойников. Каждая настоящая заявка теперь есть дважды: в боевой воронке и в тестовой. Двойники должны совпасть по клиенту, полям и меткам. Расхождения и есть список ошибок нового пути.
3. Переключают настройкой, код не трогают. Один переключатель меняет несколько параметров сразу. Перед правкой делают копию файла настроек, после правки проверяют, что сайт работает, и сразу прогоняют тестовую заявку из этой статьи.
4. Старый путь остаётся страховкой. Он срабатывает, только если новый не ответил. Двойники в боевой воронке после переключения значат, что включены оба пути сразу.
5. Время выбирают заранее: утро рабочего дня, когда есть кому смотреть. Контрольные сверки назначают сразу, например через три часа и вечером.
6. Кто решает про откат, договариваются до переключения. Если что-то пошло не так, сначала собирают факты и два-три варианта (откат, точечная правка, наблюдение), потом решает тот, кто отвечает за результат. Поспешный откат без фактов часто ломает больше, чем исходная проблема.

Двойники и повторные заявки - разные вещи

Двойник - техническая ошибка: две сделки на одну отправку. Повторная заявка - клиент вернулся и отправил форму снова. Для повторных полезно отдельное правило, например такое, как в той компании: если у клиента уже есть открытая сделка, новая не создаётся. В старую пишется комментарий «Повторная заявка с сайта», а ответственному ставится дело связаться в течение двух часов. Закрытые сделки повторами не считаются: клиент вернулся, значит, началась новая история. Клиента ищут только по полному номеру телефона.

В примере из документации Битрикс24 для разработчиков каждая отправка формы создаёт новый лид, так что без своего правила дубли неизбежны. Защиту от автоматических отправок там советуют добавлять отдельно.

Оповещение в Telegram: второй взгляд на поток

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

Несколько деталей, которые пригодятся при настройке:

• бот ждёт полторы минуты после создания сделки: метки и идентификатор дописываются чуть позже;
• с десяти вечера до восьми утра сообщения приходят без звука;
• если разом появилось больше восьми сделок, это похоже на импорт, и бот шлёт одну строку вместо лавины;
• из личных данных в сообщение идёт только имя, а от телефона видны две последние цифры. Telegram - зарубежный сервис, и компания решила не отправлять туда больше данных клиентов, чем нужно для работы. Общие правила для сайта - в чек-листе по персональным данным.

Оповещение смотрит на CRM. Если заявка до CRM не дошла, оно промолчит так же, как менеджер, поэтому сверку с Метрикой не заменяет. Они ловят разное: Метрика - заявки, которых нет в CRM, оповещение - сделки, о которых менеджер мог не узнать.

Что сделать сегодня

1. Отправьте тестовую заявку с каждой формы сайта и проверьте сделку по таблице выше.
2. Спросите разработчика, пишутся ли журнал отброшенных заявок и копия принятых, и загляните в них.
3. Выясните, есть ли запасной путь, жив ли он и кто платит за сервис, через который он идёт.
4. Проверьте адреса приёма у всех сервисов, которые шлют вам данные: с www или без, http или https, нет ли переадресации.
5. Первую неделю сверяйте Метрику и CRM каждый день, потом реже.
6. Если в CRM уже есть сделки с сайта без клиента или с пустыми метками, начните с них: такие карточки показывают, какой путь работает неполно.

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