Лиды есть, продаж нет: где заявка теряется по дороге в отдел продаж

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

Два диагноза под одним словом «плохие лиды»

На совещании звучит одна фраза — «лиды плохие», — но за ней прячутся две разные проблемы.

Первая: заявка не доехала. Человек заполнил форму, увидел «Спасибо» и на этом исчез. В отделе продаж её нет не потому, что менеджер поленился, а потому, что карточки не существует. Это потеря на транспорте.

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

Чинятся они разным, а называются одинаково. Пока диагнозы не разведены, спор нерешаем: маркетинг показывает число из аналитики, продажи — число из CRM, и оба числа настоящие. Каждая сторона доказывает свою правоту в своей системе учёта, и обе доказывают успешно.

Признак, что дело в транспорте, простой: числа в двух системах не сходятся и никто не может объяснить разницу словами. Не «примерно похоже», а построчно. Если разница объясняется — проблема действительно в обработке, и искать утечку бессмысленно.

Дальше в статье — только транспорт. Примеры взяты на материале сайтов в B2B-маркетинге, где поток заявок обычно небольшой и каждая потерянная заметна в месячном отчёте, но механика одинакова для любой ниши.

Три числа, которые обязаны сойтись

Аудит начинается не с гипотез, а с трёх чисел за один и тот же период. Берите закрытый календарный месяц, а не «последние 30 дней»: границы периода в разных системах считаются по-разному, и часть расхождения объяснится именно этим, а не утечкой.

Число первое — сколько отправок формы зафиксировала веб-аналитика.

Число второе — сколько отправок сохранил сам сайт: журнал на стороне сервера, раздел заявок в конструкторе, письма в общем почтовом ящике.

Число третье — сколько карточек за этот период создано в CRM с источником «сайт».

Эти три числа не обязаны совпадать. Они обязаны объясняться: на каждую единицу разницы должна найтись причина, которую можно назвать вслух.

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

И сразу оговорка, из-за которой первое число почти всегда завышено, — про неё в разделе про форму. Если про неё забыть, аудит начнётся с ложного вывода «половина заявок теряется».

Как провести сверку за один период

Порядок действий, который занимает один рабочий день и не требует ничего, кроме доступов.

Дальше начинается собственно работа: разницу нужно объяснить построчно. Не «ну, часть отвалилась», а конкретно — эти четыре обращения ушли в спам, эти две отправки были повторными нажатиями одного человека, эта одна не прошла проверку на роботов.

Полезно с самого начала завести привычку: каждое необъяснённое расхождение — это открытый вопрос, а не допустимая погрешность. Погрешность появляется тогда, когда её механизм назван.

Где сверять и что значит расхождение

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

Таблица нужна не для красоты отчёта. Она задаёт последовательность: пока не сошлась первая строка, вторую разбирать бессмысленно, потому что неизвестна база, от которой считается потеря.

Звено первое: форма на сайте

Первое звено — сама форма и то, как её видит аналитика. Здесь ломается чаще всего, и здесь же чаще всего делается неверный вывод.

Возьмём цель типа «Отправка формы» в Яндекс Метрике. По справке Метрики форма определяется по наличию элемента form и некоторых параметров формы — идентификатора, имени или XPath-пути. Достижение засчитывается при нажатии на элемент button с типом submit или input с типом submit, расположенный внутри form. Для форм, которые обрабатываются скриптом, распознаётся только стандартное событие onSubmit.

Из этих требований следуют два противоположных сбоя.

Форма собрана не на теге form, а на наборе полей с обработчиком на кнопке — распространённая ситуация в самописных лендингах и в шаблонах, где дизайнер верстал вручную. Автоцель тогда не сработает никогда. Аналитика показывает ноль при живом потоке обращений, и по ней делается вывод, что реклама не приносит заявок.

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

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

Звено второе: капча

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

reCAPTCHA v3 работает без задания для посетителя и возвращает оценку каждого запроса. В документации Google: «The score is based on interactions with your site», диапазон от 0.0 до 1.0, где «1.0 is very likely a good interaction, 0.0 is very likely a bot». Порог отсечения выбираете вы сами — Google даёт лишь отправную точку: «By default, you can use a threshold of 0.5». И отдельно рекомендует то, что в реализациях обычно игнорируют: «take action behind the scenes instead of blocking traffic» — действовать незаметно, а не блокировать трафик.

