Ценообразование функций ИИ до того, как скидки съедят вашу маржу

Почему популярная функция ИИ может приносить убытки

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

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

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

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

Здесь важно ценообразование SaaS на основе затрат. Вам нужна цена, которая покрывает вызовы модели, повторы, труд проверки и обработку сбоев до того, как кто‑то начнёт давать скидки. Если ждать, пока клиенты полюбят функцию, изменить цену будет гораздо сложнее. Люди сравнивают новое число с тем, что платят сейчас, а не с вашими издержками.

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

Что считать перед установкой цены

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

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

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

Простой способ думать об этом — считать пять корзин затрат на каждые 100 использований: затраты на модель (вход и выход), повторы и резервные прогоны, время ручной проверки, возвраты или кредиты плюс обработка поддержки, и платёжные комиссии с базовой накладной.

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

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

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

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

Считайте стоимость за использование, а не лишь месячную оценку

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

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

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

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

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

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

Часто именно тогда ценообразование становится понятнее. Как только команда видит стоимость одного реального действия, правила скидок перестают быть гаданием.

Постройте цену в пяти шагах

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

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

1. Оцените, сколько раз этот клиент будет использовать функцию в месяц. Опирайтесь на реальное поведение, если оно есть. Если нет — запишите низкий и вероятный сценарии.
2. Умножьте это использование на вашу стоимость за единицу. Включите вызовы модели, хранилище, повторы, логирование и любые другие траты, которые возникают каждый раз.
3. Добавьте время людей. Считайте ручные проверки, тикеты поддержки и время на проверку плохих результатов или странных случаев.
4. Добавьте маржу до того, как кто‑то попросит скидку. Если продажи обычно дают 15% скидки, ваша прайс-лист должна иметь запас, чтобы покрыть затраты.
5. Протестируйте цену при двойном ожидаемом использовании. Популярные функции редко остаются на аккуратном номере из первой таблицы.

Небольшой пример показывает риск. Допустим, один клиент использует функцию 3 000 раз в месяц, ваша техническая стоимость — $0.03 за использование, а проверка и поддержка добавляют ещё $60 в месяц. Прямые затраты — $150. Если вы ставите цену $180, обычная скидка может стёреть большую часть маржи.

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

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

Включайте труд проверки без самообмана

Большинство команд недооценивают работу проверки, потому что считают её фоновым процессом. Если человек проверяет вывод ИИ — это часть стоимости функции.

Используйте секундомер, а не догадки. Засекайте реальные проверки с момента открытия случая до момента, когда кто‑то подтверждает, редактирует, отклоняет или отправляет ответ с пометкой. Проверка, которая кажется двумя минутами, часто занимает больше, если учитывать чтение контекста, проверку источников и написание краткого объяснения.

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

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

Простой пример иллюстрирует смысл. Пусть ревьюер тратит 4 минуты на первый проход, в среднем 1 минуту на повторные проверки и 30 секунд на общение с клиентом, распределённое по всем случаям. Менеджер тратит 10 минут на 5% запросов — это ещё 30 секунд на запрос. Быстрая проверка уже 6 минут, а не 4.

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

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

Цените обработку сбоев до того, как она начнёт вредить

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

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

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

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

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

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

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

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

Установите правила скидок до того, как продажи начнут просить

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

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

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

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

Обычно достаточно трёх типов пакетов:

• Standard: полная цена, нормальные лимиты использования, стандартная проверка.
• Volume: ниже цена за использование при обязательстве по объёму и меньшей ручной помощи.
• Custom: отдельное ценообразование для проверки, обработки сбоев и специальных рабочих процессов.

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

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

Простой пример с реальными цифрами

Команда SaaS продаёт AI‑резюме лидов для занятых менеджеров по продажам. Предложение простое: каждый менеджер платит $27 в месяц и может создавать резюме для новых лидов перед звонками.

Первый прогон модели стоит всего $0.06, поэтому функция кажется дешёвой. Это вводит в заблуждение.

Реальная стоимость резюме выше. Первый прогон — $0.06. Перезапуски добавляют в среднем ещё $0.009, потому что 15% резюме требуют ещё одного прогона. Ручная проверка добавляет в среднем $0.16, потому что 1 из 5 резюме требует 2 минуты от операционного ревьюера с оплатой $24/час. Обработка сбоев, включая повторы, кредиты и время поддержки, добавляет ещё $0.03.

Итого истинная стоимость около $0.259 за резюме.

При 80 резюме на менеджера месячные затраты: 80 x $0.259 = $20.72. При полной цене $27 функция всё ещё приносит прибыль. Валовая маржа на активного менеджера — $6.28. Это рабочий показатель, но не роскошный.

Теперь продажи просят скидку 30% ради крупного клиента. Цена падает с $27 до $18.90 за менеджера.

Ничего больше не изменилось. Использование всё так же 80 резюме. Ревью всё так же нужно. Перезапуски всё так же происходят. Поддержка всё так же обрабатывает сбои. Месячные затраты остаются $20.72, поэтому команда теряет $1.82 на активного менеджера.

Если в аккаунте 500 активных менеджеров, функция убыточна на $910 в месяц. Если использование вырастет, потому что менеджерам нравятся резюме, убыток станет больше.

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

Ошибки, которые команды делают в первом проходе ценообразования

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

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

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

Труд проверки тоже меняется с объёмом. При 100 использований в неделю один человек может просматривать редкие ошибки. При 10 000 использований формируются очереди, крайние случаи накапливаются, и кто‑то должен владеть процессом. Время проверки редко остаётся постоянным с ростом использования.

Признаки проблем обычно очевидны:

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

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

Быстрая проверка перед запуском

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

Проведите четыре проверки перед запуском.

1. Надавите на один аккаунт. Если один клиент удваивает нормальное использование, остаётся ли маржа положительной после учёта вызовов модели, повторов, логирования и ручной проверки? Если нет — добавьте лимиты использования, плату за перерасход или ужесточите лимиты по планам.
2. Установите минимум по скидкам. Продажи попросят большую скидку раньше, чем вы думаете. Запишите самую низкую разрешённую цену, минимальную приемлемую маржу и ответственного за одобрение исключений.
3. Опишите поведение при ошибочном выводе. Каждый план должен говорить, что происходит, если ИИ даёт плохой ответ, таймирует или требует второго прохода. Решите: повторять автоматически, отправлять на проверку, компенсировать кредитом или считать как использование.
4. Используйте единый свод правил. Продажи, поддержка и финансы должны цитировать одни и те же условия по ценам, кредитам, скидкам и срокам проверки. Если у каждой команды своё объяснение, клиенты найдут разницу.

Сделайте документ коротким. Две страницы максимум; достаточно одной, если там есть лимиты планов, минимум по скидкам, правила перерасхода и обработка сбоев.

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

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

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

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

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

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

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

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