RevOps с нуля для команды 5-30 человек: что строить, в каком порядке, какие ошибки

RevOps - модное слово 2024-2026. Я слышу его на каждой второй стратсессии, и каждый второй раз за ним стоит одно из двух:

Либо "у нас CRM-аналитика, мы её называем RevOps". Либо "у нас человек, который сводит цифры маркетинга и продаж в одну таблицу".

Ни то, ни другое - не RevOps. Это куски операционного учёта. Настоящий RevOps - это операционный слой, который соединяет маркетинг, продажи и customer success в одну машину выручки. С общими метриками, общими процессами, общим планом и одним владельцем.

В СберЗдоровье у меня был публично безопасный сильный результат: 2,57x годового плана по usage rate за 7 месяцев. Но я не хочу превращать это в магическую легенду. Работала не «секретная методика», а скучная связка: общий язык, источник правды по сделкам, нормальный handoff и регулярный разбор того, где деньги застревают.

Эта статья - подробный маршрут построения RevOps с нуля для B2B-команды 5-30 человек. Без академических фреймворков, без чужих кейсов. Только то, что я сам делал и видел работающим.

Зачем вам RevOps

Если у вас один из этих симптомов - вам нужен RevOps:

• Маркетинг отчитывается одной воронкой, продажи - другой, цифры не сходятся
• На квартальном обзоре каждая команда говорит "у нас всё хорошо", но общая выручка не растёт
• Лиды теряются между этапами, никто не знает где
• Прогноз выручки промахивается на 20-40% квартал к кварталу
• Customer success узнаёт о проблеме клиента через жалобу, не через сигнал
• На стыке "лид купил" и "клиент работает" - вакуум, никто не отвечает

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

Контекст СберЗдоровье: что я там делал

Когда меня позвали в СберЗдоровье на роль strategy advisor, это был большой digital health контур: сильный продукт, сложная инфраструктура, несколько коммерческих функций и много стыков между ними. Подробную структуру команды я здесь не раскрываю - она не нужна для вывода.

Всё работало по отдельности. Маркетинг отчитывался по лидам. Продажи - по выручке. CS - по NPS. Никто не отвечал за полный цикл "от первого касания до retention".

Цифры тоже не сходились. Маркетинг показывал 2400 лидов за квартал, продажи в CRM видели 1800. Куда делись 600? Никто не знал. Кто-то говорил "лиды нерелевантные, не дошли до квалификации". Кто-то - "продажи не успели обработать". Кто-то - "лиды задвоились в системе". Все три причины были правдой одновременно. Никто этого не считал.

Публично безопасный результат я оставляю: 2,57x годового плана по usage rate за 7 месяцев. Но внутреннюю механику не надо превращать в список красивых цифр. Смысл был проще: перестали теряться возможности, прогноз стал управляемее, а стык между продажей и дальнейшей работой с клиентом перестал быть чёрной дырой.

Дальше - как именно.

Шаг 1. Один владелец, не комитет

Главная ошибка в построении RevOps - сделать его комитетом из CMO, CRO и Head of CS. Комитет принимает решения за месяц, RevOps требует решений за день.

RevOps работает, когда есть один человек с правом принимать операционные решения. Это может быть:

• VP Revenue Operations (если компания крупная)
• RevOps Manager (если 30-100 человек)
• Sales Operations + дополнительная нагрузка (если меньше 30)
• Внешний консультант на 3-6 месяцев построения, потом передача внутрь

Этот человек подчиняется или CEO, или COO. Не CMO и не CRO - иначе он будет смотреть на их KPI. Он должен смотреть на сквозные метрики выручки.

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

Шаг 2. Единая воронка - один источник правды

Первое физическое действие RevOps - построить единую воронку, в которой каждый лид прозрачно проходит от первого касания до выручки и retention.

Этапы примерно такие (можно адаптировать):

1. Anonymous touch - первое взаимодействие (визит на сайт, подписка, скачивание материала)
2. Marketing Qualified Lead (MQL) - лид, прошедший квалификацию маркетингом по чек-листу (кто, какая компания, проявил интерес к продукту)
3. Sales Qualified Lead (SQL) - лид, принятый продажами как готовый к разговору
4. Discovery / Demo - проведена первая встреча
5. Proposal / Pilot - выдано предложение или начат пилот
6. Negotiation - идёт обсуждение условий
7. Closed-Won - сделка закрыта, контракт подписан
8. Onboarded - клиент начал использовать продукт (передача в CS)
9. Activated - клиент достиг первой ценности (метрика customer success)
10. Renewed / Expanded - клиент продлил контракт или расширил подписку

