Реклама приводит посетителей, в аналитике видны нажатия на кнопку, а у менеджера за день всего одна заявка. Сразу менять объявление рано. Между кнопкой на сайте и карточкой клиента может быть несколько шагов: браузер отправляет данные, сервер принимает их, служба уведомлений доставляет письмо, система продаж создаёт запись. Сбой на любом из этих шагов выглядит для владельца одинаково.
Проверьте весь путь на одной тестовой заявке с узнаваемой пометкой. Запишите время, устройство и страницу входа. Тогда разработчик сможет найти конкретную попытку в журналах. Сообщение «форма иногда не работает» почти не сужает поиск. Пометка в тестовом обращении и точное время дают шанс обнаружить место потери без перебора всех настроек сайта.
Ниже приведены семь проверок, которые можно пройти вместе с разработчиком. Диагностика может потребовать времени, особенно при редких сбоях. Эти проверки подходят для сайта услуг или магазина, где обращение отправляется через форму. Если заявки принимает внешний сервис, часть проверки придётся провести в его кабинете.
1. Убедитесь, что человек вообще может отправить форму
Начните с телефона. Откройте страницу так, как её открывает посетитель рекламы, и заполните поля привычным способом. Введите номер с пробелами, скопируйте адрес почты, попробуйте вставить имя целиком. Ошибки часто возникают на значениях, которые разработчик не использовал при проверке. Удобный примерный номер из макета ничего не говорит о работе формы с реальными вводимыми данными.
Посмотрите, остаётся ли видна кнопка, когда открыта клавиатура. Проверьте подписи ошибок. Фраза «неверные данные» заставляет угадывать, какое поле исправлять. Лучше назвать конкретное поле и допустимый способ ввода. При этом не следует стирать остальные значения после одной ошибки: повторное заполнение длинной заявки легко отбивает желание продолжать.
Проверьте обязательные поля. Если форма требует название компании у частного клиента, часть людей остановится ещё до отправки. Такое обращение не потерялось в системе, оно так и не было создано. Отличайте эту проблему от технического сбоя. Для неё нужно менять вопросы и условия заполнения, а журнал доставки сообщений останется пустым.
Попросите коллегу пройти форму без подсказок. Если он остановился на непонятном поле, запишите его точную формулировку. Для начала достаточно нескольких наблюдений, чтобы найти очевидную преграду. Вывод о массовом влиянии правки лучше делать по данным до и после изменения. Сама проверка коллегой подтверждает только то, что конкретное затруднение существует.
2. Разделите клик и успешный приём заявки
Нажатие кнопки подтверждает намерение человека отправить форму. Оно ещё не доказывает, что сайт получил данные. Если аналитика считает заявку в момент клика, отчёт будет завышать число обращений при ошибках сети и заполнения. Событие успешной заявки стоит связывать с подтверждённым результатом сервера, который принимает обращение.
Разработчик может проверить это в браузере, посмотрев запрос формы и ответ на него. Владельцу сайта полезно попросить два результата проверки: адрес обработчика и описание успешного ответа. Не нужно самостоятельно читать весь код. Достаточно договориться, какой ответ означает сохранение заявки и что видит человек при ошибке.
Здесь встречается неприятная тонкость. Запрос может получить технически успешный ответ, хотя последующее создание карточки клиента завершится сбоем. Поэтому команда должна определить, где именно начинается обещание «заявка принята». Надёжнее сохранить обращение на стороне сайта до отправки уведомлений. Тогда временная недоступность почты или системы продаж не уничтожит исходные данные.
Для нестандартной формы Feature IT может доработать сайт и обработку заявок. Перед обсуждением соберите несколько неудачных попыток с временем отправки. По ним можно проверить существующую цепочку и предложить конкретное изменение. Общий порядок настройки обмена данными на сайте поможет понять, какие части системы участвуют в передаче.
3. Проверьте, сохраняется ли обращение до уведомления
Письмо менеджеру удобно, но его отсутствие не должно оставлять компанию без исходной заявки. Проверьте, есть ли отдельное место, где обращения сохраняются с номером и временем. Это может быть база сайта или система продаж. Название технологии вторично. Нужно уметь найти принятую запись, даже если уведомление не пришло.
Сохранённая запись должна иметь понятный статус. Например, сайт принял обращение, затем попытался передать его менеджеру. При неудаче остались причина и возможность повторить отправку. Без такого разделения сотрудники начинают искать письма в разных ящиках и спорить, был ли заказ вообще. История попыток снимает часть этих вопросов.
Попросите разработчика показать поведение при временном отказе следующего сервиса. Такую проверку проводят в тестовой среде или под контролем команды. После восстановления связи заявка должна попасть по назначению, а повторная попытка не должна создавать отдельного клиента каждый раз. У обращения нужен стабильный номер, по которому система узнаёт уже обработанную запись.
Если в текущей схеме всё держится на одном письме, начните с сохранения исходного обращения. Перестройка сразу всех процессов не обязательна. Но после изменения проверьте доступ сотрудников к списку заявок и порядок ручной обработки. Технически сохранённая запись мало помогает, если никто в компании не знает, где её открыть.
4. Проследите доставку уведомления
Возьмите номер сохранённой заявки и проверьте, пытался ли сайт отправить письмо или сообщение. В журнале должна быть запись о попытке и ответе принимающего сервиса. Ответ об успешном приёме сообщения ещё не доказывает, что менеджер прочитал его. Поэтому разделяйте техническую доставку и работу человека с обращением.
Для почты проверьте адрес получателя, папку нежелательных писем и правила сортировки. После смены сотрудника уведомления иногда продолжают уходить в старый ящик. Для сообщений в рабочем чате проверьте, доступен ли нужный канал и видят ли его дежурные. Личный чат одного менеджера создаёт зависимость от его рабочего графика.
Уведомление должно содержать номер заявки и ссылку на запись. Тогда менеджер сможет проверить полный состав обращения, даже если сообщение сократилось или часть данных не поместилась. Избыточные персональные сведения в общем чате обычно не нужны. Согласуйте с командой, что именно требуется для быстрого начала работы, и храните подробности в месте с подходящими правами доступа.
Назначьте резервного получателя для технических ошибок доставки. Уведомлять его о каждом успешном письме бессмысленно: полезный сигнал утонет в потоке. Подойдёт сообщение о серии неудачных попыток или о заявке, которая долго остаётся без передачи. Порог и время ожидания выбирайте по рабочему процессу компании, затем проверяйте на тесте.
5. Найдите заявку в системе продаж
Если форма передаёт данные в систему учёта клиентов, ищите обращение по номеру и тестовой пометке. Поиск только по имени ненадёжен: оно может повторяться или записываться с ошибкой. Посмотрите, в какую очередь попала заявка, кто назначен ответственным и не скрывает ли её фильтр текущего менеджера.
Иногда запись существует, но оказывается в другом подразделении. Причиной бывает правило распределения по городу, услуге или источнику. Проверьте пустое значение каждого такого поля. Если город не выбран, система должна отправить обращение в понятную общую очередь. Тихо назначать его человеку, который больше не работает, недопустимо для рабочего процесса.
Сверьте состав данных. Телефон может попасть в комментарий вместо поля контакта, а выбранная услуга остаться только в письме. Тогда менеджер видит карточку, но не может выполнить привычное действие. Для каждой формы полезно иметь таблицу соответствия полей. В ней указаны название поля на сайте, место в карточке и правило при пустом значении.
Поля рекламного источника требуют отдельной проверки. Их состав и передачу разбирает материал о сохранении UTM-меток в заявке. Однако отсутствие метки не должно мешать самому приёму обращения. Форма должна принять обращение посетителя, который пришёл напрямую или использует браузер с ограничениями аналитики.
6. Посмотрите, кто взял обращение в работу
Техническая цепочка может быть исправна, а заявка всё равно остаётся без ответа. Проверьте, видно ли время назначения ответственного и первое действие менеджера. Статус «новая» без срока реакции удобен только до конца смены. После передачи дежурства сотрудникам приходится вспоминать, кто обещал перезвонить.
Согласуйте правило для неразобранных обращений. Например, ответственному приходит напоминание после установленного компанией времени ожидания. Если он недоступен, задача возвращается в общую очередь или переходит дежурному. Конкретные интервалы зависят от графика и характера услуги. Не стоит обещать клиенту немедленный звонок, когда заявки ночью читают только утром.
Отдельно проверьте обращение, пришедшее перед закрытием рабочего дня. У него должна быть видимая следующая точка обработки. Утренний менеджер должен получить список таких записей без поиска по переписке. Это организационное правило стоит включить в настройку системы, иначе после технической доработки проблема останется на прежнем месте.
Для передачи между сотрудниками полезна короткая запись о сделанном действии. «Позвонил, клиент попросил завтра после обеда» помогает следующему менеджеру продолжить разговор. Статус «в работе» без подробностей часто вынуждает звонить заново и задавать те же вопросы. Время следующего контакта должно храниться вместе с заявкой, чтобы напоминание адресовалось нужному человеку.
7. Повторите тест после исправления
Проверка одной формы на ноутбуке не закрывает задачу. Пройдите несколько путей, которыми реально пользуются посетители. Откройте страницу из рекламы на телефоне, отправьте короткую и длинную заявку, попробуйте разрешённый файл, если форма принимает вложения. Проверьте вариант без необязательных полей. Для каждого теста сохраните номер созданного обращения.
Сравните эти номера со списком в системе продаж и уведомлениями. Число кликов может отличаться от числа успешных заявок, но каждое подтверждение об успешном приёме должно иметь запись. Если сайт показал человеку сообщение об успехе без сохранённых данных, такое расхождение требует отдельного исправления. Скриншот зелёной галочки не заменяет проверку результата.
После выпуска изменений полезно настроить регулярную техническую проверку пути заявки. Она должна использовать тестовые данные, понятную пометку и согласованное удаление тестовых записей. Простое наблюдение за доступностью главной страницы не покажет, что сломалась форма. О разных уровнях проверки подробнее говорится в материале о мониторинге веб-приложений.
В журнале приёмки оставьте дату исправления, проверенные формы и обнаруженную причину. Когда похожий сбой повторится, команда сможет сравнить обстоятельства. Для владельца такой журнал полезнее обещания «всё починили»: он показывает, какую часть процесса проверили и какие действия теперь видны в системе.
Что подготовить для разработчика
Для первого разбора соберите ссылку на форму, время проблемной попытки и пример того, что увидел посетитель. Добавьте ожидаемое место появления заявки и контакты сотрудника, который проверит результат. Рабочие пароли в общей переписке не нужны; доступы передаются согласованным способом и в нужном объёме.
Пришлите Feature IT пример потерянной заявки, если нужна проверка сайта и его обмена данными с рабочими сервисами. Начните с одной воспроизводимой ситуации. Она поможет отделить неудобство формы от сбоя передачи и выбрать доработку, которая устраняет найденную причину.
Читайте также