Яндексовая SmartCaptcha устроена иначе, но с тем же исходом. По документации, сервис «проверяет запросы пользователей своими ML-алгоритмами и показывает задание только тем пользователям, запросы которых посчитает подозрительными»; если проверка не пройдена, серверная валидация возвращает status: failed.

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

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

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

Звено третье: письмо на почту

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

Google в справке для администраторов формулирует их как обязательные с 1 февраля 2024 года: настроить в отправляющих доменах аутентификацию SPF или DKIM, иметь действительные прямые и обратные записи DNS, использовать подключение TLS. Для отправителей больше 5000 писем в день — SPF и DKIM одновременно, плюс настроенный DMARC. Отдельным пунктом — следить, чтобы показатель «Доля попаданий в спам» в Postmaster Tools не превышал 0,3 %.

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

Второй риск бытовой: уведомление приходит на личный ящик сотрудника. Сотрудник в отпуске, уволился, поменял ящик, случайно нажал «Спам» на одном письме — и последующие уходят туда автоматически. Заявки при этом формально доставлены.

Третий риск — сайт не хранит копию. Contact Form 7, один из самых распространённых плагинов форм для WordPress, сообщений не сохраняет: в описании дополнения Flamingo на wordpress.org прямо сказано, что Contact Form 7 «doesn’t store submitted messages», и именно поэтому существует отдельный плагин-хранилище. У Тильды копия есть, но с ограниченным сроком: отправленные данные хранятся в разделе «Заявки», по умолчанию месяц, а в общих настройках форм период меняется на 1, 7, 60 или 90 дней либо сохранение отключается совсем.

Отсюда простое правило: почта не может быть единственным каналом доставки. Она хороша как уведомление и никуда не годится как система учёта.

Звено четвёртое: вебхук и интеграция

Между сайтом и CRM обычно стоит вебхук: сайт отправляет запрос, CRM его принимает. Или не принимает — и тогда всё зависит от того, что предусмотрено на этот случай.

Документация amoCRM описывает поведение при отказе достаточно подробно, чтобы на ней объяснять механику. «Наш сервис ожидает ответ от хука не более 2 секунд». Информация считается принятой, «если в заголовке http ответа будет возвращён код от 100 до 299». При неудачных ответах предусмотрены повторные попытки по расписанию. И отдельно описано условие отключения: «За последние 2 часа было получено более 100 невалидных откликов и последний хук на момент проверки так же является невалидным».

Три практических следствия из этих строк.

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

Двух секунд достаточно, чтобы потерять заявку в час пик. Всплеск нагрузки, соседний тяжёлый запрос, медленный ответ базы — и передача не состоялась. Именно поэтому важно, есть ли у вашей связки повторные попытки: без них однократный таймаут означает, что заявки нет нигде.

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

У конструкторов сайтов та же логика, но ошибки видны. У Тильды есть журнал ошибок в разделе заявок, и в справке перечислены конкретные типы: приемщик данных был удалён в момент отправки, приемщики в форме не активны, «Cannot find EMAIL or PHONE field» — приемщик требует переменные EMAIL или PHONE, «User was trying to send too big text» при объёме больше 5000 символов. Отдельный ответ в справке разбирает ситуацию, когда заявки не приходят, а журнал ошибок пуст: среди причин там названа неверная последовательность подключения приемщика к форме.

Звено пятое: лид в CRM, но не в воронке

Заявка может доехать до CRM и всё равно не попасть к менеджеру. Формально она есть, в выгрузке видна, а в работе её нет.

В amoCRM для этого существует «Неразобранное» — по документации, системный статус воронки сделок с дополнительными возможностями, куда попадают обращения четырёх категорий: чаты, почта, звонки и формы. Ключевая деталь: «До принятия неразобранной сделки, контакты и компании недоступны в соответствующих разделах». То есть менеджер, который ищет клиента по телефону в разделе контактов, его не найдёт — обращение существует, но живёт в отдельном накопителе, пока кто-то не примет его вручную.

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

