Юнит-экономика B2B SaaS с длинным циклом: как считать CAC, когда сделка тянется месяцами

Все цифры иллюстративные, для понимания логики, не реальные финансовые данные.

Когда я отвечал за бизнес-юнит МСБ в Kaiten, мне нужно было посчитать юнит-экономику B2B SaaS с длинным циклом сделки. Поначалу задача казалась простой: поделить LTV на CAC и сравнить с порогом. Для B2C я делал это много раз, там сделка закрывается быстрее месяца.

Взял свои старые таблицы, попробовал адаптировать под новый процесс. Не сработало. Цифры расходились в разы в зависимости от способа подсчёта, и верить нельзя было ни одной. Причина оказалась одна: готовые формулы привязывают расходы к месяцу привлечения, а у меня сейлзы вели сделку месяцами.

Тогда я отложил готовые модели и разобрал свой процесс на составляющие: по каким этапам идёт сделка и какие расходы возникают на каждом из них. Собрал юнит-экономику заново, отталкиваясь от базовых принципов. Главное, что увидел: единица учёта не клиент в месяце привлечения, а сделка, которая идёт по этапам и копит стоимость, пока висит в пайплайне. На эту основу легли привычные MRR, LTV, payback, и модель дала одно число, в которое не стыдно поверить.

Эта статья — то, к чему я пришёл, в форме, которую сам хотел бы прочитать, когда впервые сел за эту задачу. Дальше расскажу про три принципа и дам шаблон в Google Sheets, который превращает «у меня не сходится» в работающую модель.

Вопросы, на которые я искал ответ

Три простых вопроса, на которые B2C-формулы не дают честного ответа в длинном цикле:

1. Сколько на самом деле стоит сделка с учётом маркетинга, продаж, пресейла, юристов и CS (Customer Success, команда по работе с клиентами), то есть всех, кто прикасается к ней на разных этапах продажи?

2. Как длина цикла влияет на экономику сделки? Если сейлз работает с ней четыре месяца вместо одного, насколько дороже она обходится?

3. Какой CAC корректнее показывать: на аккаунт, на лицензию, на «успешно закрытую сделку» или на «все сделки в когорте, включая неуспешные»?

Кажется, что это три разных вопроса. На деле один, просто заданный с трёх сторон. Дальше отвечу на каждый, а в финале соберу всё вместе.

Почему B2C-формулы ломаются на длинном цикле

Посмотрим, что предполагает привычная формула в гуляющих по интернетам моделях юнит-экономики.

Стандартная B2C-формула CAC в общем виде:

CAC = (расходы на маркетинг и продажи за период) ÷ (количество новых клиентов за тот же период)

CAC (Customer Acquisition Cost) показывает, сколько бизнес тратит на маркетинг и продажи, чтобы привлечь одного клиента.

В ней зашиты три неявных допущения:

• Допущение первое: клиент привлекается в том же месяце, в котором бизнес понёс расходы. В B2C обычно так. Человек увидел рекламу, кликнул, оплатил подписку — всё за один день. У меня даже за месяц закрывалось мало сделок.

• Допущение второе: труд сейлза не привязан к конкретной сделке. В B2C сейлзов часто нет, либо они работают конвейером: входящий звонок → закрытие за пару дней.

• Допущение третье: одна когорта затрат соответствует одной когорте клиентов. Если я в марте потратил миллион на маркетинг и в марте у меня закрылось 200 клиентов, эти 200 клиентов «оплачены» мартовским миллионом.

В многоэтапных B2B-продажах все три допущения сломаны.

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

Труд сейлза «прибит» к конкретной сделке. Посчитайте ФОТ (фонд оплаты труда) команды продаж за март и поделите на «закрытые в марте сделки». Получите цифру, которая не отражает реальность. Часть этого ФОТ ушла на сделки, которые закроются через два-три месяца. А мартовские закрытия — результат работы, которую сейлзы делали в январе и феврале.

Когорта затрат не равна когорте клиентов. Если делить расходы марта на клиентов марта, в числителе окажутся расходы на все активные сделки месяца (200 из них так и не закроются), а в знаменателе только успешно закрытые. Цифра получается в лучшем случае случайной, в худшем обманчиво низкой.

Из-за этих трёх некорректных допущений одна и та же команда с одной и той же экономикой даст три разных CAC, смотря как поделить. И все три будут неверными.

Принцип 1. Считаем сделку, а не клиента

