RevOps в длинной сделке: где на самом деле умирает выручка между первым интересом и внедрением

Когда компания говорит: “нам не хватает входящих”, я почти всегда хочу спросить: вы точно уверены, что проблема на входе? Потому что в длинной сделке одна из самых частых иллюзий - думать, что revenue умирает в начале воронки.

На самом деле в enterprise и сложном B2B деньги очень часто гибнут дальше. Уже после интереса. Уже после первой встречи. Уже после пилота. Уже после красивой презентации. Просто эти потери размазаны по такому количеству handoff и микрорешений, что внутри компании их легко принять за “сложность рынка”.

Что RevOps в длинной сделке означает на практике

RevOps в таком цикле - это не CRM-обновление и не попытка сделать маркетинг “ближе к продажам”. Это способ увидеть всю revenue-механику как единый маршрут:

• откуда приходит интерес;
• кто и как его квалифицирует;
• как строится multi-threading внутри аккаунта;
• что происходит после встречи;
• как устроен пилот;
• как проходит handoff к внедрению;
• когда появляется expansion-логика.

Где чаще всего текут деньги

Ниже - точки, которые я встречаю чаще всего.

1. Слабая квалификация. Компания считает возможностью то, что на деле было просто вежливым интересом.
2. Один champion вместо сети контактов. Сделка держится на одном человеке и умирает вместе с его паузой или увольнением.
3. Никакого внятного next step после встречи. Была хорошая энергия, но не появилось фиксированного следующего хода.
4. Пилот без memo. Все договорились “попробовать”, но не зафиксировали цель, критерии, владельцев, ритм и решение после пилота.
5. Handoff между продажей и внедрением. Продажа что-то пообещала, delivery понял это иначе, доверие клиента просело.
6. Сервис подключается слишком поздно. Customer success появляется уже после того, как ожидания не совпали с реальностью.
7. Нет expansion-слоя. Компания довела до запуска, но не спроектировала следующий revenue-шаг.

Почему всё ломается сразу после встречи

Именно здесь нужны:

• follow-up не ради вежливости, а ради фиксации рамки;
• decision memo по итогам встречи;
• следующий шаг с owner и датой;
• материалы не “вообще про продукт”, а под роль и фазу решения.

Пилот - это не проба, а мост к деньгам

Если у пилота нет memo, то нет и единого ответа на четыре вопроса:

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

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

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

Именно поэтому Sales Enablement и RevOps так тесно связаны. Материалы - это не украшение сделки. Это часть её физики.

Что особенно важно в российском контуре

Но как только цикл усложняется, это перестаёт работать. Нужны уже не только сильные люди, но и revenue-конструкция: единые стадии, revenue-room, материалы, pilot memo, ясный handoff, нормальная дисциплина следующего шага.

Мини-чеклист для self-audit

• Есть ли у вас единое определение “хорошей возможности”?
• Есть ли в сделках multi-threading, а не один champion?
• Есть ли у каждой встречи зафиксированный next step с owner и датой?
• Есть ли у пилота memo и критерии перехода в контракт?
• Есть ли handoff между sales и delivery как формальный объект, а не молчаливое ожидание?
• Есть ли expansion-path уже на этапе внедрения?

Если на половину этих вопросов ответ “нет”, проблема у вас, скорее всего, не во входящих. У вас RevOps-утечка внутри самой сделки.

Что стоит забрать с собой

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

Поэтому зрелый RevOps в enterprise - это не новая бюрократия. Это способ перестать терять деньги в тех местах, которые внутри компании слишком долго считались «просто частью процесса».

Сколько реально теряется на каждом из семи разрывов

Не все утечки одинаково дороги. Из моих RevOps-аудитов в enterprise-компаниях с циклом 6–18 месяцев — типичная статистика по тому, сколько pipeline-ценности умирает на каждом разрыве.

• Слабая квалификация: 15–25% pipeline превращается в pseudo-возможности, которые выглядят живыми в CRM, но на деле клиент уже сказал «нет» или просто проявил вежливый интерес.
• Один champion вместо сети: 20–35% сделок умирает при увольнении champion-а или его смене проекта. Это часто маскируется под «сделка не зашла», хотя реальная причина — отсутствие multi-threading.
• Нет внятного next step после встречи: 12–18% сделок теряются в первые 2–4 недели после первой встречи просто потому, что обе стороны не зафиксировали, что должно случиться дальше.
• Pilot без memo: 30–45% pilot'ов признаются «успешными», но не превращаются в контракт. Главная причина — критерии и решающий не были заранее проговорены.
• Handoff sales→delivery: 15–25% клиентов в первые 90 дней после подписания получают onboarding, не соответствующий их ожиданиям из продажи. Часть из них тихо уходят на следующем годовом цикле.
• Сервис подключается поздно: 10–20% expansion-revenue теряется, потому что customer success не успел установить контакт до того, как у клиента возникли проблемы.
• Нет expansion-слоя: 30–60% потенциального expansion'а не происходит, потому что нет owner-а у этой работы. Этот пункт обычно самый дорогой в долгую — он определяет, есть у компании 1.2x или 1.5x net revenue retention.

