Заявки с сайта не доходят до CRM: причины и как найти потерянные лиды

Почему потери лидов так трудно заметить

Заявка, которая не дошла до CRM, не оставляет следа там, где её ждут. Менеджер не видит несуществующей карточки и не знает, что кто-то пытался с вами связаться. Клиент, не получивший ответа, как правило, не пишет повторно, а идёт к конкуренту. В результате о потере знает только человек, которого проигнорировали, а он ничего не расскажет.

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

Причины на стороне сайта и формы

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

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

Причины на стороне интеграции

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

К потерям приводят и технические ограничения: у многих CRM есть лимиты на количество запросов в единицу времени, и во время рекламной кампании поток может превысить допустимый порог. Временная недоступность CRM или сбой на стороне посредника (сервиса, который передаёт данные между сайтом и CRM) тоже вызывают пропажи, если у интеграции нет механизма повторной отправки. Поэтому качество интеграции определяется не тем, как она работает, когда всё хорошо, а тем, что происходит, когда что-то пошло не так. Про связку мессенджеров и CRM мы подробно рассказывали в статье про интеграцию WhatsApp и Instagram с CRM.

Причины на стороне самой CRM

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

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

Как понять, что заявки теряются: сверка источников

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

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

Пошаговая диагностика

Когда подозрение возникло, действуйте последовательно, от простого к сложному, и не меняйте несколько вещей одновременно, иначе вы не поймёте, что именно помогло.

• Отправьте тестовую заявку с разных устройств и браузеров, включая мобильный телефон и режим без расширений, и проследите, появляется ли она в CRM. Используйте разные данные, чтобы исключить срабатывание проверки на дубли.
• Проверьте, что видит пользователь. Открывает ли форма сообщение об успехе и отправляется ли запрос на самом деле. В инструментах разработчика браузера видно, уходит ли запрос и какой ответ приходит от сервера.
• Посмотрите журналы. Журнал сайта покажет, дошла ли заявка до сервера и была ли попытка передачи в CRM. Во многих CRM есть журнал входящих запросов или интеграций, где видны отклонённые обращения и причины ошибок.
• Проверьте доступы интеграции: не истёк ли токен, не отозван ли ключ, не сменился ли пользователь, от имени которого работает подключение.
• Сверьте поля формы и поля CRM. Не появились ли обязательные поля, не изменились ли названия и типы данных, не добавились ли новые ограничения.
• Проверьте правила CRM: дубли, распределение заявок, роботы и автоматические сценарии, фильтры в списках, архивные воронки.
• Убедитесь, что формы не блокируются защитой: капчей, антиспамом, политикой безопасности браузера, а также что скрипты передачи данных не режутся блокировщиками.
• Свяжите находку с датой. Определите, когда начались потери: после обновления сайта, смены сотрудника, изменения в CRM или начала рекламной кампании. Дата почти всегда указывает на причину.

Как найти и вернуть уже потерянные лиды

Когда причина устранена, остаётся вернуть то, что потеряно. Начните с источников, где копия заявки могла сохраниться: журнал сайта и базы данных формы, письма-уведомления, чат с уведомлениями, рекламные кабинеты, которые хранят данные о лидах, система сквозной аналитики и подмены номеров, журнал АТС и история мессенджеров. Из них можно собрать список контактов за период, когда интеграция не работала.

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

Как не допустить потерь: защита от повторения

Главный принцип надёжной интеграции - заявка не должна исчезать, даже если что-то сломалось. На практике это означает несколько вещей. Сайт должен сохранять каждую заявку у себя до того, как получит подтверждение, что CRM её приняла, и повторять отправку, если подтверждения нет. Так временный сбой не превращается в потерю. Ошибки должны сообщаться людям: если передача не удалась, ответственный получает уведомление, а не узнаёт об этом через неделю. Хорошая практика - дублировать заявку в резервный канал, например на почту или в рабочий мессенджер, чтобы у менеджеров оставался путь к клиенту, даже если CRM недоступна.

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

Чьё это дело: ответственность и процесс

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

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

Частые ошибки

Самая распространённая ошибка - считать интеграцию «сделанной раз и навсегда». Сайт, CRM и внешние сервисы меняются, и подключение, работавшее год назад, может молча перестать работать после обновления любой из частей. Вторая ошибка - полагаться только на CRM как на единственный источник правды и не сравнивать её данные с аналитикой, рекламными кабинетами и журналом сайта.

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

Чек-листы