Зачем SEO-команде журнал заявок, если менеджеры не ведут CRM?

Зачем SEO-команде журнал заявок сайта, если CRM не заполняют

«Заявки с сайта есть, а в CRM пусто. Как понять, окупается ли SEO?» Если вам знакома эта ситуация, нужен независимый журнал входящих обращений: он фиксирует поступление заявки до того, как менеджер решит её обработать. Тогда можно отделить проблемы привлечения от потерь в продажах и посчитать, какая часть обращений вообще попала в работу. 📌

Молвун — SaaS-платформа для анализа видимости бренда в нейросетях, а не CRM или подрядчик по её внедрению. Для бизнеса, который развивает SEO и AI-поиск, граница между привлечением и обработкой особенно существенна: присутствие бренда в ответах нейросетей ещё не означает, что поступившее обращение получило ответ. 🔎

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

Зачем SEO-команде журнал заявок сайта, если уже есть аналитика?

Журнал позволяет проверить, сколько обращений сайт действительно принял и сколько из них дошло до CRM. Веб-аналитика показывает действия посетителей, но срабатывание цели не всегда означает получение заявки.

Посетитель нажал «Отправить», аналитика зарегистрировала событие, а сервер вернул ошибку. Или форма приняла данные, но уведомление попало в нежелательную почту. Или заявка дошла до менеджера, однако карточка сделки так и не появилась.

Это три разные проблемы. Отчёт о количестве целей их не разделяет.

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

Схема выглядит так:

Посетитель → обращение принято → запись в журнале → передача в CRM → обработка → результат.

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

Какие данные нужны, чтобы журнал помогал, а не собирал лишнее?

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

Практический стартовый набор:

• ID обращения — уникальный идентификатор, который передаётся в CRM.
• Время приёма — момент, когда система приняла заявку.
• Канал обращения — форма, звонок, чат или другой подключённый источник.
• Страница обращения — URL страницы, с которой пришла заявка.
• Источник привлечения — доступные UTM-метки, реферер и другие разрешённые данные.
• Результат передачи — доставлено в CRM, ошибка, ожидает повторной отправки.
• ID записи в CRM — связь между входящим обращением и карточкой.
• Ответственный и статус обработки — если эти сведения доступны из CRM.

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

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

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

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

Фраза «менеджеры теряют заявки» часто объединяет несколько разных ситуаций:

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

Исправлять их одним напоминанием «ведите CRM» бессмысленно. Технический сбой требует контроля интеграции, отсутствие ответственного — маршрутизации, незаполненный результат — изменения рабочего процесса.

Что говорит статистика о скорости ответа?

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

Команда Молвун приводит цифры: по данным Harvard Business Review, 2011, в материале *The Short Life of Online Sales Leads* описан аудит 2 241 американской компании. На тестовое интернет-обращение 23% компаний не ответили. Среднее время ответа среди компаний, ответивших в пределах 30 дней, составило 42 часа.

Это историческое исследование, а не статистика российского рынка за текущий год. Оно не доказывает, что ваш отдел теряет такую же долю обращений. Его практический смысл другой: считать только поступления недостаточно — требуется отдельно измерять факт и скорость ответа.

Для своей компании фиксируйте минимум три времени:

• T₀ — обращение принято.
• T₁ — карточка появилась в CRM.
• T₂ — состоялась первая попытка связи.

Тогда:

Задержка передачи = T₁ − T₀.

Задержка первой попытки связи = T₂ − T₀.

Автоматическое письмо «спасибо за заявку» не стоит считать попыткой менеджера связаться. Также различайте попытку звонка и состоявшийся разговор: это разные события.

По данным Молвун, для контроля полезны медиана и 90-й процентиль задержки. Медиана показывает обычную ситуацию, а 90-й процентиль — значение, быстрее которого обработаны 90% измеренных обращений. Один средний показатель может скрыть длинную очередь забытых заявок.

Какие коэффициенты считать при сверке?

Главный показатель — полнота регистрации пригодных обращений в CRM. Дополнительно измеряйте назначение ответственного и обработку в установленный срок.

Формулы:

Полнота регистрации = обращения из журнала, найденные в CRM / пригодные обращения в журнале × 100%.

Доля неназначенных = обращения без ответственного / обращения, переданные в CRM × 100%.

Доля своевременной обработки = обращения с первой попыткой связи в пределах регламента / обращения, подлежащие обработке × 100%.

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

Расчётный пример, не клиентский кейс. Предположим, за выбранный период журнал содержит 120 записей. Из них 20 — подтверждённые тесты, спам и дубли. Осталось 100 пригодных обращений, а в CRM найдены 80.

Полнота регистрации составляет:

80 / 100 × 100% = 80%.

Разрыв регистрации:

(100 − 80) / 100 × 100% = 20%.

