Заявка должна сохраняться в системе учёта, а уведомление — помогать менеджеру её заметить. Сообщение в чате само по себе не заменяет историю обращений.
Определите путь заявки
Посетитель заполняет форму, сервер принимает данные, обращение сохраняется, а ответственный получает уведомление. Эти действия связаны, но сбой на одном шаге не всегда означает сбой на остальных.
Например, запись уже появилась в системе, а сообщение в мессенджер задержалось. В таком случае менеджер может увидеть обращение в списке заявок, если этот список предусмотрен и доступен.
Собирайте нужный минимум
Для первого разговора часто достаточно имени, контакта и краткого описания задачи. Длинная анкета полезна только тогда, когда ответы действительно нужны до связи с клиентом.
- Номер или другой выбранный способ связи.
- Услуга и комментарий, если посетитель их указал.
- Страница отправки и источник обращения.
- Рекламные метки, когда они есть в адресе перехода.
Запрашивать все возможные данные на всякий случай не нужно. Лучше собирать то, с чем менеджер сможет сделать следующий шаг.
Проверьте неудачную отправку
При ошибке серверного запроса форма должна показать понятное сообщение и сохранить введённый текст для повторной попытки. Нельзя показывать успех, если запрос не был принят.
Повторные нажатия не должны создавать поток одинаковых запросов. Предотвращение дублей и подтверждение сохранения заявки нужно согласовать и на стороне приёмника данных.
Назначьте следующий шаг
Даже исправная форма не решает вопрос, кто отвечает человеку. Назначьте ответственного, договоритесь о рабочем времени и фиксируйте статус обращения.
После запуска полезно периодически отправлять тестовую заявку. Проверяйте всю цепочку, особенно после изменения формы, подключения нового сервиса или обновления сервера.
Заявка «рассчитать ремонт» сохраняется с контактом и страницей отправки. Менеджер получает уведомление, открывает запись, назначает звонок и отмечает результат. На следующий день понятно, какие обращения ещё ждут ответа.
