директор и машина · стратегия · запись № 032 · 8 августа 2026 · Давид Герштейн

Юнит-экономика направления: посчитать, пока оно не съело прибыль

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

Это две стороны одной проблемы, и обе стоят денег прямо сейчас. Если руководитель не знает маржу направления, он либо хвалит канал, который уже съедает прибыль, либо режет тот, что кормит остальных — вслепую, без цифр. Возьмём условный, но типичный случай для иллюстрации: отдел из нескольких менеджеров со средним чеком заметного размера теряет 10% сделок на неизвестной стадии — просто потому что никто не считает по направлению и не видит, где они застревают. Формула для прикидки своего случая: количество сделок в работе × средний чек × доля зависших без объяснения = ежемесячные потери от непрозрачности воронки. В нашем примере это заметная часть месячной выручки (оценка, консервативно — без учёта возможного повторного возврата части сделок). Юнит-экономика бизнеса — не отчёт для инвестора раз в квартал, а ответ на вопрос «мы зарабатываем или проедаем» по каждому направлению отдельно, а не в среднем по компании.

Юнит-экономика бизнеса: почему средний расчёт по компании ничего не говорит

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

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

Где путаются цифры чаще всего

В одной из компаний план стратегии предполагал выручку в год, а в реальный план заложили сумму почти в два с половиной раза меньше. Разница возникла не потому что кто-то ошибся в расчётах, а потому что не договорились о терминах. Речь шла о сумме подписанных договоров или о фактических авансовых платежах, которые составляют 37–40% от суммы договора. Это не мелочь. Это разные деньги, разные кассовые разрывы и разная реальная маржа направления.

Точка безубыточности: считать раньше, чем радоваться росту

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

Точка безубыточности направления считается просто: постоянные расходы направления делятся на маржу с единицы. Пример на условных цифрах (для иллюстрации формулы, не из кейса): если постоянные расходы направления — заметная сумма в месяц, а маржа с одной сделки составляет десятую её часть, точка безубыточности — 10 сделок в месяц. Девятая сделка ещё не окупает направление, десятая — только выводит в ноль, и лишь начиная с одиннадцатой направление зарабатывает. Сложность не в формуле, а в том, чтобы честно разнести расходы. Если аренда, зарплата бэк-офиса и часть маркетинга не распределены по направлениям, а висят «на компании в целом», точка безубыточности каждого направления будет занижена — и решение о его судьбе примут на основе неверных цифр.

На диаграмме — та же вилка дохода наглядно: как процент от прибыли сильно колеблется, а фиксированный оклад держится в узком коридоре.

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

Механика расчёта: что → чем → куда

Расчёт юнит-экономики направления — это не разовая аналитическая сессия, а еженедельный цикл. Вот как он выглядит по шагам, чтобы его можно было повторить с любой командой:

1. Что. Каждую сделку и каждый расход помечают направлением (продукт, рынок, канал) — не «на компанию», а конкретно. Источник данных — CRM (Bitrix24 или amoCRM) плюс таблица расходов, которая обычно ведётся отдельно от CRM.
2. Чем. Раз в неделю, в фиксированный день, данные выгружаются в единую таблицу — вручную или через вебхук. В одной из компаний выбрали четверг: результаты недели копятся к этому дню и сводятся в отчёт по трём блокам — маркетинг, продажи, авансы.
3. Куда. Свод попадает в Google Таблицу с формулами точки безубыточности по каждому направлению: постоянные расходы направления ÷ маржа с единицы. Формула, а не фиксированное число — чтобы не пересчитывать вручную каждый раз, когда меняются вводные.
4. Кто смотрит. Руководитель направления — каждый четверг, до общей планёрки. Собственник или финдиректор — раз в месяц, сравнивая тренд, а не разовое значение.

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

ИИ-связка: как автоматизировать сбор и первичный анализ

Ручной свод раз в неделю занимает у аналитика или ассистента руководителя 2–3 часа: выгрузить сделки из CRM, сверить с таблицей расходов, найти нестыковки терминов («договор» вместо «аванс»), пересчитать маржу по направлениям. Это рутина, которую можно передать модели — но не для принятия решений, а для подготовки черновика отчёта, который потом проверяет человек.