Каждый этап имеет владельца (маркетинг / продажи / CS), чёткий критерий перехода и SLA по времени. Если лид застрял на этапе дольше SLA - это не "лид завис", это сигнал, который RevOps должен поднять.

Самая тяжёлая часть обычно не техническая. Воронку можно нарисовать за вечер. Гораздо сложнее договориться, что считать MQL, что считать SQL, где заканчивается маркетинг и где начинается ответственность продаж. Вот здесь RevOps впервые перестаёт быть таблицей и становится управленческой функцией.

Шаг 3. Data stack, на котором всё держится

RevOps без данных - просто координационная роль. С данными - реальный рычаг.

Минимальный стек для команды 10-30 человек:

• CRM - центр всего. amoCRM, Bitrix24, RetailCRM или Pipedrive в зависимости от специфики. CRM должна быть единственным источником информации о сделках, без параллельных таблиц.
• Marketing automation - что-то вроде SendPulse, Mindbox или Carrot Quest. Здесь живут касания до момента передачи в CRM.
• Аналитика - Яндекс Метрика + дашборд (Power BI, Yandex DataLens или Google Data Studio). Здесь сходятся данные из CRM и marketing automation.
• Call analytics (если в продажах много звонков) - Comagic, Calltouch или CoMagic для прослушки и квалификации.
• Customer success tooling - может быть отдельная таблица в начале, потом отдельный инструмент типа Customer.io или внутренней разработки.

Правило простое: один источник правды по сделкам - CRM. Если команда ведёт параллельные таблицы, это не повод запрещать таблицы приказом. Это повод спросить, почему CRM не отвечает на реальные вопросы команды. Обычно там и лежит первый ремонт.

Шаг 4. Метрики, которые меняют поведение

Не все метрики одинаково полезны. Часть метрик - индикаторы здоровья. Часть - триггеры действий. RevOps должен различать.

Индикаторы здоровья (смотрим раз в неделю):

• Pipeline coverage - сколько раз пайплайн покрывает квартальный план (здоровая цифра 3-4x)
• Win rate по стадии - на каком этапе проседаем
• Avg deal size по cohort месяца
• Sales velocity (avg deal size × win rate / avg sales cycle)
• NPS / CSAT по cohort месяца внедрения
• Churn rate месячный и квартальный
• Net Revenue Retention (NRR)

Триггеры действий (смотрим ежедневно или с алертом):

• Лиды старше SLA на этапе - кому переназначить
• Сделки без активности более 14 дней - что делать
• Клиенты с резким падением активности - звонок CS
• Контракты, истекающие через 60-90 дней - старт renewal-flow

Когда триггеры появляются, у команды меняется поведение. Раньше «сделка зависла» всплывала на отчёте, когда уже поздно. Теперь система поднимает руку раньше: нет касания, нет next step, клиент выпал из активности, продление близко. Это маленькая разница в интерфейсе и огромная разница в управлении.

Шаг 5. Ритуалы, которые делают RevOps живым

RevOps - не разовое внедрение. Это набор регулярных ритуалов, которые поддерживают живой темп. Без них через два месяца всё разваливается.

Минимальный набор ритуалов:

• Еженедельный pipeline review (45 минут). Маркетинг + продажи + RevOps. Что зашло, что выпало, что застряло, что нужно подключить.
• Двухнедельный handoff sync (30 минут). Продажи + CS. Что передаём, какие риски у новых клиентов, что обсуждали на закрытии сделки.
• Месячный business review (90 минут). Все три команды + руководство. Прогноз vs факт, тренды, корректировки.
• Квартальный strategy review (полдня). Что меняем в воронке, в стеке, в KPI на следующий квартал.

Эти встречи - не разговор "по плану". Это рабочие сессии с живыми решениями. Если из встречи никто не уходит с конкретной задачей и сроком - встреча была лишней.

Шаг 6. Самые опасные точки - handoff'ы

В RevOps есть три места, где теряется больше всего ценности:

Handoff 1. Маркетинг → Продажи. Лид передан, не подхвачен в течение 24 часов. Конверсия падает на 60-80%. Решение: SLA на скорость подхвата + автоалерт.