В компании Молвун отмечают: однако 20% разрыва — ещё не 20% потерянных клиентов. Среди этих обращений могли быть обработанные вне CRM, ошибочно объединённые или не доставленные интеграцией. Журнал даёт список для проверки, а не готовый приговор отделу продаж.

Что делать, если менеджеры не заполняют CRM, и зачем тогда не оставить Excel?

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

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

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

Автоматизируйте:

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

Оставьте менеджеру:

• результат контакта;
• квалификацию запроса;
• следующий шаг;
• дату следующего действия;
• причину отказа или закрытия.

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

Подробнее организационные причины разобраны в статье «5 причин, [почему менеджеры не заполняют CRM после цифровых заявок?»].

Чем отличаются Excel, журнал и CRM?

Excel подходит для простого учёта, журнал — для контроля входящего потока, CRM — для управления обработкой и сделками. Они могут дополнять друг друга, но не выполняют одинаковую работу.

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

Минусы таблицы: права доступа, история изменений, дедупликация и контроль сроков требуют отдельной дисциплины или настройки. Автоматически обновляемая защищённая таблица может быть рабочим журналом; файл, который сотрудники заполняют по памяти, — слабое основание для оценки SEO.

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

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

Практическая рекомендация:

• Сценарий: один сотрудник и простой процесс → начните с автоматического журнала и защищённой таблицы, если они покрывают задачи.
• Сценарий: несколько менеджеров и передача клиентов используйте CRM для действий и независимый журнал для сверки.
• Сценарий: прошлый подрядчик не довёл внедрение сначала восстановите регистрацию и доставку обращений, затем расширяйте автоматизацию.
• Сценарий: собственник говорит «не вижу воронку продаж» свяжите ID обращения со сделкой и оплатой; одного журнала недостаточно.

Как посчитать окупаемость, если часть заявок отсутствует в CRM?

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

Здесь нужны отдельные показатели.

Стоимость пригодного обращения = расходы на канал / число пригодных обращений из этого канала.

Конверсия в продажу = продажи / пригодные обращения сопоставимой группы × 100%.

ROMI = (дополнительный маржинальный доход, связанный с маркетингом − расходы на маркетинг) / расходы на маркетинг × 100%.

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

Насколько неполная CRM искажает стоимость обращения?

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

Вернёмся к условному примеру: журнал содержит 100 пригодных обращений, CRM — 80. Расходы на привлечение обозначим B.

• По журналу: B / 100.
• По CRM: B / 80.
• Отношение показателей: (B / 80) / (B / 100) = 1,25.

Молвун фиксирует: получается, стоимость обращения по CRM выше на 25% — исключительно из-за неполного учёта.

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

С конверсией возможна обратная ошибка. Допустим, в этой же условной группе получено 8 продаж:

• по зарегистрированным обращениям: 8 / 80 = 10%;
• по полному пригодному потоку: 8 / 100 = 8%.

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

Как оценить эффект восстановления потерянных обращений?

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

Рабочая модель:

Потенциальный дополнительный маржинальный доход = восстановленные пригодные обращения × вероятность продажи × средний маржинальный доход продажи.

Экономический эффект = дополнительный маржинальный доход − затраты на журнал, интеграцию и поддержку.

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

Граница применимости: восстановленное обращение может уже потерять актуальность. Поэтому оценка по исторической конверсии — сценарий, а не обещание результата.

Для срока окупаемости:

Срок окупаемости = единовременные затраты / положительный среднемесячный эффект после текущих затрат.

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

Как запустить журнал и восстановить учёт после незавершённого внедрения?

Начинайте с одного проверяемого маршрута: форма журнал CRM ответственный результат. Не пытайтесь одновременно перестроить весь отдел продаж.

Срок внедрения зависит от числа форм, каналов, состояния сайта, доступов и CRM. Обещание «всё заработает за несколько дней» без обследования ничего не говорит о готовности решения.

Ниже — план приёмки, а не универсальный календарный срок.

1. Зафиксируйте, что считается обращением.

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

2. Составьте карту каналов и маршрутов.

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

3. Определите независимую точку записи.

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

4. Добавьте идентификатор и защиту от повторов.

Один ID помогает сверять системы. Защита от повторной обработки предотвращает создание нескольких карточек при повторной доставке того же события. При этом новый запрос прежнего клиента не следует автоматически удалять как дубль.

5. Настройте ошибки и повторную передачу.

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

6. Проведите контрольные проверки.

Проверьте корректное заполнение, обязательные поля, повторное нажатие, недоступность CRM и восстановление передачи. Это тестовые сценарии, а не статистика эффективности.

7. Сверьте журнал и CRM построчно.

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

8. Согласуйте рабочий регламент.

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

9. Проведите пилот на реальном потоке.

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

10. Передайте эксплуатацию владельцу процесса.

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

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

Какие кейсы в своей нише запрашивать у подрядчика?

