Потерянные заявки с сайта: причины, аудит и контроль CRM

Где теряются заявки: пять этапов и восемь ошибок

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

Пять этапов пути заявки

1. Форма. Проверяет обязательные поля и отправляет данные. Показывает "Спасибо" после подтверждения сервера.
2. Сервер. Проверяет входящие данные и сохраняет обращение. Присваивает ему уникальный идентификатор для дальнейшей сверки.
3. Передача. Интеграция отправляет данные через API, то есть программный интерфейс CRM. Другой вариант - webhook, автоматический HTTP-запрос по событию, или письмо.
4. CRM. Создаёт карточку или корректно связывает обращение с существующей. Сохраняет поля и назначает ответственного.
5. Первый ответ. Менеджер получает уведомление и связывается с клиентом. Действие и его время фиксируются в системе.

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

Восемь типичных ошибок

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

Как найти потерянные обращения, если заявки не приходят в CRM

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

Сначала согласуйте, что считается заявкой. Отдельно размечайте следующие категории:

• Новые коммерческие обращения.
• Запросы действующих клиентов.
• Повторные отправки одного обращения.
• Спам и нецелевые запросы.
• Обращения поставщиков и партнёров.

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

Например, аналитика показывает 30 целей, а сервер сохранил 20 обращений. Нужно проверить измерение: событие могло сработать по клику или повторно. Цель должна фиксировать подтверждённую отправку, а не нажатие кнопки.

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

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

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

Сколько стоят потерянные заявки: расчёт потенциальной выручки

Потенциальную выручку под риском можно оценить через число заявок, долю потерь, конверсию в продажу и средний чек. В условном сценарии с 500 заявками в месяц результат составляет $25 000. Это оценка возможностей продаж, а не подтверждённые убытки.

Формула: число заявок × доля потерь × конверсия в продажу × средний чек.

1. При 500 заявках и доле потерь 10% до обработки не доходят 50 обращений: 500 × 10% = 50.
2. При условной конверсии 20% эти обращения могли бы дать 10 продаж: 50 × 20% = 10.
3. При среднем чеке $2500 потенциальная месячная выручка под риском составляет 50 × 20% × $2500 = $25 000.

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

Для собственной оценки сначала определите долю потерь по сверке. Конверсию берите для похожих источников и типов обращений с завершённым циклом продаж. Это позволит сравнить стоимость исправлений с обоснованным сценарием риска.

Пошаговый аудит цепочки заявки

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

Шаги 1-2: форма и приём на сервере

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

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

Шаги 3-4: передача и карточка в CRM

Проверьте ответ API или webhook и журнал ошибок интеграции. Ответ "принято" может означать постановку задачи в очередь, поэтому нужен следующий контроль: обращение действительно зарегистрировано в CRM.

• Имя и телефон сохранены без потерь и неверного преобразования.
• Источник и UTM-метки, обозначающие рекламную кампанию, связаны с обращением.
• Запись находится в нужной воронке.
• Новое обращение не объединено с чужой сделкой.
• Идентификатор CRM связан с исходной заявкой в журнале сайта.

Проверка интеграций входит и в общий подход RegionSoft к аудиту CRM. Для поиска потерянных обращений мы дополняем её сквозной сверкой конкретных записей.

Шаги 5-7: уведомления, менеджеры и мониторинг

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

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

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

Надёжная CRM-интеграция: доставка и подтверждение

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

Для управляемой доставки мы рекомендуем серверный слой между формой и CRM. Прямой запрос из браузера или единственное письмо без резервного хранения затрудняют восстановление после сбоя.

Архитектура включает несколько компонентов:

• Журнал заявок. Хранит обращение и историю его доставки независимо от CRM.
• Очередь. Отделяет приём формы от скорости внешней системы.
• Повторные попытки. Повторяют отправку при временной ошибке с паузами между попытками.
• Ключ идемпотентности. Уникальный ключ одной отправки предотвращает повторное создание записи при повторе запроса.
• Журнал ошибок. Сохраняет причину сбоя и идентификатор обращения без лишних персональных данных.
• Оповещения. Сообщают ответственному о недоставленных заявках и исчерпанных попытках.

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

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

Отдельный сервис интеграции amoCRM описан в профиле Дмитрия Черчела. Такой подход выделяет передачу данных в самостоятельную часть системы с собственным контролем ошибок.

DevOps и инфраструктура Webdelo охватывают эксплуатационную сторону подобных решений. Для цепочки заявок важно контролировать возраст старейшего задания в очереди и наличие недоставленных обращений, а не только доступность сервера.

Кейсы Webdelo: BolgarskiyDom и Bonadomus

В BolgarskiyDom мы работали над автоматизацией обработки заявок и CRM, включая отдельную архитектуру интеграции amoCRM. В Bonadomus задача включала передачу обращения вместе с контекстом объекта недвижимости. Эти проекты показывают две стороны обработки: доставку данных и их полезность для менеджера.

