---
title: Где теряются заявки на пути от формы до оплаты и как это посчитать
metaTitle: Где теряются заявки между формой и оплатой
description: Как найти, на каком шаге люди уходят, не оставив заявку или не заплатив: формула доли потерь и чек-лист из десяти точек.
date: 2026-09-28
tags: [marketing-automation, business-automation, analytics]
cover: cover.webp
coverAlt: "Моментальный снимок машины проваливается в щель между лотком для бумаг и пустым ящиком, рядом ждёт платёжный терминал"
---

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

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

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

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

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

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

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

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

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

![На стойке регистрации девушка с розовыми волосами сверяет бейджи с трафаретом на пять точек и отводит в сторону бейдж с семью точками](/blog/lost-leads-form-crm-payment/fig-phone-check.webp "Слишком строгая проверка номера вместе с мусором отсеивает и живых клиентов")

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чем такой автоответчик отличается от бота с правилами и от агента, который сам выбирает следующий шаг в пределах разрешённых ему действий, разобрано [в отдельной статье](/ru/blog/ai-agent-vs-chatbot-business/).

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

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

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

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

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

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

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

![У кассы магазина корзина покупателя отложена на полку, а кассир показывает на второй терминал](/blog/lost-leads-form-crm-payment/fig-payment-retry.webp "После отказа оплаты заказ сохраняется, а человеку понятно, что делать дальше")

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

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

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

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

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

Если цифры по стыкам вы сводите в таблицу, собрать из неё дашборд - сводный отчёт с графиками - с помощью ИИ-агента и проверить формулы поможет [отдельный разбор](/ru/blog/ai-excel-dashboard-audit/).

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

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

Majento строит связку формы, CRM и оплаты и автоматизирует обработку заявок. Подробнее - на страницах [маркетинговой автоматизации](/ru/marketing-automation/) и [разработки под конкретную задачу](/ru/custom-software-development/).

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

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

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

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

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

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

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

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

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

Если хотите проверить, где теряются заявки на вашем сайте и в продажах, напишите в [Telegram](https://t.me/shimaoz) или на [hello@majento.ai](mailto:hello@majento.ai).