Как увидеть всю воронку продаж до оплаты, отмены и возврата

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

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

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

В этой статье не выбираем CRM, BI-систему или «самый прибыльный» рекламный канал. Сначала разберём, как сделать воронку продаж проверяемой: от маркетинга и первого обращения через продажу до оплаты, отмены или возврата. Такой контур нужен и B2B с длинным согласованием, и интернет-магазину, и услугам по записи; меняются доказательства переходов, а не сам принцип. Базовые роли и границы инструмента собраны в материале о CRM. Для следующего шага по связке расходов, обращений, сделок и оплат полезен материал о сквозной аналитике. Экономику уже связанной цепочки разбирает материал об окупаемости каналов привлечения.

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

Удобно разделить три слоя. Первый — наблюдение: мы видим факт в отчёте. Второй — разбор причины: проверяем данные, выборку случаев и процесс, а не ищем виноватого по графику. Третий — действие: меняем правило, доступ, уведомление, распределение заявок или саму передачу между системами, а затем сверяем результат. В процессном подходе ISO эта логика описана через входы и выходы работ, критерии, ответственность, мониторинг и улучшение. Для продаж это не означает «сертифицировать воронку»: это простой способ не путать красивую визуализацию с работающим контуром.

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

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

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

Название стадии в CRM — не факт: фактом становится событие, которое можно подтвердить в системе-источнике.

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

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

Для офлайн-конверсий Яндекс Метрика связывает визит с событием по ClientID, UserID, yclid или PurchaseId. Телефон и email относятся к данным клиентов и заказов из CRM: ими можно сопоставить CRM-запись с визитом, но это отдельный механизм. За пределами конкретной интеграции не запоминайте этот список как рецепт: фиксируйте общий идентификатор или правило сопоставления. Кроме того, у Метрики есть собственные окна дополнения данных — 21 день для визита и до 111 дней для изменения заказа из CRM. Для длинного B2B-цикла это не «ошибка аналитики», а ограничение, которое надо учесть в проектировании отчёта и в ручной сверке.

Системы по-разному называют даже базовые сущности. В Битрикс24 режим CRM может работать с лидами или сразу со сделками; в 1С:УНФ есть связка лида, заказа, оплат и взаиморасчётов. Из этого не следует, что один продукт лучше другого. Следует другое: нельзя копировать названия сущностей из интерфейса в регламент продаж. Компания сначала формулирует, что для неё означает «квалифицирован», «согласован» и «оплачен», а потом настраивает поля и интеграции под эти определения.

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

Стандарт ISO/IEC 25012 рассматривает качество данных отдельно: для обмена между системами важны хотя бы полнота, непротиворечивость и однозначность смысла. В продажах это переводится в конкретные проверки. Полнота — у лида есть канал, контакт, дата и связка со сделкой. Непротиворечивость — сумма заказа, валюта и статус не расходятся между CRM и учётной системой без понятной причины. Однозначность — «оплата» и «подтверждённая оплата» не оказываются одним и тем же словом для разных людей.

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

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

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

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

Для каждой точки сверки ответьте на пять вопросов:

В проектном управлении есть RACI — способ различить того, кто выполняет работу, и того, кто отвечает за результат. Необязательно строить вокруг продаж отдельную RACI-матрицу. Её полезный смысл проще: проверяющий и принимающий решение не всегда один человек. Руководитель маркетинга может обнаружить потерю UTM-меток, специалист по интеграциям — найти сбой передачи, а коммерческий директор — решить, менять ли порядок распределения лидов. Нельзя назначить маркетинг ответственным за оплату, если у него нет доступа ни к счёту, ни к условиям сделки.

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

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

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

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

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

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

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

В B2B-поставке оборудования обращение может перейти в квалификацию только после уточнения номенклатуры, объёма и технических требований. Предложение — это версия расчёта с понятным составом, а не просто статус «КП». После согласования может появиться счёт, затем частичная оплата и изменение комплектации. Здесь опасно ставить равенство между отправленным предложением и продажей: длинный цикл маскирует задержки, а отдельный платёж не всегда означает закрытие обязательства.

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

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

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

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

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

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

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

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

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

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

Автоматизация хорошего маршрута экономит время; автоматизация неясного маршрута прячет ошибку глубже.

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

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