Валовая маржа SaaS: где технические решения съедают прибыль

Почему утечки прибыли остаются незаметными

Валовая маржа — это деньги, которые остаются после оплаты прямых затрат на поставку вашего софта. Если клиент платит 10 000 долларов, а вы тратите 3 000 долларов на хостинг, время поддержки, онбординг и сторонние инструменты, чтобы обслужить этого клиента, ваша валовая маржа составляет 7 000 долларов. Эта цифра важнее общей выручки, если вы хотите, чтобы софтверный бизнес продолжал приносить деньги.

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

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

Фаундеры часто не замечают этого, потому что потеря выручки звучит громко. Ушедший клиент или плохой месяц продаж быстро привлекают внимание. Потеря маржи тише. Она проявляется в переработках, ещё одном дорогом облачном сервисе, ещё одном исключении в продукте или ещё одном обещании клиенту, которое никто не оценил как следует.

Ещё одна распространённая ошибка — смешивать разовые затраты на запуск с постоянными затратами на поставку.

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

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

Когда работа на доставку перестаёт окупаться

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

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

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

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

Именно тогда сервисная работа начинает выглядеть как продуктовая выручка. Контракт по-прежнему висит в повторяющейся выручке на дашборде, но модель поставки уже больше похожа на кастомную разработку: индивидуальные запросы, ручной уход и постоянные толкования. Компания говорит «SaaS». Структура затрат говорит «агентство».

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

Когда кастомные запросы становятся постоянными затратами

Один клиент просит маленькое исключение, и команда соглашается, потому что сделка кажется стоящей. Второй клиент хочет почти то же самое, но не совсем. Через полгода в продукте появляются дополнительные ветки, специальные настройки, странные крайние случаи и заметки по поддержке, которые понимают только два инженера.

Вот так и проседает маржа. Первый запрос кажется дешёвым. Дальние последствия — нет.

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

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

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

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

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

Инфраструктурные привычки, которые съедают прибыль

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

Скрытые потери

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

Обсуждать это на продуктовом совещании почти не принято. Зато позже это всплывает в счёте за облако, который растёт быстрее выручки. Если команда ещё и берёт кастомную разработку, проблема усиливается. Дополнительные среды, кастомные интеграции и задачи под конкретного клиента часто продолжают жить ещё долго после того, как работа перестала приносить деньги.

Слабый мониторинг только усугубляет ситуацию. Если никто не отслеживает стоимость по сервисам, длительность задач, частоту ошибок и тренды использования, команда не видит, что именно съедает деньги. Люди начинают гадать. Они добавляют мощности, чтобы чувствовать себя в безопасности, или покупают ещё один инструмент, потому что первый кажется слишком шумным. Осторожность — это нормально. Слепая осторожность стоит дорого.

Удобство выходит дорого

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

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

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

Как пошагово проверить риск для маржи

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

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

1. Запишите каждую активность по порядку. Сделайте это просто: кто её делает, как часто и сколько времени это обычно занимает.
2. Добавьте примерную стоимость, а не идеальную. Используйте почасовую стоимость команды, ежемесячную стоимость инструментов и облачное потребление, связанное с этим клиентом или функцией.
3. Отметьте всё, что повторяется для каждого клиента. Повторяющаяся работа — это место, где маржа проседает быстрее всего, потому что рост умножает её.
4. Решите, что нужно для каждого дорогого шага: убрать его, автоматизировать, стандартизировать или переоценить.
5. Через месяц снова пройдите по тому же потоку и сравните цифры.

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

Следите за кастомной работой, которая притворяется мелкой. Обещание продаж в духе «просто одна кастомная интеграция» часто добавляет месяцы тестирования, нагрузку на поддержку и боль при обновлениях. Первый счёт может оплатить разработку. Дальше он почти никогда не покрывает длинный хвост.

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

Простой пример из растущей SaaS-команды

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

Потом начали приходить более крупные клиенты. Это выглядело как победа. Три новых аккаунта платили примерно в четыре раза больше обычного клиента, и отдел продаж активно давил, чтобы закрыть их.

Проблемы начались с обещаний, данных во время сделки. Один клиент захотел кастомные отчёты для своей финансовой команды. Другой попросил private hosting, потому что его IT-лид считал это более безопасным. Третий хотел особый формат экспорта и несколько правил согласования, которыми никто другой не пользовался.

Выручка быстро росла. Маржа — нет.

Кастомные отчёты отнимали у одного инженера по несколько часов каждую неделю, потому что каждое новое поле данных меняло логику. Для private hosting понадобились собственный мониторинг, бэкапы, шаги деплоя и проверки поддержки. Формат экспорта сначала выглядел мелким, но теперь каждое обновление продукта требовало дополнительного тестирования, потому что именно этот клиент мог сломаться по-другому.