BolgarskiyDom: автоматизация CRM

В проекте BolgarskiyDom автоматизация обработки заявок связана с CRM-интеграцией. Выделенная архитектура amoCRM позволяет рассматривать обмен данными как отдельную техническую задачу.

Для аудита такого решения важны границы ответственности: где обращение сохранено и какой компонент отвечает за следующую попытку доставки. Это делает неисправность проверяемой по конкретному переходу.

Bonadomus: контекст объекта в обращении

В проекте Bonadomus обращения передаются в CRM с контекстом объекта недвижимости. Менеджер видит, к какому объекту относится запрос, и может подготовить предметный ответ.

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

Скорость первого ответа и SLA отдела продаж

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

Для начала достаточно понятных статусов:

• Новое обращение. Запрос зарегистрирован и ожидает принятия менеджером.
• В работе. Менеджер принял запрос и выполняет следующий шаг.
• Ожидает клиента. Ответ отправлен, зафиксирована дата следующего контакта.
• Квалифицировано. Подтверждено соответствие запроса критериям продажи.
• Закрыто. Указаны результат и причина закрытия.

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

Например, обращение в субботу в 23:00 может остаться без контакта до понедельника. Если дежурства нет, автоответ должен сообщить понятный срок человеческого ответа. Само автоматическое подтверждение следует учитывать отдельно от первого контакта менеджера.

Технический SLA регулирует другую часть процесса: реакцию на неисправность системы. Порядок реагирования и условия поддержки помогают разделить эти обязательства с регламентом продаж. Ни один из регламентов сам по себе не гарантирует рост выручки.

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

Контроль лидов строится на пяти показателях: приём сервером, регистрация в CRM, назначение, первый ответ и нарушения SLA. Вместе они показывают участок задержки. Для корректного сравнения нужны единые идентификаторы обращений и одинаковые правила подсчёта.

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

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

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

Андрей Жуматий, сооснователь и директор по маркетингу Webdelo

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

Обработка входящих заявок: автоматизация, уведомления и мониторинг

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

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

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

Для мониторинга задайте отдельные условия:

• Сервер принимает обращения, а новые регистрации в CRM отсутствуют.
• Webhook или API возвращают ошибки.
• Растёт число недоставленных заявок или время их ожидания.
• Тестовая заявка не проходит весь маршрут.
• Новые обращения назначаются неактивным сотрудникам.

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

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

Чек-лист аудита: 15 проверок

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

Форма и сервер

1. Тестовая заявка отправлена из каждой формы, включая мобильные и всплывающие.
2. "Спасибо" появляется только после подтверждённого приёма и сохранения данных сервером.
3. Заявка сохраняется в независимом от CRM журнале с уникальным идентификатором.
4. Повторное нажатие и повтор запроса не создают дубль одной отправки.
5. Если используется почта, проверены SPF, DKIM, DMARC, доставка и действующий владелец ящика.

Интеграция и CRM

6. Обращение регистрируется в нужной воронке CRM.
7. Имя, телефон, содержание запроса, источник и доступные UTM-метки передаются полностью.
8. Новый клиент не объединяется с чужой сделкой, обращения не остаются бесконтрольно в "неразобранном".
9. Ошибки интеграции фиксируются, временные сбои запускают повторную отправку.
10. Каждая принятая сервером заявка сопоставлена с записью CRM либо имеет объяснимый статус ожидания.

Процесс продаж

11. Ответственный назначается автоматически по согласованному правилу.
12. Маршрутизация исключает уволенных и временно отсутствующих сотрудников.
13. Установлены сроки ответа и порядок эскалации просрочки.
14. Работает отдельное правило для обращений в нерабочее время.
15. Настроен и проверен сигнал об остановке доставки заявок.

Аудит CRM-интеграции и обработки заявок от Webdelo

В Webdelo мы проверяем всю цепочку: форму, серверную обработку, API или webhook, CRM, уведомления, действия менеджеров и мониторинг. Задача аудита - установить, где нарушается доставка или обработка обращения. Рекомендации связываем с обнаруженным сбоем и его влиянием на работу команды.

В проверку входят:

• Тестовые обращения из согласованного списка форм.
• Сверка сохранённых серверных событий с регистрациями в CRM.
• Проверка полноты полей и правил объединения записей.
• Проверка назначения, уведомлений и эскалации.
• Разбор повторной доставки и восстановления после ошибок.
• Рекомендации по архитектуре и приоритетам исправлений.

Инженерное направление компании представляет CTO Webdelo Андрей Попов. При обсуждении аудита согласуем технические границы проверки и необходимые доступы.

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

Заказать аудит обработки заявок.

Главное о контроле заявок

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

Начните со сверки серверного журнала и CRM. Затем устраните выявленные разрывы доставки и закрепите правила обработки. Такой порядок даёт руководителю проверяемую картину работы с обращениями и основу для решений о дальнейшей автоматизации.