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

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

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

Путь заявки состоит из пяти этапов: человек заполняет форму, форма передаёт данные в CRM, менеджер отвечает, клиент получает счёт и платит. CRM - это система учёта клиентов, программа, где хранятся все обращения.

На стыке каждого этапа система аналитики записывает два события. На форме попытка - нажатие «Отправить», успех - форма ушла без ошибки; на оплате попытка - нажатие «Оплатить», успех - платёж прошёл. Разница между ними и есть потери на этом стыке.

Доля потерь - это доля попыток, которые не закончились успехом.

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

Ту же формулу применяют к каждому следующему стыку: сколько из 460 отправленных заявок появилось в CRM, скольким ответили, сколько получили счёт и сколько в итоге заплатили.

Так ощущение «с заявками что-то не так» сменяется числом у определённого стыка, и его уже можно разбирать с командой.

Как проверка номера телефона отсекла клиентов

Одна компания собрала из аналитики сайта все случаи, когда человек не смог отправить заявку или начать разговор. Несколько замеров подряд таких сбоев становилось больше: 2, 5, 17, 33.

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

На одно поле смотрят с двух сторон. Для разработчика главное - чтобы через него нельзя было навредить базе данных. Для бизнеса главное - чтобы человек смог оставить заявку. Эти задачи не противоречат друг другу, но проверять нужно обе.

То есть проверяют и защиту базы, и то, что человек с настоящим номером в любом привычном ему формате может отправить заявку.

Одно поле, одна неаккуратная проверка - и в последнем замере уже 33 сбоя.

Где пропадают заявки между формой и системой учёта клиентов

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

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

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

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

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

Передача заявки от формы к менеджеру - такой же стык, как любой другой. На нём тоже нужно своё событие аналитики.

Почему ответы медленнее к концу очереди

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

Но к тридцатой-сороковой сделке ответы запаздывают, начинаются провалы по времени, менеджер отвечает небрежно.

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

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

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

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

В той же компании в CRM стоял встроенный ИИ-автоответчик - программа, которая отвечает клиентам без участия живого менеджера. Со стандартными вопросами он справлялся, а на чуть более сложных начинал писать ерунду.

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

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

Как ошибка в счёте годами уводила людей на главную

В одном продукте при любой ошибке выставления счёта код отправлял человека на главный экран, а не обратно в заказ.

Люди, попавшие на эту ошибку, повторно не платили.

Этот код написали давно, когда только подключали платёжную систему, как временную заглушку - наскоро сделанное решение, которое собирались потом заменить. Команда у продукта была сильная и многое переписывала. А это место не трогала, потому что оно «как-то работало».

Временная заглушка тихо просуществовала несколько лет.

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

Что показать человеку, если оплата не прошла

В международном сервисе с миллионами пользователей разобрали отказы на этапе оплаты. Причин нашлось четыре, и на каждую человеку нужен свой ответ.

• Данные карты не введены - сначала проверить аналитику: часть таких событий оказалась её ошибкой, люди после них всё равно покупали.
• Временный сбой в банке или платёжной сети, не связанный с покупателем, - предложить повторить попытку.
• Не хватает средств - сказать прямо и предложить другой способ оплаты: повтор здесь не поможет.
• Карта не принимается (так часто бывает с картами одних стран при оплате через банк другой страны) - предложить другую карту. Предупредить об этом можно ещё при вводе номера карты.

Многие сайты при ошибке оплаты показывают только «что-то пошло не так», и человек не понимает, что делать дальше. Текст ошибки должен зависеть от типа отказа, а заказ при этом не должен пропадать.

Ещё одна точка потерь - раздельная оплата. Когда клиент хочет заплатить частями или двумя платежами, а ссылку на каждую часть менеджер создаёт вручную, оплата ждёт, пока он освободится. Эту работу можно автоматизировать, а оплату сразу записывать в CRM.

Десять точек, где теряются заявки

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

Точка	Что проверить	Какое событие считать
Поле телефона	Проверка не отсекает настоящие номера, правильно понимает код страны	Отправка, отклонённая проверкой
Форма во встроенном окне конструктора	Каждая отправка доходит до компании	Отправки формы против полученных заявок
Ошибка при отправке	Человек видит понятное сообщение, введённое не пропадает	Ошибка отправки
Передача в CRM	Все поля доходят и попадают в нужные места	Заявка создана в системе
Передача в продажи	У каждой заявки есть ответственный	Назначен менеджер
Первый ответ	Скорость по всей очереди, включая ночь	Время до первого ответа
Автоответчик	На нестандартный вопрос передаёт разговор человеку	Передача человеку
Выставление счёта	При ошибке человек остаётся в заказе и видит, что делать	Ошибка счёта и следующий экран
Отказ оплаты	Текст зависит от типа отказа	Код отказа (пометка о причине)
Повторная и раздельная оплата	Ссылка создаётся без ручной работы менеджера	Повторная попытка после отказа

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

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

Вопросы и ответы

Какая доля потерь считается нормальной?

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

С чего начать, если аналитики почти нет?

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

Нужно ли уходить с конструктора сайтов?

Необязательно. Конструктор - инструмент для быстрой сборки страниц, и сам по себе он не причина потерь. Вопрос в том, как работает конкретная форма: доходят ли данные до CRM, правильно ли сопоставлены поля, обрабатываются ли ошибки. Если форма теряет заявки, сначала найдите причину, а потом решайте, что менять: форму или всю страницу.

Почему нельзя при любой ошибке оплаты писать «повторите попытку»?

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

Если хотите проверить, где теряются заявки на вашем сайте и в продажах, напишите в Telegram или на hello@majento.ai.