Привычная дробь даёт три разных CAC, потому что делит не то. Чинить надо не формулу, а единицу учёта.

Единица учёта в B2B с длинным циклом — не клиент, привлечённый в месяце, а сделка, которая идёт по этапам.

Идея не новая. В управленческом учёте есть концепция Activity-Based Costing (Каплан и Купер, 1988): затраты разносят не пропорционально объёму выпуска, а пропорционально реальному потреблению ресурсов конкретными активностями. В практике B2B SaaS похожую логику называют «cohort-based CAC». Названий много, идея одна: считайте сделку, а не клиента, и накапливайте расходы, а не аллоцируйте их в моменте.

Из этой смены единицы учёта следуют два рабочих принципа: как собирать сделки в когорту и как разносить по ним затраты.

Принцип 2. Когорта формируется по появлению сделки, а не по закрытию

Первый принцип отвечает на вопрос, как группировать сделки. Когорта формируется по месяцу появления сделки в пайплайне, а не по месяцу её закрытия. Мартовская когорта — это все сделки, которые в марте попали в работу сейлзов, включая те, что успешно закроются в июле, и те, что провалятся в августе.

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

Каждый месяц в пайплайн заходит новая когорта — группа сделок с общим временным признаком, все сделки этого месяца. Дальше когорту разносят по таблице. В строках идут состояния сделок, в столбцах месяцы её жизни.

В марте в пайплайн зашло 200 сделок (это мартовская когорта). Что с ней происходит дальше:

К июлю из 200 мартовских сделок успешно закрылось 35, неуспешно 161, осталось активных 4. Конверсия когорты 17,5%, и она будет меняться в августе-сентябре, пока не закроются последние сделки.

Этот блок отвечает на два вопроса:

• Сколько сделок было в работе в каждом месяце? Это знаменатель для аллокации затрат на следующем шаге.

• Какая итоговая конверсия каждой когорты? Так можно сравнивать когорты между собой и видеть, улучшается ли работа с воронкой во времени.

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

В этой же таблице сразу видно главный сигнал здоровья воронки — скорость отвала. Если из 200 мартовских сделок к маю осталось 90, это нормально для длинного цикла. Осталось 30 — проблема в привлечении и квалификации, и платить за этих лидов вы будете дальше по цепочке. Осталось 180 — проблема в продажах: сейлзы не отпускают мёртвые сделки, и расходы по ним будут копиться месяцами. Об этом ещё пойдёт речь.

Принцип 3. Затраты разносим на все активные сделки и накапливаем

У этого принципа две части.

Стоимость сделки накапливается во времени. Каждый месяц, что сделка «лежит» в пайплайне, она получает свою долю ФОТ сейлзов, пресейла, юристов и всех, кто её «касается». К моменту закрытия стоимость сделки — это сумма всех статей расходов по всем месяцам, в которых она была активной.

Аллокация идёт на активную сделку, а не на «закрытую». В каждом месяце ФОТ команды делится не на количество закрытий, а на количество активных сделок в работе — тех, что ещё не закрыты успешно, не закрыты неуспешно и не приостановлены. Именно столько внимания команда фактически потратила.

Покажу на цифрах. Пусть ФОТ команды продаж 500 000 ₽ в месяц. В марте в пайплайне 200 активных сделок, стоимость работы с одной = 500 000 ÷ 200 = 2 500 ₽. В апреле количество активных сдвинется: старые когорты частично отвалятся, добавятся новые. Аллокация пересчитывается каждый месяц. Для упрощения беру «чистый» ФОТ без премий; если нужно с премиями, добавьте усреднённое прогнозное значение.

Накопленная стоимость работы команды продаж с мартовской когортой собирается так. В каждом месяце берём «стоимость одной сделки в этом месяце» × «сколько мартовских ещё активны». Сумма по всем месяцам жизни когорты = полные затраты сейлзов на эту когорту.

К июлю на мартовскую когорту суммарно ушло ~1 500 000 ₽. Это затраты на работу со всеми 200 сделками: и теми, что закрылись, и теми, что отвалились, и теми, что ещё висят. Делим на количество успешно закрытых, выходит ~43 000 ₽ на одну успешную сделку.

Цифра похожа на правду. Она учитывает работу и с успешными сделками, и с отвалившимися по дороге, а их деньги тоже надо где-то посчитать.

Можно возразить: разные сделки требуют разного внимания. Демо в апреле два часа, согласование договора в июне десять часов, усреднять всё подряд неправильно.

