Где теряются заявки между сайтом, мессенджером и CRM: проверка по шагам
Карта пути заявки и журнал расхождений: проверьте доставку из сайта и чатов, очередь CRM, назначение ответственного и первый ответ.
Если в форме есть отправка, а в CRM нет новой карточки, проблема ещё не обязательно в менеджере. Заявка могла не дойти до интеграции, попасть в «неразобранное», склеиться с другой записью или остаться без ответственного. Руководителю продаж стоит проследить несколько реальных обращений от исходного события до первого содержательного ответа. Так станет видно, какой переход чинить и кому поручить проверку.
Сначала договоритесь, что считать потерей
Запись в CRM сама по себе не означает обработанную заявку. Для аудита полезно разделить четыре состояния:
- Не доставлена: исходное обращение есть, подтверждения его приёма системой нет.
- Не найдена: CRM приняла обращение, но менеджер не видит его в рабочей очереди; оно может быть в другом статусе или привязано к прежней карточке.
- Не назначена: карточка существует, но у неё нет владельца или задачи с понятным сроком.
- Без ответа: владелец есть, но клиент не получил содержательного ответа в установленный командой срок.
Срок ответа задайте сами по рабочему графику и типу обращения. Не подменяйте его общим обещанием «ответим за пять минут»: сначала проверьте, способны ли его выполнять. Отдельно отмечайте обращения вне рабочего времени.
Нарисуйте путь одной заявки
Нужна не схема всех интеграций компании, а одна линия для конкретного канала. Например: форма → запись о приёме на сайте → интеграция → очередь CRM → карточка → ответственный → первый ответ. Для мессенджера начните с входящего сообщения и идентификатора беседы.
На каждом переходе спросите две вещи: какой след подтверждает передачу и кто разбирает сбой. Скриншот уведомления в чате — слабое доказательство, если из него нельзя найти карточку. Номер заявки, время, ID сообщения или записи помогают сопоставить события без публикации персональных данных. В amoCRM, например, «неразобранное» собирает обращения из чатов, форм, звонков и почты; запись может быть принята, отклонена или связана с существующей сделкой. Это пример устройства конкретной CRM, а не универсальное правило для любой системы. Источник: документация amoCRM.
| Переход | Что сравнить | Если следа нет | Владелец проверки |
|---|---|---|---|
| Отправка → приём | ID формы или сообщения и время исходного события | Проверить обработчик формы, доступность канала, ошибку приёма | Владелец сайта или канала |
| Приём → CRM | ID события и результат передачи в интеграции | Проверить очередь, ошибку и повторную доставку; не отправлять вручную без проверки дубля | Интегратор CRM |
| CRM → рабочая очередь | ID исходного события, запись в «неразобранном», карточка или связанная сделка | Проверить фильтры, статус, отклонение и правила дублей | Администратор CRM |
| Карточка → ответственный | Время назначения, владелец и задача | Проверить правило распределения и резервного владельца | Руководитель продаж |
| Ответственный → ответ | Время первого содержательного ответа в том же канале | Проверить нагрузку, смены и просроченные задачи | Руководитель смены |
Проведите аудит на выборке, а не по памяти
Возьмите 10–20 обращений из разных каналов и смен. Это рабочий размер для первого ручного аудита, не статистическая норма. Добавьте обычные обращения и сложные: повторное сообщение того же клиента, обращение после закрытия смены, сообщение без телефона, ошибку формы. Сравните исходные журналы каналов с CRM, а не только список карточек в CRM: пропавшая запись не попадёт в CRM-отчёт.
Скопируйте журнал и замените примеры собственными обезличенными ID:
| ID обращения | Канал / время | След приёма | ID в CRM или статус | Ответственный / время | Первый ответ / время | Разрыв и следующий шаг |
|---|---|---|---|---|---|---|
| F-001 | форма, 10:14 | получено, 10:14 | неразобранное, 10:15 | — | — | Проверить очередь и назначение |
| C-002 | чат, 18:48 | получено, 18:48 | сделка 345, 18:49 | М1, 09:03 | 09:15 | Сопоставить с графиком смен |
Эти две строки — учебный пример, а не результат исследования клиента. Храните журнал в разрешённом рабочем контуре; для редакции или подрядчика достаточно обезличенных ID, а не телефонов и переписки. Если доступ к исходным логам ограничен, попросите владельца системы сделать сверку и вернуть только результат по переходам.
Проверьте три частые ловушки
«Карточки нет — значит, заявка не дошла». Поиск только в активной воронке пропускает неразобранное, архивные или связанные записи. В документации amoCRM входящее из разных источников специально может ждать разбора в отдельном статусе. Найдите исходный UID и проверьте итог: принято, отклонено или привязано. Источник: amoCRM.
«Нашли контакт — значит, дубль обработан». Повторное сообщение может относиться к старой сделке или быть новой потребностью того же клиента. Техническое совпадение телефона не решает этот вопрос. В некоторых CRM контроль дублей зависит от включённых настроек и выбранных источников: это прямо оговорено в документации amoCRM; Битрикс24 позволяет выбрать поля, по которым искать совпадения. Проверяйте и саму связку, и то, попало ли новое намерение в работу.
«Ответственный назначен — значит, клиенту ответили». Назначение и ответ — разные события. В системе с журналом изменений полезно отдельно смотреть изменение владельца, статуса и появление сообщения; API событий amoCRM показывает, какие типы событий доступны для такого разбора. Если CRM не сохраняет исходящий ответ, сверяйте его в канале общения.
Решение после аудита
Подсчитайте по каждому переходу: сколько обращений проверено, сколько имеют подтверждённый след, сколько требуют ручного поиска и сколько не получили ответа в выбранный срок. Не складывайте все разрывы в один показатель «потерянных лидов»: один клиент может иметь несколько событий и одну сделку. Исправляйте первый подтверждённый разрыв. Если данные доходят, но зависают без владельца, начните с правил назначения и резервной очереди. Если поток доставлен, но людям трудно понять намерение в свободном тексте, отдельно оцените, когда хватит правил CRM, а когда нужен ИИ.
После изменения повторите аудит на сопоставимых каналах и сменах. Показатель улучшения — не количество новых карточек, а доля обращений с прослеживаемым путём, назначенным владельцем и ответом в вашем сроке. Сложные, спорные и дорогие обращения должны оставаться видимыми человеку, даже если часть маршрута автоматизирована.