Ценообразование кастомной работы без вреда для продуктового плана

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

Кастомная работа редко вредит вам в первый день. Обычно она бьёт позже.

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

Как только это исключение выходит в релиз, команде приходится помнить о нём каждый раз, когда она касается продукта. Ответы поддержки становятся длиннее. QA нужны дополнительные проверки. Новым сотрудникам приходится объяснять, почему у одного клиента всё работает иначе. Исправление, которое должно занять один день, растягивается на два, потому что кто-то должен спросить: «Это не сломает тот кастомный сценарий?»

Вот так и утекает маржа. Первоначальная работа может занять 20 часов. А следом эта история будет возвращаться месяцами.

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

Это быстро происходит в небольшой SaaS-компании. Сначала у вас чистый инструмент с понятным процессом. Один клиент получает особый экспорт. Другой — другую роль пользователя. Третий просит почти то же самое, что и первый, но не совсем. И вот у вас уже нет чёткого продуктового решения. У вас куча частных договорённостей.

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

Разделите работу на три категории

Большинство неудачных кастомных сделок начинается с одной расплывчатой суммы.

Клиент видит одну цену, но на самом деле ваша команда берёт на себя три разных вида работы: setup, support и roadmap work. Они стоят по-разному, и цену для них тоже надо задавать по-разному.

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

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

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

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

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

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

Решите, что относится к setup

Setup должен покрывать работу, которая проводит клиента от подписанной сметы до аккуратного первого запуска. Он не должен превращаться в корзину для любого запроса, который появляется до или после go-live.

Обычно setup-пакеты вполне стандартные: импорт старых данных, настройка ролей и прав, обучение администраторов или обычных пользователей, проверка перед запуском и финальная передача.

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

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

Дата окончания важна не меньше цены. Setup должен заканчиваться в чёткой точке передачи, например «через 10 рабочих дней после подтверждения импорта» или «после первого отчёта по первой неделе работы». После этого начинается оплата поддержки. Без этой границы клиенты будут растягивать setup-нужды неделями.

Полезно ещё и прямо указать, что в setup не входит. Кастомные функции, бесконечная чистка данных, новые отчёты, дополнительное обучение и поддержка после запуска должны оставаться вне setup, если только они отдельно не перечислены в смете.

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

Назначайте цену на поддержку, не пряча её

Многие команды прячут поддержку в цене проекта, потому что так в момент сделки кажется проще. Обычно это ошибка.

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

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

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

• Исправление бага означает, что работа не соответствует согласованному объёму.
• Совет — это когда клиенту нужна помощь с использованием, планированием или проверкой чего-то.
• Запрос на изменение — это новая работа.

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

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

Выносите общие запросы в roadmap

Некоторые запросы сначала выглядят кастомными, но на самом деле это сигналы для продукта.

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

Помогает быстрый тест. Задайте себе три вопроса:

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

Если ответ «да», перестаньте считать это разовой уступкой.

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

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

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

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

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

Как оформить сделку в смете

Хорошая смета делает продажу простой и защищает продукт.

Не отправляйте одну общую сумму с размытыми примечаниями. Разбейте сделку на части, чтобы обе стороны видели, что именно покупают, когда это закончится и что будет после запуска.

1. Начните со стандартного продукта. Сначала укажите обычный план или лицензию, используя ту же базовую цену, которую вы даёте похожим клиентам.
2. Добавьте setup отдельной строкой. Назовите каждый пункт, задайте лимит и укажите дату. Например: импорт до 5 000 записей, подключение одного платёжного провайдера и обучение в рамках двух сессий до 30 мая.
3. Добавьте support как отдельный план. Подберите его под реальные потребности клиента.
4. Уберите переиспользуемые идеи из коммерческого предложения. Если запрос может помочь нескольким клиентам, вынесите его в заметку по roadmap, а не в цену setup.
5. Укажите, что не входит в смету. Отдельно отметьте дополнительные интеграции, разработку функций, чистку сверх согласованного лимита и выездные работы, если вы их не предоставляете.

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

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

Смета не обязана быть длинной. Она должна быть понятной.

Простой пример из небольшой SaaS-сделки

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

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

Чистый вариант проще.

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

Изменения отчёта и ежедневные вопросы не должны прятаться внутри setup. Такие запросы обычно продолжаются и после запуска. Их лучше вынести в ежемесячную поддержку с понятным объёмом и лимитом.

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

Смета может выглядеть так:

• 3 000 $ — setup за импорт и обучение
• 500 $ в месяц — поддержка, включая правки отчёта и вопросы
• SSO не входит в эту смету и пройдёт через продуктовый разбор, если спрос сохранится

Такая структура делает сделку честной. Клиент видит, что он платит один раз, что он платит каждый месяц и что всё ещё остаётся продуктовой работой. У компании при этом остаются один продукт, один код и один roadmap.

Ошибки, из-за которых рождаются разовые продукты

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

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

Ещё одна проблема начинается прямо на звонке. Кто-то говорит: «Да, это можно добавить», — ещё до того, как запрос увидели продукт или разработка. В итоге в смету попадает не услуга, а функция. Так обещания продаж превращаются в долг для roadmap.

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

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

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

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

Что проверить перед отправкой сметы

Если смету нужно объяснять десять минут, скорее всего, она слишком запутанная.

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

Перед отправкой сделайте быструю проверку:

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

Один простой тест работает особенно хорошо: представьте, что на следующей неделе второй клиент попросит тот же пакет. Сможете ли вы продать его снова, меняя только мелочи? Если да — структура, скорее всего, хорошая. Если нет — перенесите часть работы в roadmap или возьмите оплату за дополнительный setup уже сейчас.

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

Иногда помогает второй взгляд перед отправкой предложения. Oleg Sotnikov на oleg.is работает как Fractional CTO и startup advisor, и именно с такими проблемами по объёму работ и границам продукта он помогает основателям разбираться.

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

Возьмите последние пять подписанных сделок и разнесите все обещанные задачи по трём категориям: setup, постоянная поддержка или roadmap work. Сделайте это на бумаге или в таблице. Если какая-то задача всё время прыгает между категориями, значит, процесс смет у вас всё ещё слишком расплывчатый.

Потом обновите шаблон предложения. Каждый раз держите setup, support и roadmap work в отдельных строках.

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

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

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