Отвечу контраргументом в трёх частях:

• Среднее значение лучше никакого. Считать примерно — не то же самое, что считать с ошибкой. Среднее по 200 сделкам не идеально, зато это число, на которое можно опереться на разборе с командой. Цифры нужны не сами по себе, а ради принятия решений, и под каждое решение нужна своя точность: поднимать её стоит только тогда, когда этого требует решение. Альтернатива одна: опираться в решениях на ощущения.

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

• Если разброс действительно большой, добавляйте коэффициенты по этапам: «сделка на стадии демо = 1.5, сделка на стадии договора = 2.0, сделка на стадии переговоров = 1.0». Это та же модель, только с весами вместо равной аллокации.

В шаблоне это лист «Затраты на все сделки ОП» (ОП — отдел продаж). ФОТ задаётся вручную, активные сделки тянутся из листа когорт, накопление считает формула.

С сейлзами всё понятно: они работают со сделкой непрерывно, их ФОТ аллоцируется на активные сделки каждого месяца. С другими ролями сложнее, потому что они подключаются не ко всем сделкам и не на все месяцы.

Я разделил их на три группы по логике учёта.

Группа 1. Пресейл-инженер. Подключается на конкретные сделки на конкретных этапах: обычно демо или подготовка ответа на RFP (request for proposal, по сути заявка от клиента), если он есть. Учитывать можно двумя способами.

• Если пресейл подключается часто, предсказуемо и полностью относится к P&L (profit & loss, отчёт о прибылях и убытках) вашего бизнес-юнита: ФОТ пресейла ÷ количество демо в месяце × количество демо на сделку. Грубее, но проще.

• Если редко, точечно или вы делите его с другими юнитами: фиксируете факт участия в CRM и считаете «часы на сделку × ставка часа». Точнее, но требует дисциплины ввода.

В обоих случаях расход прикрепляется к сделке и попадает в её накопленную стоимость в месяце участия.

Группа 2. Юристы и согласования. Подключаются на стадии договора. Логика: ФОТ команды юристов (или её части) ÷ количество согласований в месяце × количество согласований на сделку. По моему опыту в МСБ этот блок недооценивают. Когда я возглавил бизнес-вертикаль, многие сделки с низким чеком требовали уникальных условий договора, и эта строка стала одним из рычагов управления юнит-экономикой: она показала, какая часть сделок становится нерентабельной именно из-за юридической нагрузки. Похожая картина — включайте обязательно и учите продавцов использовать «право на отказ» в переговорах. Шаблон договора стандартный, согласований мало — этой строкой можно пренебречь.

Группа 3. Онбординг и Customer Success. Однозначного ответа нет. В литературе вы найдёте оба подхода: «онбординг включаем в CAC» и «онбординг идёт в COGS (cost of goods sold, себестоимость)». Я склоняюсь к включению в CAC. Расход возникает в момент заключения сделки, без онбординга на сложных B2B SaaS-продуктах клиент не доходит до регулярного использования, а значит онбординг — часть стоимости привлечения. Если в B2B-сделке часть онбординга оплачена клиентом одноразовым платежом (setup fee, разовый платёж за подключение и настройку), это тоже логичнее держать внутри привлечения.

Но вопрос каждый решает на своё усмотрение, и я не настаиваю на своём варианте. В шаблоне эту строку легко убрать или перенести в COGS.

К этому же блоку прилегают другие расходы первого месяца обслуживания, которые в литературе часто объединяют под понятием «1st COGS»: настройка тестового окружения для пилота, лицензии на пилот, кастомные интеграции, обучение пользователей, инфраструктура под клиента. Часть из них уходит в CAC, часть в COGS. Принцип тот же: возникает в момент привлечения → CAC; возникает в процессе использования → COGS.

Важная оговорка про знаменатель сравнения. LTV правильно считать не от выручки, а от валовой прибыли: выручку клиента умножают на валовую маржу, долю, которая остаётся после COGS (хостинг, поддержка, регулярный CS). Считать LTV от выручки — частая ошибка, она завышает множитель. Не хочу здесь разбирать этот вопрос детально, про это давно хорошо написал у себя в статьях Олег Якубенков. В примерах ниже беру маржу 80%, это иллюстративная цифра, не реальные данные.

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

Полный CAC с учётом неуспешных сделок

Это центр всей модели. Полный CAC когорты собирается как сумма по строкам:

