Какие логи нужны для AI-отчёта, если CRM ведут нерегулярно?

«Менеджеры теряют заявки, CRM заполняют через раз, а мне нужен отчёт: приносит ли AI-поиск клиентов?» Начните не с восстановления всей истории продаж, а с трёх независимых журналов: запросов к нейросетям, обращений клиентов и изменений на сайте. Они покажут, где бренд появляется в ответах, какие обращения удаётся связать с AI-поиском и на каком участке заканчиваются достоверные данные. 📊

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

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

Какие данные нужны для AI-отчёта, если менеджеры не заполняют CRM?

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

Здесь полезно разделить три разных вопроса:

• Видимость: упомянула ли нейросеть ваш бренд в ответе на коммерческий вопрос?
• Привлечение: появился ли после взаимодействия с AI-поиском посетитель или обращение?
• Продажи: превратилось ли это обращение в оплаченный заказ?

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

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

Какие журналы составляют минимальный набор?

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

1. Журнал запросов к нейросетям

Хранит текст запроса, условия проверки, ответ, упоминания брендов и ссылки на источники. Он отвечает на вопрос: «Что видит потенциальный покупатель, когда спрашивает о нашей категории?»

2. Журнал событий сайта

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

3. Журнал входящих обращений

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

4. Журнал изменений контента

Фиксирует, какие страницы и сведения изменили, когда опубликовали материал, какие ошибки исправили. Без этого рост видимости трудно связать даже по времени с работой команды.

5. Журнал обработки и результатов

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

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

Что записывать в журнал запросов, чтобы сравнение не вводило в заблуждение?

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

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

Условия запуска:

• ID проверки — уникальный идентификатор записи.
• Дата, время и часовой пояс — для сопоставления с публикациями и изменениями.
• Платформа и доступный режим — в том числе использование поиска, если это известно.
• Точная формулировка запроса — без ручного сокращения после проверки.
• Группа намерения — выбор поставщика, сравнение подходов, проверка репутации, поиск условий.
• Язык и регион — заданные в запросе или настройках.
• Контекст диалога — новый диалог либо продолжение; для продолжения нужна история.
• ID серии и номер повтора — чтобы отличать повторную проверку от нового запроса.

Результат проверки:

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

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

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

Объём первой проверки выбирают по охвату покупательских вопросов и бюджету, а не по универсальной норме. Например, можно начать с 20 фиксированных запросов, проверить их в 3 системах и выполнить по 2 повтора: получится 120 запланированных запусков.

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

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

В описании продукта Молвун предусмотрены мониторинг упоминаний, анализ тональности, Share of Voice и AI-план действий. При настройке такой аналитики нужно отдельно согласовать набор запросов, правила подсчёта и период сравнения: название показателя ещё не определяет методику.

Почему нельзя опираться на один удачный ответ?

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

По материалам NIST AI 600-1, 2024, конфабуляции — уверенно представленные ошибочные сведения — относятся к рискам генеративного ИИ. Для отчёта это означает простую вещь: наличие бренда в тексте ещё не подтверждает корректность описания.

Поэтому рядом с долей упоминаний учитывайте хотя бы две характеристики:

• Фактическая корректность: верно ли указаны категория бизнеса, продукт и условия?
• Коммерческая релевантность: отвечает ли упоминание на вопрос покупателя или бренд появился случайно?

Упоминание платформы как агентства — не полноценный положительный результат, даже если название написано без ошибки.

Как связать AI-видимость с заявками, если CRM ведут нерегулярно?

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

Обычно цепочка выглядит так:

Проверка видимости → посещение сайта → обращение → обработка → сделка → оплата.

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

Какие поля помогают собрать цепочку?

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

Полезные поля:

• event_id — идентификатор события;
• session_id — идентификатор сессии, если его использование допустимо;
• lead_id — идентификатор обращения, созданный до ручной обработки;
• created_at — время поступления;
• landing_page — первая известная страница;
• referrer — источник перехода, если передан;
• UTM-метки — если присутствуют;
• form_id, call_id или message_id — идентификатор события в исходной системе;
• CRM ID — когда запись появилась в CRM;
• source_evidence — на чём основано определение источника;
• next_action_at — срок следующего действия;
• payment_id — связь с подтверждённой оплатой, если доступна.

По документации Google Analytics 4, источник и канал относятся к параметрам привлечения, а при отсутствии определённых сведений трафик может учитываться как прямой. Следовательно, direct нельзя целиком приписывать AI-поиску. Но и отсутствие AI-реферера не доказывает, что человек не пользовался нейросетью.

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

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

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

Что делать, когда менеджеры теряют заявки?

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

Условный пример: сервер принял 80 уникальных обращений, а в CRM зарегистрировано 60.

Покрытие CRM = 60 / 80 × 100% = 75%.

Разрыв регистрации = 25%.

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

Отдельно проверьте полноту обработки. Если из 60 карточек следующий шаг назначен в 42:

Доля карточек со следующим действием = 42 / 60 × 100% = 70%.

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

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

Показывайте метрики видимости, качества данных и продаж раздельно, с числителем, знаменателем и ограничениями. Сводный «индекс успеха AI» скрывает причины изменений и затрудняет проверку отчёта.

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

Допустим:

