Между кнопкой «Отправить» и менеджером, который перезванивает, обращение проходит четыре системы и шесть мест, где может исчезнуть бесследно. Ни одно из них не выглядит как поломка: сайт открывается, форма отправляется, в CRM заявки приходят, менеджеры работают. Потеря заметна только по косвенным признакам — реклама даёт трафик, а заявок почему-то меньше, чем месяц назад; клиент говорит «я вам писал», а в системе его нет.
Разница между этой статьёй и общими советами «настройте интеграцию» в одном: ниже к каждому месту потери приложен способ проверки, который делается своими силами за 10–30 минут. Все шесть проверок занимают около двух часов, и после них у вас появляется собственная цифра — сколько обращений в месяц вы не видите — вместо ощущения, что вроде всё работает.
Главный вывод из инженерной практики стоит вынести вперёд: заявка должна сначала записываться у вас и только потом уходить дальше. Если первым получателем обращения выступает почта или CRM, то любая их недоступность превращается не в задержку, а в исчезновение — восстанавливать нечего.
Шесть мест потери и способ проверить каждое
Порядок в таблице — от самой частой причины к самой редкой по нашей практике разбора чужих контуров.
| Место потери | Как выглядит снаружи | Как проверить | Время |
|---|---|---|---|
| 1. Форма не отправилась | Кнопка нажимается, ничего не происходит или крутится вечно | Отправить заявку с телефона и из другого браузера, посмотреть журнал ошибок страницы за неделю | 15 мин |
| 2. Письмо ушло в спам | Заявка есть в журнале сайта, но менеджер её не видел | Отправить тестовую с внешнего адреса, проверить папку спама и правила пересылки в общем ящике | 10 мин |
| 3. Вызов ушёл в недоступную систему | Провал за конкретные часы или дни, чаще после обновления CRM | Выгрузить журнал ответов интеграции за 30 дней, посчитать долю неуспешных | 30 мин |
| 4. Заявка без ответственного | Заявка в системе есть, но её никто не взял и она ушла вниз списка | Выгрузить из CRM заявки без ответственного или без активности дольше суток за месяц | 20 мин |
| 5. Ночное и выходное обращение | Утренний перезвон, клиент уже купил у другого | Сравнить конверсию заявок с 20:00 до 9:00 с конверсией дневных за квартал | 20 мин |
| 6. Дубль от повторного нажатия | Два менеджера звонят одному человеку с разными предложениями | Сгруппировать заявки за месяц по телефону в пределах десяти минут | 15 мин |
Обратите внимание, что первые три проверки ищут обращения, которых у вас нет вообще, а последние три — обращения, которые есть, но не обработаны. Это разные болезни с разным лечением: первые лечатся резервным контуром и мониторингом, вторые — правилами распределения и защитой от повторов. Смешивать их в одну задачу «наладить заявки» — верный способ починить половину и остаться с потерями.
Схема процесса в чертёжной манере: слева направо блоки «Кнопка на сайте», «Приём формы», «Свой журнал обращений», «Очередь передачи», «CRM», «Менеджер». Между блоками и над ними шесть пронумерованных красных меток разрыва с короткими подписями: 1 «форма не отправилась», 2 «письмо в спаме», 3 «система недоступна», 4 «нет ответственного», 5 «ночь и выходные», 6 «дубль от двойного нажатия». Под блоком «Свой журнал обращений» пометка «здесь заявка уже не теряется». Сбоку врезка «Проверочная заявка каждые 30 минут» со стрелкой во вход схемы. Подписи по-русски, без логотипов.
Сначала свой журнал, потом CRM
Порядок, при котором обращение сначала записывается в собственное хранилище на стороне сайта и только после этого ставится в очередь на передачу в CRM, почту и мессенджер. Если получатель недоступен, попытка повторяется с нарастающей паузой, а заявка всё это время существует и видна человеку. Ни одна заявка не считается принятой, пока она не записана у вас.
Эта конструкция стоит недорого и закрывает третье место потери целиком, а заодно превращает четвёртое из невидимого в очевидное: в собственном журнале сразу видно, сколько заявок дошло до CRM, а сколько застряло. Как именно собирается такой контур, с какими полями и какими способами передачи, разобрано в статье про связку формы сайта с CRM — здесь важно только правило очерёдности.
Второе следствие правила касается дублей. Защита от повторного нажатия ставится там же, на приёме: обращение с тем же телефоном и той же формы в пределах десяти минут не создаёт вторую заявку, а дописывается в первую. Сравнивать по тексту сообщения нельзя — постоянный покупатель, оставивший два разных запроса за час, получит отказ.
Проверочная заявка и срок первого ответа
Самая дешёвая работа из всей сметы даёт примерно половину эффекта. Речь о проверочной заявке — искусственном обращении, которое отправляется само по расписанию и проходит весь путь до CRM.
- 1Расписание
Каждые 30 минут в рабочие часы и раз в час ночью. Реже — и вы узнаёте о поломке от клиента; чаще — и алерты начинают шуметь на кратких сбоях сети.
- 2Маршрут
Заявка отправляется через ту же форму и тем же способом, что и настоящая, с признаком проверочной. Проверка внутренним вызовом мимо формы бесполезна: чаще всего ломается именно страница.
- 3Проверка результата
Через минуту система смотрит, появилась ли запись в CRM. Не появилась дважды подряд — уходит алерт человеку, а не в общий чат, где его никто не увидит.
- 4Уборка
Проверочные заявки помечаются и не попадают в отчёты и в работу менеджеров, иначе через месяц контур приходится выключать вручную.
Отдельная тема — ночь и выходные. Обращение, оставленное в 23:40, до утра не обрабатывается ни в одной компании, и это нормально. Ненормально, когда покупатель об этом не знает: он ждёт ответа, не дожидается и оформляет заказ у того, кто ответил. Минимальное решение — автоматический ответ в момент приёма с честным сроком («ответим до 10:00») и постановка заявки в очередь с приоритетом на утро. Это не автоматизация продаж, а вежливость, которая стоит несколько часов работы; сами автоматические ответы клиентам при этом полезны и в рабочее время.
Горизонтальная лента времени с 23:00 до 10:00 в чертёжной манере, с двумя дорожками. Верхняя, «Как сейчас»: метка «23:40 заявка», далее длинный пустой участок с подписью «тишина 9 часов 20 минут», метка «9:00 менеджер открыл почту», метка «9:40 звонок, клиент уже купил». Нижняя, «Как надо»: метка «23:40 заявка», через минуту «23:41 автоответ: ответим до 10:00», далее «9:00 автораспределение», «9:12 звонок». Справа подпись «конверсия ночных заявок сравнивается с дневными за квартал». Подписи по-русски, без логотипов.
Что обязано приехать вместе с заявкой
Заявка — это не только телефон и текст. Вместе с ней передаются и сохраняются ещё две группы данных, и обе становятся проблемой позже, если о них не подумать сразу.
- Факт согласия на обработку данных. Сохраняется не галочка, а событие: дата и время, версия текста согласия, адрес страницы, с которой оно дано, и технические признаки посетителя. Согласие как поле «да» без даты и версии текста в спорной ситуации не значит ничего. Требования 152-ФЗ к хранению таких данных мы описали на странице о безопасности.
- Метки источника. Из какого канала, кампании и с какой страницы пришло обращение. Метки должны сохраняться на самой заявке в момент приёма, а не только в системе веб-аналитики: через месяц связать одно с другим будет уже нечем, а именно эта связка потом даёт отчёт о стоимости заказа по каналу.
- Технический контекст. Номер сессии, адрес страницы, версия формы. Три поля, которые ничего не стоят при приёме и экономят часы, когда нужно понять, почему в конкретный день заявки перестали доходить.
Сколько стоят потерянные заявки
Модельный магазин: 700 обращений с форм в месяц, конверсия в заказ 28 %, средний чек 6 000 ₽, валовая маржа 24 % — 1 440 ₽ с заказа, полная стоимость часа менеджера 900 ₽. Контур собран «в лоб»: форма отправляет письмо и вызов в CRM, резервной записи нет, проверок нет.
Работы делаются поверх существующей формы и существующей CRM, менять их не нужно. Ставка инженера-подрядчика 3 000 ₽ в час.
Самая дешёвая строка сметы — проверочная заявка за 18 000 ₽ — делает заметными первые три места потери, а это 35 обращений из 63 и 14 400 ₽ из 30 270 ₽, то есть почти половина суммы. Если бюджет ограничен, начинать надо именно с неё: она не чинит контур, но делает поломку заметной в течение получаса, а не в конце месяца. Подробный разбор того, как считать цену одной необработанной заявки на своих данных, у нас есть в отдельной статье.
Столбиковая диаграмма из трёх сегментов с подписями в рублях за месяц: «Маржа 18 несостоявшихся заказов — 25 920», «Разбор жалоб «я оставлял заявку» — 2 250», «Разбор дублей — 2 100». Итог справа «30 270 ₽ в месяц». Ниже горизонтальная плашка сметы из пяти позиций с суммами 36 000, 30 000, 18 000, 18 000 и 15 000 ₽ и подписью «итого 117 000 ₽, окупаемость 3,9 месяца». Отдельной пометкой выделена позиция «проверочная заявка 18 000 ₽ — закрывает половину потерь». Все числа проставлены, чертёжная манера, подписи по-русски.
Когда шесть проверок избыточны
Полный контур нужен не всем, и три ситуации стоит назвать честно.
- Меньше 60–80 обращений в месяц. Потери составят пять-семь заявок, из которых заказом стали бы полторы-две, то есть около 2 500 ₽ маржи против 117 000 ₽ вложений. Здесь работает другое: провести все шесть проверок руками один раз в квартал и завести правило, что каждое утро кто-то сверяет число заявок в CRM с числом писем.
- Все обращения приходят в мессенджер или по телефону. Формы в этом случае вообще не главный канал, и разбираться нужно с пропущенными звонками и непрочитанными диалогами, а не с формой. Заявки при этом всё равно должны попадать в одно место — иначе появляется седьмое место потери, персональный чат сотрудника.
- Заявка сразу уходит человеку, который сидит рядом. В компании из трёх человек резервный контур решает задачу, которой нет: пропажу замечают в тот же час. Начните с меток источника и фиксации согласия — это 15 000 ₽ и полезно независимо от размера.
И последнее наблюдение. Из шести мест потери пять относятся к технике, а одно, четвёртое, — к организации. Заявку без ответственного не спасёт ни очередь повторов, ни проверочное обращение: если правило «через 15 минут без ответственного заявка уходит руководителю» не согласовано с людьми, автоматика будет исправно перекладывать обращения в пустоту. Поэтому проект начинается не с интеграции, а с ответа на вопрос, кто отвечает за первый контакт в каждый час суток; квалификацию и приоритет обращений при этом можно частично снять с людей — автоматической квалификацией лидов.
Обращение считается принятым не тогда, когда покупатель увидел «спасибо, мы свяжемся», а тогда, когда запись о нём существует у вас и её видит конкретный человек.