Это полные затраты на работу с мартовской когортой за всё время её жизни.

К июлю на мартовскую когорту суммарно потрачено ~3 000 000 ₽ (сейлзы ~1 500 000 + маркетинг 70 000 + квалификация ~130 000 + пресейл ~800 000 + юристы ~500 000 за все месяцы её жизни). Успешно закрылось 35 сделок.

Наивный CAC по B2C-шпаргалке считается так: маркетинговые расходы марта ÷ закрытия марта. Например, маркетинг 70 000 ₽ (200 лидов × 350 ₽), закрытия за март 6 сделок. CAC = ~11 700 ₽. Красиво. И неправда. В этой цифре нет работы сейлзов, нет пресейла, нет юристов, и привязана она к месяцу, в котором сделки ещё не закрывались.

Честный CAC на привлечённого клиента считается на полной когорте: все затраты когорты ÷ успешно закрытые сделки этой же когорты. В нашем примере: 3 000 000 ÷ 35 = ~86 000 ₽. Эта цифра уже включает «налог на неуспешные», потому что в числителе расход на работу со всеми 200 сделками, а в знаменателе только те, что заплатили. Именно этот CAC надо сравнивать с LTV.

Рядом в модели полезно держать ещё одну метрику — стоимость одной сделки в воронке. В англоязычной практике это cost per opportunity (CPO): полные затраты ÷ число сделок в воронке.

Стоимость сделки в воронке = Полные затраты на когорту ÷ Все сделки в когорте

В нашем примере: 3 000 000 ÷ 200 = 15 000 ₽ на одну сделку в воронке.

Это не классический CAC, а диагностический индикатор, и делить его на LTV нельзя. Он показывает, во что обходится одна заявка от маркетинга до решения сейлза. Если стоимость сделки в воронке растёт, а конверсия нет, значит удлинился цикл или подросли затраты на сопровождение, и это надо чинить.

Из этих же двух чисел считается доля потерь в CAC — какая часть затрат когорты ушла на неуспешные сделки. В нашем примере при конверсии 17,5% это ~82,5%. То есть из 86 000 ₽ полного CAC около 71 000 ₽ приходится на «стоимость сделок в воронке, которые не закрылись», и только ~15 000 ₽ на работу с тем, кто заплатил. Для длинного цикла высокая доля потерь нормальна, важен не уровень, а тренд. Если доля растёт от когорты к когорте, значит упала квалификация лидов, или эффективность продаж, или сменился сегмент. Когортная модель показывает это до того, как просядет выручка.

Теперь сравнение с LTV (lifetime value, суммарная валовая прибыль от клиента за всё время жизни: выручка × валовая маржа). Пусть средний MRR (monthly recurring revenue, ежемесячная повторяющаяся выручка) клиента МСБ 42 000 ₽ при средней длине контракта 10 месяцев и марже 80%. Тогда LTV = 42 000 × 0,8 × 10 = 336 000 ₽. В длинном цикле важно не завышать длину контракта в LTV: берите консервативную среднюю по факту удержания, иначе множитель раздувается.

• Наивный B2C-CAC: 336 000 / 11 700 = 28,7. В это соотношение нельзя верить, потому что наивный CAC искусственно занижен.

• Честный CAC на привлечённого: 336 000 / 86 000 = 3,9. Это реальный множитель, в здоровом коридоре 3–5. Считается, что юнит здоров, если это значение стабильно выше 3.

Разница между «28,7» и «3,9» — та самая цифра, которую раньше я не мог свести к одному числу для команды и совета директоров.

В шаблоне это лист «CAC с учетом неуспешных». Туда стянуты все слагаемые из предыдущих листов, и финальная таблица показывает CAC по каждой когорте в трёх разрезах: на аккаунт, на лицензию, с учётом неуспешных.

Как принимать решения

Сама по себе модель бесполезна. Она нужна, чтобы отвечать на вопросы не за неделю анализа сделок в CRM, а за минуты.

Поэтому поверх когортных расчётов в шаблоне есть дашборд, который сводит ключевые метрики в одну таблицу со светофором.

Главные строки дашборда:

Пороги двух типов. LTV:CAC, payback и валовая маржа — отраслевые ориентиры (Benchmarkit 2025: медиана LTV:CAC ~3,6, здоровый коридор 3–5; payback < 12 мес для SMB). Payback — это срок окупаемости CAC в месяцах, CAC ÷ (MRR × валовая маржа); SMB (Small & Medium Business) — аналог российского МСБ. Доля потерь и стоимость зависшей сделки — пороги, которые я выставил под свой сегмент МСБ, калибруйте под себя.