Сумма этих утечек в средней enterprise-B2B-компании — 35–55% от потенциального revenue. То есть компания систематически делает половину того, что могла бы делать с теми же лидами и тем же продуктом.

Почему multi-threading — самая недооценённая работа

Из всех семи разрывов один champion вместо сети — это та утечка, на которую sales-команды реагируют хуже всего. Почему-то считается, что «у нас отличный champion, всё под контролем». На практике в enterprise-цикле 6–18 месяцев один champion — это всегда риск.

Что может пойти не так с одним champion-ом за 12 месяцев: ушёл из компании (15–20% за год в активной отрасли), переведён на другой проект (10–15%), потерял внутреннее влияние из-за реорганизации (5–10%), просто перестал отвечать (5–10%). Кумулятивная вероятность хотя бы одного из этих событий за год — 30–45%.

Multi-threading — это построение отношений с 3–5 ролями внутри клиента: champion, бизнес-buyer, technical reviewer, executive sponsor, иногда procurement. Не все из них принимают решение, но каждый может его поддержать или заблокировать. Если champion ушёл, кто-то из остальных продолжает движение сделки. Без этого сделка просто умирает.

Шаблон pilot memo, который реально работает

Pilot memo — это не «формализм для галочки». Это документ на 1 страницу, который превращает «давайте попробуем» в управляемый коммерческий процесс. Что в нём должно быть.

• Цель пилота. Что именно проверяем — конкретная гипотеза или метрика. Не «попробовать продукт», а «проверить, что conversion в demo вырастет с 8% до 15% за 60 дней при правильной настройке».
• Критерии успеха. Конкретные числа или события, которые клиент и поставщик считают доказательством. Без этого pilot заканчивается фразой «вроде неплохо», и сделка стоит на месте.
• Owner с обеих сторон. Имя человека у клиента + имя у поставщика. Это не «их команда» и «наша команда», а конкретные люди с зоной ответственности.
• Регулярный ритм. Weekly или bi-weekly синки на 30 минут. Без этого pilot молча идёт в свою сторону, и через 6 недель никто не знает, что там происходит.
• Решающий после пилота. Кто внутри клиента принимает решение о переходе в полноценный контракт. Заранее проговорено и зафиксировано. Часто оказывается, что это не тот же champion, и эту роль надо отдельно влиять до конца pilot'а.
• Следующий коммерческий шаг при положительном пилоте. Не «обсудим контракт», а «через 7 дней после закрытия pilot мы обсуждаем условия годового контракта с участием X и Y, цель — подписать в течение 30 дней». Это убирает гэп между «пилот успешен» и «деньги пришли».

Revenue-room для длинной сделки

Один из самых дешёвых и эффективных RevOps-инструментов в enterprise — еженедельная revenue-room длительностью 90 минут. Участники: CMO, CRO, директор продаж, руководитель CS, иногда CFO. Что обсуждается:

• Топ-10 крупных аккаунтов: где сейчас, что нового, какой next step.
• Топ-3 риска по сделкам — где champion не отвечает, где появилась новая роль в комитете, где security задаёт вопросы.
• Что нужно от других функций: кейс под отрасль, ROI-расчёт, security-документ, юридическое разъяснение.
• Решения по новым входящим аккаунтам.
• Метрики недели: pipeline by stage, conversion rates, time in stage.

Это не «отчётный комитет». Это рабочая комната, где принимаются решения о конкретных сделках в реальном времени. В компаниях, где такая room работает 6+ месяцев подряд, win rate в enterprise обычно растёт на 10–20%.

Полная revenue-конструкция в длинной сделке

Если собрать всё в одну картину, RevOps в enterprise работает на четырёх уровнях.

Уровень 1: единый язык стадий. MQL, SQL, opportunity, qualified opportunity, proposal, negotiation, closed/won — что значит каждая стадия, какие критерии перехода, какие метрики на каждой. Без этого revenue-room превращается в спор о терминах.

Уровень 2: материалы под роли. Кейс, ROI, demo, security, juridical, executive summary — для каждой ключевой роли в комитете. Это работа на 3–6 месяцев один раз, потом обновляется по мере изменений продукта.

Уровень 3: pilot и handoff протоколы. Стандартные шаблоны, которые работают в 80% случаев и адаптируются под конкретного клиента в оставшихся 20%.

Уровень 4: ритм управления. Weekly revenue-room, monthly review по метрикам, quarterly стратегические сессии. Это и есть то, что превращает «у нас есть процесс» в «у нас работает процесс».