На этой странице
Короткий ответ
Считайте прибыль на активную карточку после прямых затрат, труда и доли общих расходов; масштаб имеет смысл только если часы на проект не растут вместе с количеством клиентов.
Определите единицу расчёта
Клиент, договор, карточка и филиал — не одно и то же. Сеть из двадцати точек может быть одним клиентом, но создавать двадцать наборов запросов и отчётов. Для производственной экономики удобнее считать активную карточку в месяц, а для продаж — клиента и договор. Свяжите обе единицы коэффициентом карточек на клиента.
Не подставляйте текущие тарифы из памяти. Создайте таблицу переменных и обновляйте их из официального прайса и фактического учёта времени. Модель должна переживать смену цены: меняются входные данные, а не логика расчёта.
Запишите базовые формулы
Обозначим P — месячную выручку с карточки, V — прямые переменные затраты платформы и инфраструктуры, H — часы команды, R — среднюю полную стоимость часа, O — долю общих расходов. Вклад на карточку: CM = P − V − H × R. Операционная прибыль: OP = CM − O. Маржинальность: OP / P.
Для клиента с N карточками добавьте разовую стоимость онбординга B и ежемесячные общие часы A, не зависящие от количества точек. Тогда прибыль клиента: N × (P − V − H × R) − A × R − O − амортизированная доля B. Это показывает, почему сеть нельзя оценивать простым умножением розничного пакета.
| Переменная | Что измерять |
|---|---|
| P | Фактическая выручка без обещаний будущего апсейла |
| V | Лицензия, Cloud, инфраструктура и прямые сервисы |
| H | Производство, контроль, отчёт и поддержка на карточку |
| R | Полная стоимость часа с налогами и нагрузкой |
| O | Продажи, управление, ПО и прочие общие расходы |
Сравните сценарии масштаба
Для 1 карточки доминируют онбординг и настройка. На 10 появляются повторяемые шаблоны. На 50 ручная координация становится риском, а на 100 любое исключение превращается в очередь. Не утверждайте заранее, что маржа обязательно растёт: она растёт только если автоматизация снижает H и A быстрее, чем увеличиваются контроль и поддержка.
Сделайте три сценария — консервативный, базовый и эффективный. Меняйте часы, загрузку специалиста, долю ошибок и отток, а не только цену. Отдельно моделируйте Software и Cloud: в Software агентство несёт больше самостоятельной операционной работы и контроля среды; в Cloud платит за формат без установки и инфраструктуры на своей стороне.
- 1Проверка спроса и реального времени на весь цикл.
- 10Стандартизация брифа, семантики и отчёта.
- 50Реестр, очереди, контроль исключений и резерв команды.
- 100Автоматизация, SLA данных и отдельная функция качества.
Учтите то, что обычно забывают
Время продаж, неуспешный онбординг, восстановление доступов, переделка отчётов, просроченные оплаты и поддержка клиента не бесплатны. Добавьте стоимость качества: выборочный аудит, реакцию на аномалии, резерв на болезнь специалиста. Без этого таблица показывает красивую валовую маржу, а счёт компании — нехватку денег.
Считайте отток и срок жизни отдельно, не превращая их в гарантии. LTV-модель: месячная операционная прибыль клиента × ожидаемое число месяцев минус стоимость привлечения и онбординга. Используйте исторический диапазон, а не желаемый срок договора. При малой выборке показывайте сценарии.
Соберите управленческую панель
Ежемесячно смотрите карточки на специалиста, часы на карточку, долю проектов с исключениями, валовый вклад, операционную прибыль, отток и дебиторку. Разделяйте новые и зрелые проекты: онбординг временно дороже. Для сетей показывайте экономику клиента и точки одновременно.
Решение о цене или формате принимайте после анализа причины. Низкая маржа может означать неверный пакет, слабый процесс, слишком много ручной отчётности или неподходящий продукт. Сначала исправьте драйвер, затем меняйте коммерческие условия через владельца продукта.
Подставьте свои данные и проверьте Software
Агентствам с объёмом обычно важны контроль и стоимость единицы. Получите тестовый доступ к Software, замерьте реальные часы и сравните с Cloud по полной экономике.