Каждая строка считается из когортных расчётов и сравнивается с пороговым значением. Зелёный — норма, жёлтый — внимание, красный — проблема.

Главное правило, которое я для себя вывел: модель отвечает не на вопрос «красивые ли цифры», а на вопрос «можно ли нанять следующего сейлза».

Это другой класс вопроса. «Красивые» — про отчётность. «Можно ли нанять» — про решение.

Механика простая. Новый сейлз — это не только плюс руки, но и плюс ФОТ, который размажется на все активные сделки и поднимет аллокацию на каждую. Поэтому смотрю три цифры дашборда: CAC с учётом неуспешных (под порогом ли LTV:CAC > 3), его тренд по когортам (стабилен или растёт) и payback (доживём ли до окупаемости найма на текущей оборотке). CAC стабилен и под порогом, payback укладывается в 12 месяцев — нанимаю, экономика выдержит. CAC растёт три когорты подряд — сначала чиню воронку: новый сейлз в дырявой воронке просто увеличит стоимость сделок в воронке, а не выручку.

Точно так же модель отвечает на смежные вопросы. Открывать ли новый канал маркетинга — пересчитываем CAC при новой стоимости лида. Закрывать ли убыточный сегмент — да, если CAC сегмента стабильно выше LTV. Поднимать ли цены — да, если payback больше 18 месяцев. Каждое решение упирается в одну из метрик.

Решение по отдельной сделке

Тот же подход работает не только на когорте, но и на отдельной сделке, особенно на зависшей. Зависшая сделка выглядит как потенциальный доход, а ведёт себя как расход: занимает слот в пайплайне сейлза, всплывает на еженедельных синках и ревью, сидит в прогнозе у РОПа (руководителя отдела продаж), занимает место в презентации CEO. Всё это расход внимания, которого в CRM не видно, поэтому никто его не считает. Когортная модель делает его видимым и даёт способ решить: добивать сделку или закрывать.

Логика та же, что и для юнита целиком, только на одной сделке. Оцениваете, во что сделка обойдётся к закрытию: накопленное плюс прогноз оставшихся месяцев. Сравниваете с тем, что она принесёт, то есть с валовой прибылью контракта. Если отношение проваливается под ваш порог (бенчмарк LTV:CAC > 3 или принятый в вашей компании), дальше работать смысла нет.

Пример. Сделка к седьмому месяцу накопила ~100 тыс ₽, до закрытия прогнозируете ещё ~30. Итого ~130 тыс на сделку, которая при марже 80% принесёт ~336 тыс валовой прибыли (те же цифры, что в примере выше). Отношение 2,6, ниже порога 3. Сделка перестала окупаться: даже если закроется, заработаете на ней меньше, чем держит здоровый юнит. Естественно, каждая сделка уникальна, и закрывать её на основании одной цифры неправильно. Важен ещё и план работы по сделке, а не просто «мамой клянусь, после пилота купят», но это тема другой статьи.

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

Главный рычаг для МСБ — Sales Cycle Length

Sales Cycle Length — стандартная метрика B2B SaaS, среднее время от появления лида в пайплайне до закрытия сделки. По данным Ebsta «B2B Sales Benchmark Report» (анализ более 3 млн сделок), средний B2B-цикл сейчас около 6,5 месяцев, вырос с 4,9 в 2019 году. Важная оговорка: это средневзвешенное по всем сегментам, включая Enterprise. Для SMB-сегмента с ACV (annual contract value, годовая стоимость контракта) до $15K бенчмарки короче, 14–90 дней. Просрочка сделки относительно среднего по сегменту снижает win rate (долю успешно закрытых сделок) почти вдвое (Ebsta × Pavilion, 2025).

Это западные бенчмарки. Мой МСБ-сегмент был не быстрый SMB на 14–90 дней, а сделки в среднем на 2–5 месяцев: чек выше, часто нужен пресейл, согласование договора, проведение пилота. Именно для такого длинного хвоста когортная модель и нужна, ведь между «лид зашёл» и «клиент заплатил» проходит несколько отчётных периодов. Логика та же: чем длиннее цикл относительно нормы сегмента, тем больше накопленная стоимость в когорте.