Схема конвейера:

CRM (Bitrix24/amoCRM) → еженедельный вебхук выгружает сделки за неделю в JSON → скрипт на Google Apps Script объединяет их с таблицей расходов по направлениям → дешёвая модель (уровня GPT-4o-mini) классифицирует записи и считает точку безубыточности по формуле → черновик отчёта падает в Google Sheets и дублируется в Telegram-канал руководителя → человек проверяет цифры перед четверговой встречей.

Дешёвая модель здесь оправдана: задача — классификация и арифметика по заданной формуле, а не творческий анализ. Гонять через дорогую модель тысячи строк сделок ради пересчёта маржи — переплата без выигрыша в качестве. Дорогую модель имеет смысл подключать только на втором шаге — когда нужно объяснить руководителю аномалию человеческим языком, а не выдать сырые цифры.

Пример входных данных, которые скрипт формирует из CRM-выгрузки и таблицы расходов (упрощённая структура для одного направления за неделю):

Ты — финансовый аналитик. На входе JSON с данными по одному направлению бизнеса за неделю.
Твоя задача: посчитать точку безубыточности, маржу с единицы и указать на несоответствия
терминов (например, если сумма похожа на "сумму договора", а не на фактическое поступление).

Правила:
1. Не путай "выручка по договору" и "фактическое поступление (аванс)". Если в данных
   встречается оба поля — считай юнит-экономику ТОЛЬКО по фактическим поступлениям.
2. Точка безубыточности = постоянные_расходы_направления / маржа_с_единицы.
3. Если данных недостаточно для расчёта (нет разбивки расходов по направлению) —
   явно укажи это в поле "warnings", не додумывай цифры.
4. Ответ верни строго в формате JSON без пояснений вне структуры.

Входные данные:
{
  "direction": "Направление B",
  "period": "2026-W32",
  "deals": [
    {"id": "1042", "contract_sum": 480000, "actual_payment": 190000, "status": "в работе"},
    {"id": "1043", "contract_sum": 320000, "actual_payment": 320000, "status": "закрыта"}
  ],
  "fixed_costs_direction": 410000,
  "variable_cost_per_unit": 65000
}

Пример ответа модели, который ложится в таблицу без ручной доработки:

{
  "direction": "Направление B",
  "period": "2026-W32",
  "actual_revenue": 510000,
  "margin_per_unit": 255000,
  "break_even_units": 1.6,
  "warnings": [
    "contract_sum и actual_payment расходятся по сделке 1042 на 60%: считать по actual_payment",
    "недостаточно данных для проверки, включён ли фонд бэк-офиса в fixed_costs_direction"
  ]
}

Здесь видно, как работает формула на реальных числах: постоянные расходы направления делятся на маржу с единицы — получается 1,6. То есть направлению нужно закрыть меньше двух сделок в неделю, чтобы выйти в ноль по фиксированным расходам этой недели; всё сверху — вклад в прибыль. И сразу видно, почему нельзя было взять contract_sum вместо actual_payment: сумма по сделке 1042 почти вдвое больше фактического поступления — если бы модель считала по договору, точка безубыточности выглядела бы пройденной, хотя деньги ещё не пришли.

Вот как этот черновик выглядит уже собранным — в виде отчёта в Google Таблице или Telegram-боте, который руководитель открывает в четверг утром:

Инженерная обвязка простая и без экзотики: вебхук из Bitrix24 настроен на событие «изменение стадии сделки», данные копятся в промежуточном листе Google Sheets, скрипт запускается по расписанию (Apps Script trigger, каждый четверг утром). Если вебхук не отработал или модель вернула невалидный JSON — бот в Telegram присылает сообщение «отчёт за неделю не собран, проверь вручную» вместо того, чтобы молча подставить пустые значения. Это критично: расчёт юнит-экономики, который тихо сломался и продолжает показывать старые цифры, опаснее, чем его отсутствие — про похожий сценарий тихой поломки я писал в статье про то, как CRM сдвигает даты незаметно для пользователя.