Схема воронки продаж для B2B‑основателей: минимальные поля, стадии и отслеживание активности, чтобы прогнозировать честно и не позволять сделкам тухнуть из‑за раздутой CRM.
Сначала воронка кажется понятной: несколько сделок, и большая часть контекста живёт в голове. Потом список растёт, вы пропускаете фоллоу‑ап, и воронка начинает рассказывать более приятную историю, чем реальность. Это «воронка врет»: не намеренно, а потому что ничего в системе не заставляет говорить правду.
Проявляется это одинаково:
Типичная реакция — перегрузить CRM: больше полей, больше кастомных стадий, длиннее заметки. Парадоксально, но это обычно ухудшает прогнозирование. Обновлять становится тяжело — люди делают это реже, и воронка тихо гниёт.
Минимально жизнеспособная схема воронки делает обратное. Это ровно столько структуры, чтобы принимать решения. Она не пытается зафиксировать всё. Она фиксирует несколько фактов, которые мешают вам обманывать себя.
Если взять одно правило: у каждой открытой сделки должно быть (1) явное следующее действие, (2) дата для этого действия и (3) дата закрытия, привязанная к реальному таймлайну покупателя (встреча, юридический шаг, проверка бюджета). Если чего‑то не хватает, сделка не активна.
Стадии тоже должны иметь смысл. Сделка продвигается вперёд только когда произошло что‑то конкретное, а не потому что так кажется. Цель не в красивой дашборде. Цель — честный вид, на который можно опираться в управлении бизнесом.
Схема воронки работает только если все используют её одинаково. Прежде чем добавлять поля или спорить о стадиях, решите, что представляет собой одна запись сделки.
Чистый дефолт для B2B: одна сделка = одно решение о покупке. Если одна и та же компания может купить дважды (две команды, два продукта, два бюджета) — это две сделки, не одна запутанная запись.
Держите объекты простыми. Можно обойтись тремя сущностями: лид (человек, с которым можно связаться), аккаунт (компания) и сделка (конкретная покупка, которую вы пытаетесь закрыть). Если вы один, можно пропустить формальные лиды и аккаунты и просто убедиться, что у каждой сделки явно указан компания и основной контакт.
Запишите несколько правил работы, особенно если с воронкой работает кто‑то кроме вас:
Пример: вы говорите с Алексом из Northwind о пилоте для финансовой команды. Это одна сделка. Если через месяц продукт захочет отдельный контракт — создайте вторую сделку. Не растягивайте одну запись на два решения.
Воронка остаётся полезной, когда у каждой сделки есть те поля, которые вы действительно проверяете каждую неделю. Добавляйте поля «про всякий случай» — и они превратятся в декор.
Начните с формата названия сделки, который предотвращает дубликаты. Простая схема работает: Компания - Продукт/Объём - Квартал/Месяц. Пример: “Acme - Team plan - март 2026.” Так видно, когда «Acme - Demo» и «Acme - Follow-up» на самом деле одна и та же сделка.
Каждая сделка также нуждается в чёткой идентификации:
Роль важна, потому что она меняет следующий шаг. Чемпиону нужен enablement; лицу, принимающему решение — деловой аргумент.
Добавьте поля ответственности:
Потом добавьте только денежные и временные поля, которые вы будете использовать:
Если сомневаетесь в поле — не добавляйте. Позже можно добавить. Удалять поля после формирования привычек сложнее.
Большинство «больших» воронок на самом деле не большие. В них полно сделок, красиво смотрящихся, но не имеющих пути к «да».
Начните с одного поля, которое заставляет быть конкретным: Use case (объём работ). Опишите, чего хочет добиться покупатель и как выглядит «готово». Если вы не можете описать результат в двух предложениях, скорее всего вы ещё не понимаете сделку.
Далее зафиксируйте процесс принятия решения в одном месте. Это не свалка контактов. Это история о том, как принимается решение: кто подписывает, кто может блокировать и какие шаги нужны (проверка безопасности, юристы, закупки). Если вы не знаете подписанта — считайте сделку ранней.
Добавьте сигнал соответствия по цене, даже грубый. Диапазоны (“< $5k”, “$5–25k”, “$25k+”) подходят, или простая шкала Likely / Unclear / Unlikely по тому, что вы услышали. Цель — остановить продвижение сделок, которые не могут вас позволить.
И наконец, держите поле red flags в одну строку. Если требуется абзац — это заметки.
Компактный набор, работающий для большинства B2B‑основателей:
Пример: «Нужно почистить CRM перед продлением, подписант — VP Sales, требуется проверка безопасности, бюджет вероятно $10–20k, конкурент — оставить как есть, red flag: чемпион не владеет проектом». Такая запись сложнее обмануть себя.
Воронка портится, когда превращается в список желаний. Решение — не в дополнительных полях, а в нескольких сигналах активности, которые заставляют каждую сделку отвечать на вопрос: что происходит дальше?
Если вы добавляете только один уровень в схему воронки, добавьте эти поля активности:
Практичное правило: если у сделки нет следующего шага или срока, это не реальная сделка. Отложите её или закройте. Это делает прогноз точнее больше, чем любая модель скоринга.
Держите «Причину проигрыша» короткой, чтобы вы действительно пользовались ею: цена, нет бюджета, нет решения, выбрали конкурента, не подходит по таймингу, не соответствует.
Как это выглядит: у вас демо с операционным руководителем во вторник. Сразу после звонка вы ставите дату последней активности = вторник, канал = встреча, следующий шаг = «Отправить 2 примера кейсов и подтвердить, кто подписывает», срок следующего шага = четверг. Если в четверг ответа нет — сделка идёт в красную зону без споров о «прогрессе».
Хорошая модель стадий делает одну работу: честно показывает, где каждая сделка, без нужды присматривать за десятком мелких шагов. Если вы не можете сказать, что должно быть истинным, чтобы сделка была в стадии — стадия превратится в ощущение.
Эта шестиступенчатая модель подходит большинству B2B‑основателей:
New: есть имя и причина для контакта. Первый контакт выполнен или запланирован.
Qualified: подтверждена базовая пригодность. Проблема реальна, клиент соответствует ICP, есть правдоподобный путь к покупке.
Discovery done: состоялся реальный разговор. Вы понимаете use case, критерии успеха и вовлечённых лиц.
Proposal sent: цена и объём в руках клиента. Записан или явно запрошен следующий шаг.
Negotiation/Legal: идут закупки, проверка безопасности, согласование бюджета или правки контракта.
Closed won / Closed lost: помечен результат и зафиксирована причина.
Двигайте сделку вперёд только когда произошло что‑то в реальном мире (встреча состоялась, предложение отправлено, началась юридическая проверка). Если ничего не происходило — стадия остаётся прежней.
Название стадии — это не её определение. Если вы просто пометите колонку «Qualified» или «Negotiation», в ней окажутся сделки, потому что никто не договорился, что «завершение» значит.
Пишите правила стадии как простые проверки true/false. Когда у каждой сделки в стадии одинаковые факты, ваша воронка остаётся надёжной.
Критерий входа говорит, что уже должно быть правдой, чтобы сделка вошла в стадию. Критерий выхода — что должно измениться, чтобы она могла продвинуться. Держите оба короткими и измеримыми.
Примеры:
Если вы не можете написать критерии без слов типа «хорошо», «сильный» или «заинтересован» — стадия слишком расплывчатая.
Задайте максимальный возраст для каждой стадии как раннее предупреждение, не как наказание. Пример: Discovery макс 14 дней, Proposal макс 21 день. Когда сделка достигает лимита — срабатывает сброс: назначьте следующий шаг, верните её назад или закройте.
Решите стандартное действие, когда критерии не выполняются:
Это предотвращает «зомби‑сделки», раздутые ваш прогноз.
Схему воронки можно собрать за несколько часов, если относиться к ней как к небольшому продукту: сначала правила, потом только то, что эти правила поддерживает.
Начните с чистого листа, а не внутри инструмента. Запишите стадии и критерии входа/выхода простым языком. Если вы не можете объяснить стадию одним предложением — это, вероятно, две стадии (или не стадия вовсе).
Простой поток сборки:
Проверьте на практике: возьмите активную сделку и попытайтесь продвинуть её по стадиям. Если вы постоянно угадываете — критерии слишком расплывчатые.
Одно правило, которое стоит ввести сразу: если дата следующей активности пуста, сделка не может оставаться в активной стадии.
Большинство перегрузок CRM рождается из хороших намерений: вы хотите точности, поэтому добавляете поля, стадии и заметки. Результат — обратный. Люди перестают обновлять систему, и воронка превращается в кладбище сделок.
Если две стадии ощущаются одинаково, они будут использоваться одинаково. «Discovery», «Deep discovery» и «Discovery follow‑up» часто означают «мы поговорили», без явного следующего события. Стадии должны меняться только когда происходит реальное изменение.
Быстрый тест: если вы не можете в одном предложении сказать, что нужно, чтобы войти в стадию — скорее всего, она лишняя.
Дата закрытия полезна только если привязана к причине. Рассматривайте её как дату следующей точки принятия решения (утверждение бюджета, встреча по закупкам, крайний срок подписи) и двигайте её, когда это событие сдвигается.
Длинные заметки скрывают одно важное: что произошло последним и что происходит следующим. Держите заметки короткими, а активность отслеживайте через дату последней активности и следующий шаг (владелец + срок).
Без определения «qualified» превращается в «они звучали неплохо». Выберите 3–4 проверки, которые обязательно должны быть истинны (проблема, покупатель, таймлайн, какой‑то признак бюджета). Если чего‑то не хватает — это ещё не qualified.
Воронки, которые только растут, перестают быть воронкой и превращаются в свалку. Закрывайте как проигранные быстро, когда сделка неактивна или не подходит, и фиксируйте одну ясную причину, чтобы учиться.
Выберите одно время в неделю (30 минут достаточно) и относитесь к нему как к встрече с вашим будущим «я». Гигиена воронки — это не про добавление полей, а про то, чтобы у каждой сделки оставался реальный путь вперёд.
Простой поток обзора:
Конкретный пример: сделка помечена «Proposal sent», но нет встречи для её обсуждения — это не стадия «Proposal». Верните назад, назначьте следующий шаг и перестаньте считать её до тех пор, пока покупатель не включится снова.
Вы продаёте B2B‑инструмент аналитики компании на 50 человек. После первого звонка вы создаёте сделку и заполняете только то, что пригодится на следующей неделе. Простая схема приносит пользу тем, что требует ясности, а не бумажной работы.
Сразу после звонка запись выглядит так:
Сделка начинается в Discovery. Вы переводите её только после подтверждения календарного приглашения (не когда «кто‑то сказал, что заинтересован»). После демо триггером для перехода в оценку будет конкретная просьба (например, «Подключитесь к Shopify и нашим складам»), за которой последует согласованная техническая проверка.
Теперь ступор: CFO перестаёт отвечать после обсуждения цены. В журнале видно два фоллоу‑апа, ответа нет, и срок следующего шага проходит. Правило простое: если нет согласованного следующего шага, сделка не может оставаться в Proposal.
Вы делаете честный шаг: либо возвращаете её на стадию оценки (если нужен новый спонсор или информация), либо закрываете как проигранную (если лицо, принимающее решение, не включается в срок). В примере вы возвращаете сделку, обновляете заинтересованных лиц (Ops привлекает менеджера по финансам), ставите новую дату следующего шага и возвращаете в Proposal только после того, как CFO подтвердит встречу по решению.
Схема воронки работает только если ей доверяют. Самый быстрый путь — начать минимально и пожить с этим 30 дней. Это покажет, что вы действительно используете, а не то, что думаете, что может понадобиться.
В первый месяц будьте строги: если поле не меняет решения — уберите его. Если появляется повторяющийся вопрос, и вы не можете ответить на него из воронки — добавьте ровно одно поле для этой пробелы.
Простой тест перед любым новым полем: «Если это пусто, мы не сможем решить, ___?»
Если вы хотите собрать лёгкую кастомную CRM вместо того, чтобы подгонять универсальную, инструменты вроде Koder.ai (koder.ai) помогут, когда вы уже пропишете стадии, обязательные поля и правила валидации. Проще генерировать и итерационно улучшать простое приложение, когда схема уже ясна.
Пайплайн «врет», когда он показывает прогресс, который не подтверждается реальными действиями покупателя. Самые распространённые причины — отсутствующие следующие шаги, устаревшая дата последней активности и сдвигаемые в будущее даты закрытия без подтверждённой от покупателя временной точки.
Сделайте три поля обязательными для каждой открытой сделки: конкретное следующее действие, срок для этого шага и дата закрытия, привязанная к реальному событию у покупателя (встреча, проверка, подпись). Если хоть одно из них пустое, считайте сделку неактивной, пока это не исправлено.
По умолчанию: одна сделка = одно решение о покупке. Если одна и та же компания может купить дважды через разные команды, бюджеты или контракты, создавайте отдельные сделки, чтобы не смешивать разные сроки и заинтересованных лиц в одной записи.
Начните с формата названия сделки, который предотвращает дубликаты, компании, основного контакта, владельца, ожидаемой суммы, целевой даты закрытия и источника. Затем добавьте столько квалифицирующих полей, сколько нужно, чтобы объяснить, почему сделка должна закрыться: use case, процесс принятия решения и соответствие по цене.
Короткая формулировка use case плюс критерии успеха заставляет вас думать о результате, а не о интересе покупателя. Если вы не можете чётко описать результат в одном предложении, скорее всего сделка ещё слишком ранняя для прогноза.
Опишите процесс как короткую историю: кто подписывает, кто может заблокировать и какие шаги нужны (проверка безопасности, юридический отдел, закупки). Если вы ещё не знаете подписанта, держите сделку на ранней стадии и направьте следующий шаг на поиск этого человека и процесса.
Используйте приблизительный диапазон или простую шкалу Likely/Unclear/Unlikely на основе услышанного. Цель — не идеальная финансовая модель, а остановить продвижение сделок, у которых бюджет не соответствует вашему предложению.
Отслеживайте дату последней активности, следующий шаг, срок следующего шага и причину закрытия в конце. Заметки могут оставаться, но именно эти поля не дают сделкам «дрейфовать» и вынуждают решать, что будет дальше.
Перемещайте сделки между стадиями только после реального события: проведённый звонок, отправленное коммерческое предложение или подключение юридического отдела. Если перемещение может произойти только потому, что «вроде бы всё хорошо», определение стадии слишком расплывчатое и прогноз начнёт искажаться.
Задайте максимальное число дней для каждой стадии как раннее предупреждение, затем при достижении лимита выполните одно из простых действий: назначьте реальный следующий шаг, верните сделку на предыдущую стадию или закройте как «без решения» после оговорённого числа попыток контакта.