В энтерпрайзе с большим чеком есть запас на длинный цикл. В МСБ запаса часто нет, и цикл становится одной из первых переменных экономики, с которой стоит работать.

Что это даёт на практике

Две точки контроля, которые появляются после внедрения модели.

Первая — регулярный обзор сделок старше N месяцев, где N это медианная длина успешной сделки в когорте плюс один. Считается из модели, а не «потому что давно висит». Каждую такую сделку прогоняем через правило выше, через отношение её стоимости к валовой прибыли контракта: либо возвращаем в работу с конкретным сроком, либо закрываем. Без модели этот разговор сводится к «у меня предчувствие». С моделью к цифре, которую видят все.

Вторая — Sales Cycle Length как KPI наравне с конверсией. Каждый месяц, на который вы укоротили средний цикл сделки в когорте, экономит на каждой активной сделке этого срока.

Где эта модель не нужна

Чтобы не уйти в крайность «всё считать когортно», проговорю обратное.

Когортная модель избыточна, если у вас:

• Короткий цикл сделки. Лид зашёл, закрытие в течение двух недель. Здесь классическая B2C-формула CAC = расходы периода ÷ клиенты периода работает корректно, потому что когорта затрат совпадает с когортой клиентов в пределах одного отчётного периода.

• Нет пайплайна как такового. Self-serve B2B (PLG, product-led growth, рост через продукт; чек до 10 000 руб./мес), где клиент проходит воронку сам, без активной работы сейлза. Расход на сейлза не аллоцируется, потому что сейлза нет.

• Расходы аллоцируются в месяц привлечения по факту. Если у вас performance-маркетинг, конверсия в подписку онлайн и минимальный онбординг, складывать накопленную стоимость по месяцам нечего, она и так в одном месяце.

Тащить когортную модель в эти ситуации — процесс ради процесса. Чем проще модель, отвечающая на ваши вопросы, тем лучше. Она нужна там, где между «лид зашёл» и «клиент заплатил» проходит больше одного отчётного периода, а в B2B SaaS с продажей через сейлза это почти всегда.

Что в итоге

Если у вас в B2B-продажах длинный цикл и привычная CAC-формула даёт цифру, в которую вы не верите, стоит перейти на когортную модель. Главное в ней — три принципа: единица учёта меняется с клиента-в-месяце на сделку-через-этапы; когорты формируются по месяцу появления сделки в пайплайне, а не закрытия; затраты разносятся на все активные сделки месяца и накапливаются по всем месяцам жизни когорты. Деление полных затрат на все сделки когорты, включая неуспешные, даёт честный CAC, который не стыдно показать совету директоров или инвестору.

Так закрылись три вопроса, с которых я начинал. Сколько на самом деле стоит сделка — полный CAC когорты с учётом неуспешных. Как на экономику влияет длина цикла — через накопление стоимости и Sales Cycle Length. Какой CAC показывать — честный, на всю когорту, а не наивный по месяцу закрытия.

Главный эффект не в «более точных цифрах», а в том, что разговор перестаёт быть про ощущения и становится про цифры, которые видят все. Ценность оказалась не в одной презентации совету, а в обычных ежедневных разговорах, которые модель сделала возможными.

Я понимал, из чего складывается стоимость привлечения, как на это влиять и что конкретно делать дальше. Например, ввести более тщательный пайп-ревью с CCO (коммерческим директором) и сейлзами. Я знал, на каком сроке сделка со средним для сегмента MRR становится невыгодной, и мог объяснить сейлзам, почему закрываю их «вечно живущие» сделки. Не потому что «мне кажется», а апеллируя к цифрам в общей таблице.

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

Шаблон в Google Sheets, можно скопировать к себе и адаптировать под свою воронку: убрать или добавить роли, поменять количество этапов, настроить пороги дашборда. Если будете адаптировать — буду рад услышать, что получилось, в комментариях или в моём канале.

Будут вопросы по адаптации под свою воронку — пишите в канал или в личку. Отвечу, а если надо, сядем и соберём модель под ваш бизнес. Мне самому интересно, на каких воронках она ломается.

Об авторе

Владимир Лунёв — независимый эксперт, автор методологии делегирования задач ИИ и Telegram-канала «Управление здорового человека». Более 15 лет в управлении IT: Ex. Руководитель бизнес-юнита МСБ Kaiten, Ex. Директор по развитию МСБ Bank CenterCredit, ex-СДЭК, ex-Яндекс.