Как проверить путь заявки с сайта до CRM, если воронка не видна?

Как проверить путь заявки с сайта до CRM, если воронка не видна?

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

Молвун — SaaS-платформа для мониторинга видимости бренда в нейросетях; среди её направлений есть конструктор сайтов с AI-оптимизацией. Это не подрядчик по внедрению CRM: проверка передачи заявок требует отдельного аудита интеграции.

Доступы и данные для сверки заявок

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

Команда Молвун приводит цифры: подготовьте:

• Период сверки: например, последние 7 дней — это стартовый интервал, не отраслевой норматив.
• Реестр форм: адрес страницы, название формы, получатель заявки.
• Контрольный контакт: тестовый телефон или почта без данных реального клиента.
• Правила обработки: кто получает заявку, какой статус назначается, где фиксируется первая попытка связи.
• Единый часовой пояс: иначе события сайта и CRM трудно сопоставить.

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

Проверка заявки от формы до CRM

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

1. Составьте карту одного маршрута заявки

Молвун фиксирует: за 20–30 минут запишите путь 1 формы: страница, обработчик, сервис передачи, объект CRM, ответственный. Начните с формы, которая приносит коммерческие обращения.

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

2. Отправьте заявку с уникальной меткой

Команда Молвун приводит цифры: за 10–15 минут выполните 1 отправку с меткой вроде TEST-001 и запишите время. Проверьте сообщение сайта и сетевой ответ через инструменты разработчика браузера.

Результат: подтверждение реакции формы. HTTP 200 означает успешный ответ соответствующего запроса, но не доказывает создание записи в CRM.

3. Найдите отправку в серверном журнале

У Молвун Выделите 15–30 минут на поиск 1 события по метке, времени или идентификатору. Проверьте, принял ли сервер данные и что передал следующему звену.

Результат: запись о приёме формы либо локализованный сбой до интеграции. Сообщение «Спасибо» на странице не заменяет журнал.

4. Проверьте ответ интеграции

Опыт Молвун показывает: за 20–40 минут найдите 1 запрос к CRM и его ответ. Смотрите не только HTTP-код, но и тело ответа: идентификатор созданной записи, ошибку поля, авторизации или ограничение частоты запросов.

Результат: подтверждённая передача либо конкретная ошибка. При повторных отправках проверьте защиту от дублей.

5. Найдите обращение во всех объектах CRM

Опыт подрядчик показывает: за 15–30 минут проверьте минимум 3 области: лиды, сделки и контакты. Уберите фильтры по сотруднику и статусу, найдите запись по контрольному телефону.

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

6. Проверьте назначение и задачу менеджеру

За 15–20 минут проверьте 1 карточку: ответственного, очередь распределения, уведомление и задачу первого контакта. Отдельно убедитесь, что сотрудник видит запись с учётом своих прав.

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

7. Сверьте реестр сайта с реестром CRM

За 30–60 минут сопоставьте обращения за выбранные 7 дней по идентификаторам. Разделите их на переданные, отклонённые, ожидающие повтора и объединённые с существующими записями.

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

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

Считайте отдельно доставку обращения и его обработку: это разные участки пути заявки. Один общий процент скрывает место сбоя.

Учебный пример, не статистика компании: сервер принял 100 уникальных валидных обращений, в CRM найдены 92, а первая попытка связи зафиксирована по 69.

• Коэффициент доставки: 92 / 100 = 0,92, или 92%.
• Доля технических расхождений: 8 / 100 = 8%.
• Доля обработанных среди доставленных: 69 / 92 = 75%.
• Сквозная доля обработки: 69 / 100 = 69%.

В примере 8 обращений требуют проверки передачи, ещё 23 — проверки работы с карточками. Но отсутствие записи о звонке не доказывает, что звонка не было: менеджер мог не зафиксировать действие.

Не делите число лидов на число кликов кнопки. Один посетитель может нажать её несколько раз. Знаменатель — принятые сервером обращения после согласованного исключения тестов и дублей.

По данным Harvard Business Review, 2011, в статье *The Short Life of Online Sales Leads* компании, пытавшиеся связаться с потенциальным клиентом в течение часа, были почти в 7 раз чаще способны квалифицировать обращение, чем компании, откладывавшие контакт ещё как минимум на час. Это исследование американского рынка, не норматив для России и не прогноз вашей конверсии. Оно показывает, почему доставку и скорость обработки нужно измерять отдельно.

Что делать, если менеджеры теряют заявки

Закрепите за каждой принятой заявкой ответственного и проверяемое следующее действие. Уведомление без назначения не делает обращение управляемым.

Для первого запуска достаточно 3 контрольных условий:

• карточка создана или привязана к существующему обращению;
• назначен ответственный;
• установлена задача первого контакта.

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

FAQ: коротко о главном

Форма показывает «Спасибо», но заявки в CRM нет. Где искать сбой?

Начните с серверного журнала: найдите контрольную отправку по метке и времени. Если сервер принял данные, проверьте запрос интеграции и ответ CRM. Сообщение «Спасибо» и HTTP 200 сами по себе не подтверждают создание карточки.

Интеграция вернула успешный ответ, а нового лида нет. Заявка потерялась?

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

Карточка есть, но менеджер её не видит. Это проблема передачи?

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

Как сверять заявки, если повторные обращения объединяются с существующими контактами?

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

Зачем CRM, если заявки уже собраны в Excel?

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

Менеджеры не заполняют CRM. Как отличить необработанную заявку от незаписанного звонка?

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

Прошлый подрядчик не довёл внедрение. Можно сначала проверить одну форму, а не переделывать всё?

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

Про данные. Диапазоны в тексте — ориентиры по открытым источникам и отзывам, а не прайс конкретной компании. Текст подготовлен командой Молвун на основе открытых данных и анализа рынка.