Трафик растет, заявок нет: где сайт теряет ваших клиентов

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

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

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

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

Начните с посадочных страниц. Отдельно посмотрите услуги, сравнения, кейсы и информационные инструкции. Затем разделите источники и устройства. Для первого разбора достаточно двух сопоставимых периодов и нескольких основных групп страниц.

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

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

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

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

Компания продает IT-аутсорсинг для офисов, но самый посещаемый материал посвящен домашнему Wi-Fi. Это может быть полезная статья. Однако ее аудитория не обязательно выбирает обслуживание корпоративной сети.

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

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

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

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

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

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

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

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

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

Отзывы тоже должны отвечать на вопрос клиента. Фраза «все понравилось» дает мало информации. Подробный согласованный отзыв о переходе от штатного администратора к внешней команде помогает понять процесс. Для публикации используйте реальные подтвержденные материалы.

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

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

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

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

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

Метрика позволяет отправлять целевое событие через reachGoal; соответствующий идентификатор должен совпадать с настроенной целью. Место вызова выбирает разработчик под реальный сценарий приложения. Документация Яндекс Метрики (откроется в новой вкладке).

Пример названий событий для обсуждения с командой:

form_opened       — форма открыта
form_submit_click — нажата кнопка
lead_saved        — обращение сохранено
lead_qualified    — менеджер подтвердил соответствие задаче

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

При сверке используйте время и внутренний идентификатор обращения. Не передавайте в названия событий телефоны, email и текст заявки. Они не нужны для проверки количества и создают лишнее распространение клиентских данных.

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

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

Договоритесь с отделом продаж о простых статусах: получено, соответствует услуге, требуется уточнение, отказ с причиной, предложение отправлено, сделка. Конкретный набор зависит от процесса компании. Главное — одинаково применять определения.

Не меняйте одновременно определение «качественной заявки» и дизайн, если потом хотите сравнивать показатели. Если правила изменились, отметьте дату и пересчитайте сравнимую часть истории, где это возможно.

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

Если трафика достаточно, обсудите корректный A/B-тест: заранее определенную метрику, распределение посетителей и правило завершения. При малом объеме начните с проверки сценариев и интервью с клиентами. Сравнение «прошлая неделя против этой» чувствительно к составу трафика, рабочим дням и сезонности.

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

День 1: собрать визиты и обращения по основным группам страниц, согласовать определение заявки.

День 2: пройти один покупательский сценарий на телефоне и сверить тестовое обращение с CRM.

День 3: разобрать несколько недавних отказов с менеджером; проверить, какие ожидания сформировал сайт.

Дни 4–5: подготовить и внедрить одно обоснованное изменение с понятным критерием приемки.

Затем наблюдайте выбранный сегмент и качество обращений. Технический дефект можно подтвердить сразу после исправления; для вывода о коммерческом эффекте понадобится достаточный объем данных и время на решение клиента.

Если проблема появилась после обновления сайта, начните с проверки редизайна и переноса страниц. Для технической диагностики используйте чек-лист SEO-аудита.

В ЭНТЕРНО можно начать с аудита сайта: пришлите адрес, приоритетную услугу и опишите, где расходятся посещаемость и обращения. Это поможет определить, какие данные и проверки нужны первыми.