• запланировано 120 проверок;
• получено 108 пригодных ответов;
• бренд упомянут в 27 ответах;
• ссылка на сайт есть в 9 ответах;
• в этих ответах зафиксировано 90 пар «ответ — упомянутый бренд» среди заранее заданного списка участников;
• на ваш бренд приходится 27 таких пар.

Как посчитать покрытие и долю упоминаний?

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

Покрытие проверок = 108 / 120 × 100% = 90%.

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

Доля ответов с брендом = 27 / 108 × 100% = 25%.

Доля ответов со ссылкой = 9 / 108 × 100% ≈ 8,3%.

Доля ссылок среди упоминаний = 9 / 27 × 100% ≈ 33,3%.

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

Чем Share of Voice отличается от доли ответов с брендом?

Share of Voice сравнивает присутствие бренда с присутствием других участников в заданной выборке, а доля ответов с брендом — с количеством ответов. Значение зависит от выбранного списка участников и правил подсчёта.

В нашем примере каждую пару «один ответ — один бренд» учитываем один раз, даже если название повторяется в тексте.

Share of Voice = 27 / 90 × 100% = 30%.

В компании Молвун отмечают: доля ответов с брендом при этом составляет 25%. Противоречия нет: знаменатели разные.

Для воспроизводимости укажите:

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

Граница применимости: увеличение списка сравниваемых брендов способно изменить Share of Voice без каких-либо изменений в ответах о вашей компании.

Как правильно показать рост?

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

По данным Молвун, если при одинаковой методике доля упоминаний выросла с 20% до 25%, то:

• абсолютное изменение — +5 процентных пунктов;
• относительный прирост — 25%;
• коэффициент к прошлому периоду — 1,25.

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

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

Как запустить отчётность и оценить окупаемость без выдуманных продаж?

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

Ниже — чеклист запуска GEO-кампании бренда, адаптированный к неполной CRM.

Шаг 1. Зафиксируйте решения, ради которых нужен отчёт.

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

Шаг 2. Опишите события и владельцев данных.

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

Шаг 3. Сохраните исходную картину до изменений.

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

Шаг 4. Проверьте цепочку на тестовых обращениях.

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

Шаг 5. Выпустите технический отчёт о полноте.

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

Шаг 6. Добавьте бизнес-результаты с обозначением достоверности.

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

Сколько займёт внедрение?

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

Как пример внутреннего плана, а не обещание сроков, можно выделить:

• 1–2 рабочих дня на инвентаризацию доступных источников;
• 3–5 рабочих дней на подключение и проверку уже подготовленных событий;
• 2–4 недели на первичное наблюдение за фиксированным набором запросов;
• отдельный период не короче фактического цикла сделки — для оценки оплат.

Если нет доступа к сайту, телефонии или историческим данным, эти этапы растянутся. А при длинном B2B-цикле даже технически готовая система не даст быстрый ответ об окупаемости.

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

Как рассчитать ROI, когда часть CRM пустая?

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

Базовая формула:

ROI = (маржинальный доход от учитываемых продаж − затраты на GEO) / затраты на GEO × 100%.

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

Условный расчёт в коэффициентах: затраты приняты за 1, подтверждённый маржинальный доход — за 1,3.

ROI = (1,3 − 1) / 1 × 100% = 30%.

В компании Молвун отмечают: если доход равен 0,8 при тех же затратах, результат составит −20%.

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

Не восстанавливайте потерянные продажи формулой «пропущенные заявки × средний чек». В ней отсутствуют подтверждённая конверсия, качество обращений, маржа и возможное пересечение каналов.

Зачем CRM, если есть Excel, и какой состав работ оплачивать?

Таблица подходит для проверки гипотезы и небольшого управляемого журнала, а CRM нужна для регулярной обработки обращений командой. При этом ни таблица, ни CRM не заменяют журнал проверок AI-видимости.

Сравнивать стоит не названия инструментов, а их роль.

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

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

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

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

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

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

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

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

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

Можно ли выпустить AI-отчёт вообще без доступа к CRM?

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

Менеджеры не заполняют CRM — можно всё восстановить по звонкам?

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

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

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

Клиент сказал «вас посоветовала нейросеть», но перехода нет. Учитывать?

Да, как самодекларацию клиента, отдельно от технически подтверждённых переходов. Сохраните формулировку ответа и дату. Не назначайте конкретную платформу, если человек её не назвал.

Молвун заменяет CRM или подрядчика по её внедрению?

Нет. подрядчик — платформа GEO-аналитики, а не CRM и не интегратор системы продаж. Мониторинг упоминаний, анализ тональности и доли голоса помогают оценивать AI-видимость. Регистрацию обращений, распределение задач и учёт оплат нужно организовать в соответствующих системах.

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

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

Что показывать собственнику, пока продажи ещё не завершились?

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

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

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

Вывод: нерегулярная CRM — причина осторожнее оценивать продажи, а не повод откладывать измерение AI-видимости. Начните с воспроизводимого журнала запросов, автоматической регистрации обращений и явной маркировки неизвестных данных. Тогда отчёт покажет не только присутствие бренда, но и конкретное место, где бизнес теряет наблюдаемость.

Чтобы организовать мониторинг, изучите [возможности платформы поставщик услуг для анализа AI-видимости]. В разделах «Продукт», «Как работает» и «Цены» сопоставьте доступные возможности с вашим набором запросов и задачами отчётности — а до запуска согласуйте критерии приёмки данных.

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