Три столпа RevOps: почему семь доменов ломаются и как собрать работающий контур выручки

Когда в России начали переводить словечко RevOps, вместе с ним сразу приехал любимый западный зоопарк из семи-десяти «доменов». Data, systems, processes, enablement, strategy, insights, planning. Красивый кружок из семи лепестков, где каждый лепесток подписан мелким шрифтом. На слайде смотрится как самолёт. В жизни - как набор отделов, которые не знают друг друга в лицо.

Я видел этот кружок в презентациях крупных компаний: и в BrandMaker ещё в enterprise-мире, и у партнёров по СберЗдоровью, и на стратсессиях в Ростелекоме. Через раз после этого слайда кто-нибудь из коммерческого директора тихо спрашивал: «слушайте, а кто из этих семи за то, чтобы у нас перестали терять 20% сделок между продавцом и внедрением?» Молчание.

Поэтому я давно перестал объяснять RevOps через семь доменов. Их три. Sales Enablement, CX/Retention, финансовая аналитика выручки. Всё остальное - производные.

Почему семь доменов - это не архитектура, а список дел

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

Ещё одна типовая ошибка: называть RevOps набором инструментов. Купили CRM, BI, call-analytics, посадили двух ops-специалистов - и считают, что функция появилась. Это не RevOps. Это склад.

Мой опыт говорит проще. Когда я разбираю коммерческую архитектуру - в фарме, в телекоме, в digital health - почти любую проблему можно положить в один из трёх столпов. И как только кладёшь - видно, что именно сломано, и как это чинить без запуска нового департамента.

Столп 1. Sales Enablement: вход, скорость, внутренняя продажа

Sales Enablement - это не тренинг для менеджеров. Это система, благодаря которой продавцу есть на что опереться в каждом типичном разговоре.

Если совсем по-простому, Enablement отвечает на вопрос: что именно держит сделку между первым касанием и решением комитета. Материалы, плейбуки, карты возражений, battle cards, тренинги, логика хендоффа между пресейлом и продавцом. В Pharmznanie мы эту часть собирали руками около года: от одностраничного плейбука по разговору с HR медицинского центра до полноценной системы пресейл-артефактов для сложных b2b-учёбных программ.

Что сюда входит по-честному:

• Плейбуки под сегмент. Не один на всех, а отдельно под enterprise, отдельно под средний бизнес, отдельно под soho-клиента. В одной компании - три разговора.
• Карты возражений. Не «у нас дорого», а реальные фразы, с которыми уходят сделки. Собираются из расшифровок звонков, не из головы директора по продажам.
• Материалы под этапы. Разные документы под discovery, пилот, CFO-защиту, техническое внедрение.
• Пресейл-рамка. Кто и когда подключается, какие артефакты передаются, что за чек-лист передачи.
• Онбординг продавцов. Не «прочитай wiki за две недели», а ритм - что должен уметь на 14, 30, 60, 90 дне.

Если Enablement нет - продажа держится на героях. Я видел это в B2B-командах: двое сильных менеджеров тянут большую часть результата, остальные повторяют внешнюю форму, но не механику. Убрали героев - посыпались цифры. Enablement как раз и нужен, чтобы не зависеть от героев.

Столп 2. CX и Retention: куда уходят деньги после подписи

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

Salesforce State of Sales 2024 даёт красноречивую цифру: у компаний, которые считают retention частью RevOps-контура, средний NRR на 18% выше, чем у тех, у кого CS живёт в параллельной комнате. 18% - это не косметика, это разница между «стагнация» и «двузначный рост без нового маркетингового бюджета».

Что живёт в этом столпе:

• Onboarding клиента. Не «подпиши договор и удачи», а ритмичный ввод в продукт с зафиксированными критериями успеха. В СберЗдоровье мы с этого начинали любую новую b2b-интеграцию: без onboarding-чек-листа история заканчивалась за три месяца.
• Health score. Простая модель, которая говорит «этот клиент здоров», «этот на грани», «этот уже уходит». Не BI-панель на 40 метрик, а одна шкала с цветами.
• Expansion-механика. Как и когда продавать больше текущему клиенту. Upsell не в лоб, а на основании сигнала - использование, новая задача, смена ЛПР.
• Сигнал обратно в коммерцию. Что из опыта использования возвращается к маркетингу и продажам как новое сообщение, новый кейс, новое возражение.

Столп 3. Финансовая аналитика выручки: где деньги на самом деле

Это тот столп, который чаще всего ломается тише других. Никто не жалуется - потому что все считают, что «мы же смотрим цифры». Смотрят. Только не те.

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

Это та же история, о которой я подробно писал в тексте про unit-экономику для b2b-saas: пока нет собранной цифры по сегменту и по когорте, у компании нет навигации. Только интуиция.

Как три столпа встречаются в одной «комнате выручки»

Все три не живут параллельно. Они встречаются в трёх точках.

1. Передача сделки в внедрение. Enablement собрал, CX подхватил, финансовая аналитика фиксирует метрики первого квартала использования. Обычно тут первая протечка.
2. Срок до первой ценности. Продавец обещал, команда внедрения реализует, аналитика показывает, сошлось или нет. Тут выдаётся первая цифра реального качества продажи.
3. Решение о renewal и expansion. CX говорит «клиент здоров», Enablement даёт материал для экспансии, финансовая аналитика показывает payback - и только после этого понятно, в какую сделку стоит инвестировать время CS-менеджера.

Если одной из трёх функций нет - встреча не происходит. Выручка продолжается, но управлять ей нельзя. Можно только удивляться - почему в этом квартале вышли в план, а в следующем нет.

Что происходит, когда одного столпа нет

Три типичные картины. В каждой узнаёшь реальные компании.

• Нет Enablement. План держится на 1–2 героях-продавцах. Рост линейный, через найм. Масштаб упирается в то, что новых людей некому и не на чём учить. Частый случай в российских b2b-saas на стадии 100–500 млн выручки.
• Нет CX/Retention. Воронка наливная, churn 25–35% в год. Маркетинг компенсирует дыру новым бюджетом. До первой коррекции рынка живут хорошо, после - садятся на год в реанимацию. Часто встречается в digital health и edtech.
• Нет финансовой аналитики. Компания «в целом растёт», но при ближайшем рассмотрении растёт плохой сегмент, а хороший уходит. CFO пишет один отчёт, CRO другой, CEO читает третий. Решения принимаются на ощущении. Это типично для среднего b2b в России 2024–2026.

Границы применимости

Не любой компании нужны все три столпа сразу. Если выручка меньше 150–200 млн в год и команда коммерции до 10 человек - хватит одного ответственного за связку Enablement + базовая аналитика. CX в этой фазе чаще всего делает сам основатель или первый CS.

Если компания на 500 млн+, а длинный цикл сделки, несколько сегментов и сложная команда внедрения - все три столпа нужны. Иначе начинается тот самый зоопарк из семи доменов, которым никто не управляет.

Что с этим делать

Не заводить RevOps как департамент. Завести три столпа как роли и регулярные встречи. У кого-то в компании уже есть Enablement (обычно это head of sales ops или маркетинг-директор). У кого-то есть CX (обычно кто-то из customer success). У кого-то есть финансовая аналитика (обычно это финдир).

Нужно просто собрать их в одну комнату - физическую или виртуальную - и договориться, что раз в две недели они сверяют три показателя: sales velocity, NRR по сегментам, CAC payback. Всё. Этого достаточно, чтобы коммерческая архитектура начала собираться.

Не ищите седьмой домен. Ищите точку встречи трёх.

Порядок, в котором три столпа внедряются в реальной компании

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

Мой рабочий порядок выглядит так:

1. Шаг 0. Картировать что есть. Одна неделя. На одной странице отметить: кто сейчас де-факто отвечает за Enablement, кто за CX/Retention, кто за финансовую аналитику. Не по должности, а по реальной работе. Обычно выясняется, что у двух столпов нет хозяина, а третий размазан по трём людям.
2. Шаг 1. Починить самый сломанный. Один квартал. В 70% компаний это будет CX - потому что его никто целенаправленно не строил. В 20% - финансовая аналитика. В 10% - Enablement.
3. Шаг 2. Собрать регулярную встречу трёх. Второй квартал. 30 минут раз в две недели. Три ответственных, одна повестка: sales velocity, NRR по сегментам, CAC payback.
4. Шаг 3. Закрыть недостающий столп. Третий квартал. Нанять или перераспределить.
5. Шаг 4. Стандартизовать артефакты. Четвёртый квартал. Плейбуки, карты возражений, health score, определения метрик - всё в одно место.

Через год у вас зрелый контур. Не идеальный - зрелый. Разница большая.

Типовые ошибки внедрения

В российских компаниях я чаще всего вижу одни и те же четыре грабли.

• Назначить директора по RevOps без мандата. Человек приходит, смотрит на три столпа, начинает их «собирать», но у него нет права двигать Enablement в коммерческом отделе и CX в клиентском. Через полгода уходит.
• Начать с инструмента. Купили Gong-аналог или новую BI-платформу - и думают, что это RevOps. Инструмент ложится на сломанную архитектуру и только ускоряет беспорядок.
• Поставить финансовую аналитику первой. Логически красиво, практически - мертво. Пока нет дисциплины Enablement и CX, финансовая аналитика показывает пустые цифры, на основании которых нельзя принять ни одного решения.
• Не договориться о языке. Commit у продавца и commit у CFO - разные вещи. NRR в CS и NRR в финотчёте - разные вещи. Пока язык не согласован, встречи трёх превращаются в спор о терминах.

Кейс из фармы: как три столпа собрались за 9 месяцев

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

Что было до:

• Enablement: один общий wiki, половина документов устарела.
• CX: формально есть менеджер по клиентам, реально - отвечает на входящие вопросы, но не имеет рамки health score.
• Финансовая аналитика: план/факт раз в месяц, unit-экономики по сегментам нет.

Что сделали:

1. Первый квартал - запустили health score для топ-50 клиентов. Три цвета, один критерий на цвет. NRR начали замерять помесячно.
2. Второй квартал - перепаковали wiki в три плейбука под сегменты. Переписали карту возражений по данным последних 40 проигранных сделок.
3. Третий квартал - запустили unit-экономику по сегментам. Оказалось, что один из трёх сегментов работает в ноль.

Результат был не в том, что появилась новая модная должность. Команда стала быстрее видеть просадки, раньше ловить риски продления и трезвее считать экономику по сегментам. Для меня это и есть настоящий RevOps: не оргчарт, а управляемость выручки.

Как оценить, нужен ли вам RevOps прямо сейчас

Простой тест из пяти вопросов. Ответьте честно:

• У вас больше 100 сделок в год?
• Длина цикла больше 45 дней?
• В воронке больше трёх стадий, которые кто-то реально отслеживает?
• После подписи клиентом с ним работает хотя бы один человек?
• У вас больше одного продукта или одного сегмента?

Если минимум на три «да» - RevOps-подход вам нужен. Если на все пять - уже нужен был вчера. Если на один-два - не тратьте время, делайте продажи руками, пока не вырастете.

Что посмотреть рядом по теме

Если тема откликается, рядом в блоге есть соседние тексты. Базовый разбор RevOps без магии даёт общую карту. Метафора одной комнаты для выручки объясняет, почему три столпа должны встречаться физически, а не по отдельным планеркам. RevOps-аудит - это конкретный формат, в котором такие столпы картируются за неделю. Customer Success в b2b - развёрнутый разбор второго столпа. Sales Enablement: полный гайд - расширенная версия первого. Модель зрелости RevOps в России показывает, на какой стадии вы сейчас.

Частые вопросы