Третий способ — ответственный. Карточка без ответственного не показывается никому конкретно; карточка с ответственным в отпуске лежит до его возвращения. Распределение по кругу решает первую проблему и усугубляет вторую, если в правиле не учтён график.

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

Звено шестое: каналы, которые в CRM не заходят

Самая крупная утечка обычно не в сломанной интеграции, а в каналах, которых в CRM нет вообще. Их не чинят, потому что их не считают.

Показательный пример — карточка организации в справочниках и картах. По справке Метрики, для компании в Яндекс Бизнесе автоматически создаётся отдельный счётчик, и в него попадают клики на звонок и просмотр номера, переходы на сайт, открытие чатов мессенджеров — WhatsApp, Telegram, Viber, — построение маршрута, бронирование и запись, заказы; данные приходят из Поиска, Карт, Навигатора и мобильных приложений. И там же сказано, что этот счётчик не отслеживает поведение посетителей на сайте.

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

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

Метод здесь один — инвентаризация точек входа. Выписать все места, где физически можно оставить обращение: формы сайта, все телефоны, все ящики, все мессенджеры, все карточки в справочниках, все площадки. Напротив каждой поставить, куда обращение попадает и кто его увидит. Строки без ответа — это и есть ненайденные заявки.

Звено седьмое: ночь, выходные и очередь

Заявка пришла в 23:40 в пятницу. Транспорт отработал безупречно: письмо доставлено, карточка создана, ответственный назначен. К понедельнику человек уже общается с кем-то другим.

Формально это не потеря на транспорте — карточка существует. Практически результат тот же, и считать это нужно тем же аудитом, потому что причина внешняя по отношению к менеджеру.

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

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

Чужие цифры вроде «отвечать надо за пять минут» мы сюда подставлять не будем. У продукта со сложной спецификацией и у бытовой услуги это разные величины, и проверяется это только своей выгрузкой. Если в вашей выгрузке конверсия у ночных заявок не отличается — значит, дежурство ночью вам не нужно, и это тоже результат.

Что при этом стоит сделать в любом случае — зафиксировать факт обращения автоответом. Он не заменяет звонок, но переводит ожидание из «мне не ответили» в «мне ответят утром», и оставляет отметку времени, по которой потом считается реакция.

Звено восьмое: дубли

Дубли — единственное место в списке, где заявка исчезает не по ошибке, а по замыслу. Защита от дублей работает ровно так, как её настроили, и иногда съедает настоящее обращение.

Начинается это ещё на сайте. У Тильды есть защита от повторной отправки: ошибка Double post data, по справке, возникает, когда «данные посланы повторно и совпадают с данными dataid:*, которые были ранее», и такие данные в приемщики не отправляются, а сохраняются только в самой ошибке. Посетитель, который нажал кнопку дважды из-за медленного интернета, получит одну заявку — это правильно. Посетитель, который через неделю отправил ту же форму с теми же данными, может получить ноль.

Продолжается в CRM. У CRM-формы Битрикс24 три режима работы с дубликатами — разрешить, заменять и объединять, а критерий сформулирован так: «Запись считается дубликатом, если совпадают любые два из трех параметров: ФИО или название компании, телефон, e‑mail».

Автоматическое объединение в Битрикс24 срабатывает при трёх условиях сразу: в карточках совпадают значения всех полей, за записи отвечает один сотрудник, лиды находятся на одной стадии канбана. Результат описан прямо: «После автоматического объединения элементов останется карточка, которая была создана раньше, а остальные удалятся». Удалённые карточки восстанавливаются из корзины CRM — но только если кто-то заметил пропажу.

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

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

Что чинить в каком порядке

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

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

Что в итоге

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

Сверка делается за один закрытый месяц по трём числам: отправки формы в аналитике, сохранённые отправки на стороне сайта, карточки в CRM. Разница не обязана быть нулевой — она обязана быть объяснённой построчно.

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

Хорошая новость в том, что почти всё это чинится настройкой, а не бюджетом. Плохая — что без сохранённого на стороне сайта журнала отправок починить нельзя ничего, потому что не с чем сравнивать. С него и стоит начать.