Handoff 2. Продажи → CS. Сделка закрыта, контракт подписан, CS получает уведомление и идёт читать переписку с нуля. Клиент в этот момент остывает. Решение: handoff document на полстраницы (что обещали, какие приоритеты у клиента, кто champion, какие риски), плюс kickoff-встреча в течение 5 рабочих дней.

Handoff 3. CS → renewal. Контракт подходит к концу, разговор о продлении начинается за 30 дней до даты. Клиент уже изучил альтернативы. Решение: renewal-conversation за 90 дней до окончания, с обсуждением expansion, не только продления.

Самый болезненный стык почти всегда sales → CS. Продавец знает контекст, страхи клиента, обещания на переговорах, внутреннюю политику сделки. Если это не передать до kickoff, CS начинает с нуля, а клиент через две недели чувствует, что его уже забыли. Полстраницы handoff-документа иногда стоят дороже нового дашборда.

Шаг 7. Прогноз выручки - первый продукт RevOps

Если RevOps не делает прогноз выручки - это не RevOps, а аналитика. Прогноз - главный продукт.

Простой работающий метод прогноза для команды 10-30 человек:

1. Берёте все сделки в пайплайне
2. Каждой сделке присваиваете вероятность по её этапу (Discovery 10%, Proposal 30%, Negotiation 60%, Verbal commit 85%)
3. Умножаете чек × вероятность = weighted pipeline
4. Сравниваете weighted pipeline с целью на квартал
5. Корректируете вероятности по продавцу (один точно прогнозирует, другой завышает на 30%)

Этот прогноз нужно проверять на исторических данных и корректировать раз в квартал. В первом квартале он будет промахиваться на 20-30%. К четвёртому - на 5-8%.

Хороший forecast нужен не ради красивого отчёта. Он нужен, чтобы компания могла планировать найм, маркетинг, закупки и продуктовые обещания без вечного «может 50, может 120». В первый квартал он почти всегда ошибается. Если RevOps живой, к четвёртому кварталу ошибка становится управляемой.

Типичные ошибки при построении RevOps

Ошибка 1. Начинать с инструментов. "Купим Salesforce и будет RevOps". Не будет. Сначала процессы, потом стек. Salesforce без процессов - дорогая записная книжка.

Ошибка 2. Стартовать с большого ребрендинга. "У нас теперь RevOps Department, мы переименовываем все роли". Команда устаёт от ритуала, сам процесс не двигается. Начинайте с одного человека и одной воронки.

Ошибка 3. Делать RevOps только под продажи. Если маркетинг и CS не вовлечены - это Sales Ops, не RevOps. Эффект минимальный.

Ошибка 4. Гнаться за NRR с первого месяца. NRR - метрика зрелого бизнеса. На старте смотрите на churn в первые 90 дней и activation rate. NRR будет следствием.

Ошибка 5. Бесконечно настраивать дашборды. Дашборд - инструмент. Если вы тратите неделю на красоту дашборда - вы тратите неделю не на бизнес. Стандартный дашборд из 8-12 цифр + два графика - этого достаточно для большинства задач.

Что я понял за 6 проектов RevOps

За шесть лет я строил RevOps в шести разных компаниях. Разные размеры, разные индустрии, разная зрелость. Несколько вещей, которые работают везде:

1. RevOps - это инструмент CEO, не CMO. Если CEO не понимает, что такое pipeline coverage и зачем нужен sales velocity - RevOps будет ритуалом, а не рычагом. Первое внедрение - это образование руководителя.

2. Внутренняя война маркетинга и продаж - топливо для RevOps. Если её нет - часто RevOps не нужен. Если она есть - RevOps её разрешает не путём дипломатии, а через общие метрики.

3. RevOps окупается за 6-12 месяцев. Не быстрее. Если кто-то обещает "результат через месяц" - они продают аналитический дашборд, а не RevOps.

4. Первый человек на роль - сильнее модели. Хороший Sales Ops, выросший в RevOps - лучше дорогого консультанта без знания компании. Внешний нужен только для запуска и передачи.

5. Главный риск - культурный. Если в компании "у каждого своя правда" нормализовано - RevOps не приживётся. Это другая операционная парадигма, и она требует решения "теперь у нас одна правда, и она в CRM".