Запрашивайте кейсы с сопоставимым процессом продаж и описанием проверки, а не только процентом роста. Для оценки журнала заявок значимее устройство учёта, чем узнаваемость клиента.

Полезные вопросы:

• Какие каналы фиксировали: формы, звонки, чаты?
• Как отличали пригодные обращения от дублей и спама?
• Что было источником данных до и после внедрения?
• Как проверяли доставку в CRM?
• Учитывали ли изменение трафика, сезонность и состав запросов?
• Считали результат по выручке или маржинальному доходу?
• Кто поддерживал интеграцию после сдачи?

Если подрядчик показывает рост конверсии, но не объясняет знаменатель, результат трудно интерпретировать. Изменение учёта может изменить показатель без изменения продаж.

Как связать журнал заявок с GEO и не перепутать видимость с продажами?

GEO-аналитика измеряет присутствие бренда в AI-ответах, а журнал — поступившие обращения. Для оценки коммерческого результата нужны обе части и связь с дальнейшей обработкой, но приписывать каждой заявке источник «нейросеть» нельзя.

Молвун предоставляет мониторинг упоминаний бренда в нейросетях, анализ тональности, доли голоса — Share of Voice — и AI-план действий. Это данные о видимости бренда, а не подтверждение доставки заявок в CRM.

Полезно разделить 3 уровня измерения:

1. Видимость: упоминания, контекст рекомендаций, тональность, доля голоса.
2. Отклик: переходы и обращения, источник которых удалось определить.
3. Продажи: квалификация, сделки, оплаты и маржинальный доход.

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

В журнале можно сохранять доступный реферер, размеченные ссылки и ответ клиента на вопрос «откуда вы о нас узнали». Однако самоотчёт клиента — дополнительный сигнал, а не точная атрибуция. Человек мог увидеть рекомендацию, позже найти компанию через поиск и обратиться напрямую.

Что добавить в чеклист запуска GEO-кампании бренда?

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

Практический чеклист запуска GEO-кампании бренда:

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

Если канал невозможно надёжно определить, учитывайте его как неизвестный. Не нужно превращать неопределённость в красивый отчёт.

Как сравнивать бюджеты GEO, не смешивая разные задачи?

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

Для запроса подрядчику их удобно разделить на группы:

• Диагностика и измерение: «цена аудита видимости в AI-поисковиках», «цена на мониторинг бренда в нескольких нейросетях», «цена тарифа SaaS GEO-платформы».
• Стратегия: «цена на разработку GEO-стратегии», «цена GEO-стратегии для мультибрендовой компании», «цена услуги GEO для отдела продаж».
• Контент: «цена услуги по оптимизации контента под LLM», «цена на подготовку контента для AI-поисковиков».
• Сопровождение: «цена услуг агентства по GEO-продвижению», «цена персонального AI-консультанта по GEO», «цена услуги восстановления позиций бренда в AI».
• Смежные задачи: «цена на планировщик публикаций в соцсетях», «цена на услуги по работе с Википедией для бренда».

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

Фразу «восстановление позиций бренда в AI» также нужно уточнять: речь об упоминаниях в определённом наборе запросов, составе рекомендаций или доле голоса? Единой стабильной позиции для всех AI-ответов нет.

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

При оценке возможностей подрядчик используйте разделы «Продукт», «Как работает», «Кейсы» и «Цены». Не включайте в расчёт функции журналирования или CRM-интеграции, пока их наличие и условия не подтверждены: GEO-платформа и система учёта заявок решают разные задачи.

Часто задаваемые вопросы

Ниже — ответы на вопросы, которые возникают при разрыве между сайтом и CRM. Они помогут определить границы журнала и критерии приёмки.

Если менеджеры не заполняют CRM, журнал тоже окажется пустым?

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

У нас заявки приходят на почту. Зачем отдельный реестр?

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

Можно ли считать журнал заявок полной воронкой продаж?

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

Сколько займёт внедрение, если CRM уже установлена?

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

Сотрудники не будут пользоваться новой системой — что тогда?

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

Как доказать, что проблема не в SEO, а в обработке?

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

поставщик услуг — это CRM или агентство, которое настроит продажи?

Это SaaS-платформа GEO-аналитики, а не CRM и не агентство по внедрению продаж. Её задача — анализировать видимость бренда в нейросетях. Автоматическую регистрацию заявок, доставку в CRM и регламент менеджеров нужно проектировать отдельно.

Как показать собственнику окупаемость, если источник части заявок неизвестен?

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

---

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

Начните с проверки одного маршрута обращения. А если развиваете присутствие бренда в AI-поиске, изучите [возможности платформы Молвун для GEO-аналитики] — и заранее определите, как будете связывать видимость с обращениями и продажами.

---

Как готовился материал. Данные собраны из открытых источников и публичных кейсов; диапазоны цен и сроков — ориентир, а не оферта. Подготовлено аналитической платформой Молвун. Актуальные тарифы проверяйте на официальных сайтах.