Сквозная аналитика для B2B: когда достаточно таблицы, а когда нужна CRM

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

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

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

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

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

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

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

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

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

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

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

UTM-метки используют единый справочник. Значения utm_source, utm_medium, utm_campaign, utm_content и utm_term записываются без свободных вариантов. Внутренние ссылки сайта не получают UTM, иначе источник сессии может измениться.

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

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

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

Маркетинг и продажи используют одинаковые названия. google / cpc, instagram / organic_social и другие значения записываются по одному правилу. Статусы отвечают на деловой вопрос: новая заявка, квалификация, расчет, предложение, договор, оплата или отказ.

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

Форма создает строку или карточку с контактом, услугой, источником и страницей. Телефония передает номер и рекламный источник, если используется коллтрекинг. WhatsApp, Telegram и email получают отдельный порядок регистрации.

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

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

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

Рекламные кабинеты получают больше данных, когда компания записывает квалифицированные и закрытые сделки. Google рекомендует использовать цели qualified lead или converted lead для enhanced conversions for leads. С 15 июня 2026 года Google переводит загрузки офлайн-конверсий и enhanced conversions for leads на Data Manager API; текущую схему нужно сверять с официальной справкой Google Ads.

Google использует хешированные данные, предоставленные пользователем, и рекламные идентификаторы для сопоставления офлайн-результата с рекламным взаимодействием. Перед внедрением компания утверждает состав данных, условия передачи и сроки хранения.

GA4 распределяет вклад каналов по модели атрибуции. В отчетах доступны data-driven, paid and organic last click и Google paid channels last click. Модели отвечают на вопрос о распределении вклада, а CRM записывает фактический статус и сумму.

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

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

Одного успешного теста мало для постоянного контроля. После изменений формы, CRM, телефонии, домена или рекламного кабинета проверку повторяют.

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

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

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

Meta Conversions API передает события с сервера и может работать вместе с Pixel. Такой вариант снижает зависимость от ошибок загрузки браузера, передачи данных и блокировщиков. При передаче одного события из браузера и сервера используют одинаковый event_id, чтобы система распознала повтор.

Серверная отправка не исправляет неверный статус в CRM. Сначала компания определяет событие: новая заявка, квалифицированная заявка, договор или оплата. Затем разработчик настраивает передачу и проверяет события в Events Manager.

Состав параметров согласуют с политикой обработки данных и настройками согласия. Описание возможностей доступно в справке Meta о Conversions API.

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

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

ROMI и ROAS рассчитывают по утвержденной методике. В расчет входят рекламные расходы, работа подрядчика, разработка, телефония, CRM и другие затраты, если руководитель использует показатель для решения по бюджету. Формула и состав затрат записываются рядом с отчетом.

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

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

Такое разделение дает руководителю два отчета. Товарное направление оценивается по заявкам с перечнем и количеством. Проектное направление - по обращениям с параметрами объекта и переходом к расчету. Общий CPL скрывал бы эту разницу.

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

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

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

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

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

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

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

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

Метриум рассчитывает объем после проверки текущей схемы. Публичный диапазон без списка систем и интеграций дал бы неверное ожидание по сроку и стоимости.

Самая частая ошибка - разные значения одного источника. google, Google Ads, google_ads и adwords попадают в разные строки. Справочник устраняет дубли.

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

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

Четвертая ошибка - загрузка всех заявок как основной цели рекламного кабинета. Алгоритм получает обращения разного качества. Цель для оптимизации выбирают после накопления стабильных данных и проверки процесса квалификации.

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

Статья 12 Закона Республики Казахстан «О персональных данных и их защите» требует собирать данные, необходимые и достаточные для задачи, и хранить их в базе на территории Казахстана. Собственник или оператор должен подтверждать получение согласия в предусмотренных законом случаях и прекращать обработку после отзыва в установленный срок, если закон не требует продолжения.

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

Подробная техническая проверка формы и политики разобрана в материале о персональных данных на сайте в Казахстане.

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

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

Основную цель выбирают по бизнес-задаче и качеству данных. Для B2B часто важнее квалифицированная или закрытая заявка. Новую цель сначала проверяют как вторичную и сопоставляют с CRM, затем используют для оптимизации после накопления стабильных данных.

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

BI нужен при нескольких юридических лицах, CRM, учетных системах, филиалах и сложных финансовых отчетах. Один сайт и один процесс продаж обычно можно начать с CRM-отчета или таблицы.

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

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

Метриум проводит аудит форм, событий, UTM, звонков, мессенджеров, CRM-статусов и отчетов. Состав работ и этапы описаны на странице сквозной аналитики и CRM. Для обсуждения проекта оставьте заявку на расчет: мы уточним каналы, систему учета и результат, который требуется руководителю.

• Google Ads: enhanced conversions for leads и Data Manager
• Google Ads: вопросы об импорте офлайн-конверсий
• Google Analytics: модели атрибуции
• Meta: Conversions API
• Закон Республики Казахстан «О персональных данных и их защите»