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

Разведите объекты до стадий

Объект

Что он означает

Чего не означает

Account

Организация или иной объект отношений

Автоматически квалифицированную сделку

Contact

Конкретный участник и его роль

Единственного лица, принимающего решение

Lead

Входной сигнал или потенциальный контакт по принятому правилу

Подтверждённую задачу

Opportunity

Квалифицированная возможность с задачей и процессом решения

Гарантированный заказ

Proposal / Quote

Описанный scope, цена, сроки и условия

Согласие покупателя

Order / Contract

Доказуемое обязательство сторон

Принятый результат

Delivery / Acceptance

Исполнение и подтверждение результата

Автоматическую повторную продажу

Одна компания может иметь несколько контактов и возможностей. Один контакт может участвовать в нескольких account только по явно разрешённой модели. Смешение объектов делает конверсию и ageing недостоверными.

Три карты под разные циклы

Модель

Последовательность состояний

Главная проверка

Короткая повторяемая сделка

Квалификация → fit → предложение → заказ → исполнение → следующая потребность

Не потерять передачу после заказа

Проектная продажа

Discovery → buying group → требования → решение/pilot → procurement/legal → договор → delivery/acceptance

Доказательство решения и открытые блокеры

Подписка/возобновление

Qualification → activation → value checkpoint → renewal/expansion

Не считать активацию подтверждённой ценностью

Не каждая строка обязана стать колонкой CRM. Объединяйте состояния, если exit evidence, owner и аналитика сохраняются. Разделяйте, когда команда принимает разные решения или теряет важное доказательство.

Базовая карта воронки доказательств

Состояние

Минимальное exit evidence

Обязательные данные

Целевой account

Соответствует записанным fit-критериям

Критерии, источник, owner

Допустимый первый контакт

Получен ответ или документировано основание продолжения

Канал, цель, правовое основание

Задача квалифицирована

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

Need, outcome, disqualifiers

Buying group описана

Роли и процесс решения известны либо пробелы отмечены

Участники, влияние, неизвестные роли

Критерии выбора

Покупатель подтвердил требования и ограничения

Критерии, приоритет, источник

Решение или pilot

Есть согласованное доказательство fit

Scope теста, result, caveats

Предложение рассматривается

Подтверждены scope, цена, срок и следующий шаг

Версия quote, owner, due date

Procurement / legal

Известны требования, owners и открытые блокеры

Документы, решения, сроки

Договор или заказ

Получено доказуемое обязательство

Contract/order ID, сумма, дата

Исполнение

Scope передан с owner и acceptance criteria

Handoff, deadline, obligations

Приёмка / результат

Результат подтверждён либо отклонения зафиксированы

Evidence, issues, owner

Следующая opportunity

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

Need, timing, evidence

DISQUALIFIED

Fit отсутствует до полноценной opportunity

Контролируемая причина

CLOSED_LOST

Возможность существовала, но решение проиграно или остановлено

Причина, альтернатива, evidence

Шаблон стадии CRM

stage_id;state_name;entry_event;buyer_task;required_fields;buying_group_gaps;next_step;owner;due_at;exit_evidence;ageing_signal;stop_reason;allowed_automation;forbidden_automation;metric;harm_guardrail
S01;state_without_manager_action;observable_entry;buyer_task;declared_fields;known_unknowns;one_verifiable_step;responsible_role;date;observable_buyer_change;internal_threshold_from_history;controlled_reason;safe_action;no_fabricated_state_change;event_count_and_time;data_quality

Название стадии описывает состояние, а не активность менеджера. `Презентация отправлена` — событие продавца; `критерии решения подтверждены` — наблюдаемое состояние покупателя.

Пример заполнения одной стадии без вымышленной сделки

Поле

Шаблонное значение

State

Задача квалифицирована

Entry

Покупатель описал текущий процесс и последствие проблемы

Required

Need, desired outcome, known constraints, owner, next step

Exit

Покупатель подтвердил критерии результата и участников следующего шага

Stop

Нет fit, нет задачи, нет допустимого продолжения или срок неизвестен

Guardrail

Менеджер не меняет стадию ради отчёта без evidence

Buying group без мифа об одном ЛПР

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

Правовая граница первого контакта

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

Метрики без вымышленных норм

Метрика

Как считать

Что не делать

Входы и выходы

По событиям смены состояния

Считать текущий snapshot историей

Stage conversion

Выходы в следующее допустимое состояние / зрелые входы

Смешивать несопоставимые сегменты

Stage time

Медиана и распределение времени между событиями

Задавать отраслевой срок без данных

Ageing

Текущее время с последнего entry event

Автоматически закрывать сделку по таймеру

Win / loss

По fit, источнику и контролируемой причине

Подменять unknown удобной причиной

Data completeness

Доля записей с next step, owner и due date

Заполнять фиктивные значения

Post-sale

Доля won, дошедших до acceptance

Считать signed contract результатом клиента

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

Closed Lost и Disqualified — разные исходы

DISQUALIFIED означает, что fit или допустимое продолжение не подтвердились до полноценной opportunity. CLOSED_LOST означает, что возможность существовала, но решение выбрало альтернативу, остановилось или изменилось. Разные справочники причин позволяют исправлять targeting отдельно от execution.

Передача в исполнение и повторная возможность

  1. Передайте утверждённый scope, обязательства, owners, сроки и acceptance criteria.

  2. Зафиксируйте отклонения и подтверждение результата вместо формального статуса won.

  3. Не открывайте повторную opportunity без новой названной задачи или допустимого value checkpoint.

  4. Сохраните историю и ограничения, чтобы не заставлять покупателя повторять discovery.

  5. Свяжите новую возможность с исходным account и результатом, но измеряйте её отдельно.

Еженедельный разбор воронки

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

  • Есть ли в карточке наблюдаемое доказательство текущей стадии, а не только комментарий менеджера?

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

  • Есть ли конкретное следующее действие с владельцем и датой либо честная причина отсутствия даты?

  • Какое условие перевода назад, закрытия как проигранной или дисквалификации уже наступило?

  • Не скрывает ли одна возможность несколько независимых бюджетов, решений или юридических контуров?

  • Переданы ли ограничения, обещания и критерии результата в исполнение после Closed Won?

  • Создана ли отдельная повторная возможность только после нового подтверждённого запроса, а не автоматически?

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

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

Практический следующий шаг

Возьмите десять последних возможностей, восстановите фактические события и нарисуйте путь без названий текущих колонок CRM. Для каждого перехода спросите: какое доказательство изменилось у покупателя? Затем сократите карту, создайте stage template и измеряйте один полный цикл до автоматизации.

Что читать дальше

Источники и дата проверки

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