За два квартала валовая маржа упала с 78% до 61%. Расходы на облако выросли, но больший ущерб нанесли затраты на персонал. Команда тратила больше времени на работу, которой пользовался только один аккаунт, и это время не помогало остальной базе клиентов.

Они исправили ситуацию несколькими понятными правилами. Кастомная отчётность стала стандартным платным пакетом с жёсткими ограничениями. Новых enterprise-клиентов переводили на общую инфраструктуру, если только контракт явно не покрывал полную стоимость private hosting. Команда также добавила плату за изменения для особых запросов и ежемесячную плату за поддержку всего, что создавало постоянную работу.

Один клиент остался на private setup, но теперь платил достаточно, чтобы это окупать. Другой согласился на стандартный пакет отчётности, когда увидел цену кастомной работы. Третий получил более чистый экспорт, который вписался в продукт, а не в отдельную ветку кода.

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

Ошибки, которые команды совершают, когда режут расходы

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

Это проявляется в мелочах. Команда убирает платный помощник для деплоя, тестовый дашборд или внутренний админ-инструмент, потому что они кажутся необязательными. Потом старшие инженеры тратят по три-четыре часа в неделю, закрывая эту дыру. Если так делают два человека каждую неделю, «экономия» быстро исчезает.

Ещё одна частая ошибка — урезать проверки качества. Команды убирают тесты, пропускают code review или ослабляют проверки релизов, потому что хотят меньше задержек. Неделю-две это может выглядеть дешевле. Потом баги доходят до клиентов, команда останавливает работу над фичами, чтобы всё исправить, и один инцидент съедает месяцы экономии.

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

Заморозка найма может создать ту же ловушку. Иногда это разумно, но работает только если меняется и модель поставки. Если бизнес продолжает брать тяжёлую кастомную разработку, продолжает обещать каждому клиенту всё подряд и продолжает держать те же сроки, нагрузка ложится на существующую команду. Работа замедляется, поддержка растёт, а выгорание становится скрытой стоимостью.

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

Более правильная проверка проста:

• Убирает ли это работу или просто перекладывает её на инженеров?
• Увеличит ли это риск багов или сбоев?
• Исправляем ли мы модель поставки или только замораживаем найм?
• Заметят ли клиенты более медленную скорость или худшую надёжность?

Хорошие технические лидеры обычно начинают именно с этого. Самые безопасные сокращения уменьшают повторную работу, сдерживают кастомные обещания и убирают потери до того, как они дойдут до клиентов.

Краткая проверка маржи на этот месяц

Ежемесячная проверка маржи должна занимать 20 минут. Если для этого нужен слайд-дек, вы уже делаете слишком много. Цель — найти работу и расходы, которые тихо выросли, пока выручка стояла на месте.

Задайте команде пять прямых вопросов. Если никто не может ответить хотя бы на один меньше чем за две минуты, этот пробел — часть проблемы.

• Может ли кто-то назвать три крупнейшие статьи затрат на поставку прямо сейчас? Для большинства софтверных команд это значит время инженеров, время поддержки, счета за облако, расходы на подрядчиков или работу команды customer success. Если люди гадают, а не знают, маржа движется без контроля.
• Получает ли кто-то кастомную работу без цены, срока или письменного одобрения? Маленькие уступки часто превращаются в постоянные обязательства.
• Расходы на облако выросли быстрее, чем активное использование? Большой счёт не всегда проблема. Большой счёт при неизменном числе пользователей, трафике или выручке обычно означает потери или слишком крупную инфраструктуру.
• Повторяют ли инженеры ручную настройку, QA или поддержку каждую неделю? Если один и тот же человек каждую пятницу выкатывает релизы вручную, исправляет тестовые данные или отвечает на один и тот же вопрос, это время напрямую уходит из маржи.
• Изменил ли один срочный запрос клиента основной продукт? Именно здесь команды дают дорогие обещания. Торопливое изменение для одного аккаунта может добавить тестирование, поддержку, крайние случаи и путаницу в продукте для всех остальных.

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

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

Что делать дальше

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

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

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

Для старта не нужен идеальный дашборд. Общий документ и 30 минут в календаре могут показать очень многое. Через два-три месяца паттерны уже трудно игнорировать.

Если команда не может объяснить, откуда на самом деле берутся затраты на поставку, поможет внешний технический аудит. Oleg Sotnikov на oleg.is работает как фракционный CTO и советник для стартапов, и такой аудит хорошо подходит под эту роль: посмотреть на кастомную работу, инфраструктуру и привычки команды, а затем решить, что убрать, автоматизировать, переоценить или закрыть.

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

Прибыль редко возвращается одним большим рывком. Обычно она возвращается через несколько чётких решений, которые команда наконец принимает и доводит до конца.