Еженедельная тестовая заявка: как проверять путь обращения от формы до ответа менеджера

Сайт работает, реклама крутится, в Яндекс.Метрике растёт число визитов, а заявок почему-то меньше обычного. Менеджеры говорят, что звонков стало мало, владелец подозревает рекламу, подрядчик подозревает сезон. И только через три недели выясняется, что после очередного обновления форма на сайте перестала отправлять данные в СРМ, а уведомления приходили на почту сотрудника, который уволился. Всё это время клиенты нажимали «Отправить», видели «Спасибо» и ждали звонка, которого не было. Такие истории не редкость: форма внешне работает, а путь заявки обрывается где-то внутри.

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

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

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

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

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

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

Что именно проверять: полный путь от формы до ответа

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

После отправки посмотрите, что видит клиент. Должно появиться подтверждение с понятным текстом и сроками ответа. Проверьте, пришло ли автоматическое письмо или сообщение клиенту, если вы его настраивали, и не попало ли оно в нежелательные. Затем идите по цепочке. Убедитесь, что заявка сохранилась в разделе форм ХостСМС. Проверьте почту, на которую настроено уведомление, и папку нежелательных писем. Откройте СРМ, будь то Битрикс24, амоСРМ или другая, и найдите карточку: создалась ли она, правильно ли заполнены поля, указан ли источник, привязана ли страница, с которой пришла заявка, и метки.

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

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

Проверка всех входов: форма, звонок, чат, мессенджеры, карточки

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

Позвоните на номер, указанный на сайте, и на номера в карточках в Яндекс Бизнесе и 2ГИС. Если у вас отдельные номера для разных источников, позвоните на каждый. Проверьте, что звонок принимается, что переадресация работает, что запись разговора сохраняется, что звонок попадает в СРМ и в систему коллтрекинга с верным источником. Оцените, как отвечает сотрудник: приветствие, скорость, умение уточнить потребность. Конечно, если звонит свой сотрудник, нужно предупредить, что это тест, иначе вы увидите не обычную работу, а театр. Лучше, чтобы проверку делал человек, которого менеджеры не знают, например, знакомый или сотрудник другого подразделения.

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

Не забудьте о карточках. Откройте карточку в Яндекс Картах и нажмите кнопки звонка и сайта, посмотрите, куда они ведут. Сделайте то же в 2ГИС. Проверьте, что ссылки с метками открывают нужную страницу и что визит попадает в Метрику с правильным источником. Если в карточке есть форма заказа или запись, оформите тестовую запись и проверьте, дошла ли она. Так вы убедитесь, что обращения с карт доходят до менеджеров наравне с заявками с сайта.

Регламент: кто, когда и как проводит проверку

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

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

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

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

Как фиксировать результаты и что делать при поломке

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

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

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

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

Типичные проблемы, которые находит тестовая заявка

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

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

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

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

Как это связано с продвижением 3 в 1

Наш подход «3 в 1» предполагает три источника обращений: поиск, где сайт находят в обычной выдаче и в ответах нейропоиска, карточку в Яндекс Бизнесе и Яндекс Картах и карточку в 2ГИС. Тестовая заявка должна проходить через каждый из них. Откройте поиск, найдите компанию, зайдите на сайт, оставьте заявку. Откройте Яндекс Карты, найдите карточку, позвоните и перейдите на сайт. Откройте 2ГИС, повторите то же. Так вы убедитесь, что в каждой из трёх точек обращение реально доходит до менеджера, а не теряется по дороге.

Для этого заведите отдельные номера телефонов для карточек и метки для ссылок, а в СРМ добавьте поле источника. Тогда тестовая заявка покажет, правильно ли определяется источник. Если заявка из 2ГИС записывается как «прямой заход», значит, отслеживание настроено неверно, и вы видите искажённую картину: возможно, недооцениваете один канал и переплачиваете за другой. Обращения с карт считайте наравне с заявками сайта и проверяйте их так же регулярно.

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

Метрики регламента: на что смотреть кроме поломок

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

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

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

Вывод

Еженедельная тестовая заявка это дешёвая и надёжная страховка от потери клиентов. Она проходит весь путь: форму на сайте, письмо, карточку в СРМ, цель в Яндекс.Метрике, ответ менеджера, звонки, чат, мессенджеры и карточки в Яндекс Бизнесе и 2ГИС. Назначьте ответственного, выберите постоянный день, заведите журнал, проверяйте сайт после любых изменений и дублируйте уведомления. Тогда обращения из всех трёх точек, поиска, карт и 2ГИС, будут доходить до менеджеров, а вы перестанете узнавать о поломках от клиентов.

Если вы не уверены, что ваши заявки доходят до адресата, обратитесь за бесплатной консультацией к специалистам компании «Сайты Профессионально». Мы проведём диагностику пути заявки на вашем сайте, пройдём его от формы до ответа менеджера, проверим интеграции с СРМ, цели в Яндекс.Метрике и обращения из карточек в Яндекс Бизнесе и 2ГИС, а затем поможем составить регламент еженедельной проверки, который подойдёт вашей команде.