Монетизация Ladcraft, платформы автономных ИИ-агентов, устроена сложнее, чем у классического SaaS. Стоимость работы двух пользователей на одном и том же тарифе может отличаться в разы: один отправляет пару простых запросов, другой запускает задачу, внутри которой агент несколько раз обращается к LLM и подключает дополнительные инструменты. Обычная “фиксированная” подписка это не учитывает, и поэтому вопрос честного, но прибыльного ценообразования становится критическим для бизнеса.
О компании
Группа IT-компаний Lad — российский разработчик цифровых продуктов — поделилась опытом того, как выстроила монетизацию своей AI-платформы LadCraft и почему решила не разрабатывать собственный биллинг, а использовать возможности платформы LBX.
LadCraft — это платформа автономных ИИ-агентов, которые самостоятельно выполняют задачи от текстового запроса до готового результата. Платформа помогает анализировать документы и данные, готовить отчеты и материалы, работать с корпоративными системами, планировать встречи и автоматизировать процессы.
Доступ к платформе и ее функциям предоставляется по подписке, а на использование этих функций тратятся кредиты
LadCraft — это платформа автономных ИИ-агентов, которые самостоятельно выполняют задачи от текстового запроса до готового результата. Платформа помогает анализировать документы и данные, готовить отчеты и материалы, работать с корпоративными системами, планировать встречи и автоматизировать процессы.
Доступ к платформе и ее функциям предоставляется по подписке, а на использование этих функций тратятся кредиты
Почему для AI-продукта одной подписки мало
Ключевая особенность AI-продукта в том, что себестоимость пользовательских сценариев сильно различается. Обработка простого запроса и сложной многоэтапной задачи требуют от платформы совершенно разных ресурсов, но фиксированная подписка эту разницу не учитывает. Поэтому в LadCraft подписку совместили с кредитной моделью:
Кредиты никогда не сгорают. Их можно докупить на любом тарифе.
- тариф открывает пользователю доступ к функциям и инструментам. Это не «пакет запросов», а набор возможностей: какие агенты, интеграции и сколько места в хранилище доступно пользователю;
- кредиты тратятся на использование ресурсов (в первую очередь на обращения к LLM) и покупаются отдельно.
Кредиты никогда не сгорают. Их можно докупить на любом тарифе.
Какие требования к биллингу были важны при проектировании продукта?
Продукту нужна была не просто оплата, а полноценная логика вокруг подписки:
Отдельно важно было корректно связать подписку с кредитной моделью.
Было требование к финансовой строгости: баланс не должен уходить в минус, а каждое начисление обязано выполняться ровно один раз, даже если одно и то же событие от платежной системы пришло повторно
И, наконец, прозрачность: пользователь должен видеть свой тариф, текущий расчетный период, доступный остаток и понимать, что произойдет при исчерпании кредитов.
- Бесплатные (freemium) и платные тарифы;
- автоматическое продление подписки;
- разовая покупка дополнительных кредитов;
- апгрейды и даунгрейды тарифов;
- обработка успешных и неуспешных платежей;
- разные статусы подписок;
- расчетные периоды;
- возможность отмены подписки
Отдельно важно было корректно связать подписку с кредитной моделью.
Было требование к финансовой строгости: баланс не должен уходить в минус, а каждое начисление обязано выполняться ровно один раз, даже если одно и то же событие от платежной системы пришло повторно
И, наконец, прозрачность: пользователь должен видеть свой тариф, текущий расчетный период, доступный остаток и понимать, что произойдет при исчерпании кредитов.
Узнать подробнее: Как работает биллинг LBX для AI-сервисов
Что оставили внутри продукта, а что передали в LBX
Внутри LadCraft осталась вся логика, связанная непосредственно с использованием AI:
Это продуктовая логика, потому что только LadCraft знает, какие действия выполнил агент, какие модели и инструменты он использовал и сколько в итоге стоила конкретная задача.
В LBX передали подписочный и платежный контур:
- фиксация фактического потребления ресурсов;
- расчет стоимости выполненных операций в кредитах;
- хранение кредитного баланса;
- начисление и списание кредитов;
- проверка доступного остатка;
- ограничения при исчерпании баланса;
- отображение пользователю состояния кредитов
Это продуктовая логика, потому что только LadCraft знает, какие действия выполнил агент, какие модели и инструменты он использовал и сколько в итоге стоила конкретная задача.
В LBX передали подписочный и платежный контур:
- управление подписками;
- начало и завершение расчетных периодов;
- регулярные и разовые оплаты;
- продление, отмену и смену тарифа;
- статусы оплаты и взаимодействие с платежным шлюзом;
Сначала в компании рассматривали вариант разработать эту часть самостоятельно и напрямую интегрироваться с ЮKassa. Но быстро стало понятно, что это не подключение платежной формы, а по сути создание собственного ядра подписочного биллинга: статусы подписок, автопродление, повторные попытки списания, апгрейды и даунгрейды, возвраты, обработка webhook-событий, защита от дублей и неизменяемая финансовая история.
Вместе с разработкой пришлось бы взять на себя и полную ответственность за любые ошибки в платежах, начислениях и применении тарифных правил. Рациональнее было оставить в продукте только специфичную логику, а стандартную, но сложную, подписочную часть отдать специализированной платформе.
Как выбирали биллинг и почему остановились на LBX
Основными критериями выбора были:
Компании было важно выбрать не просто платежный сервис, а специализированное биллинговое решение, которое уже умеет управлять жизненным циклом подписки. Помимо LBX рассматривали альтернативное решение и вариант собственной разработки.
Решающей стала техническая готовность LBX к быстрой интеграции, а также отдельно сыграла роль работа команды. Еще до заключения договора LBX предоставили тестовый доступ к интерфейсу и API - решение принимали не по презентации, а протестировав продукт на практике. Команда провела подробную демонстрацию, изучила техническое задание, обращала внимание на неоднозначные места в сценариях и помогла разобраться в расценках и комиссиях при работе с ЮKassa. После старта работ для проекта создали отдельную группу в Telegram, оперативно отвечали на вопросы и помогали с API.
- скорость интеграции;
- полнота и удобство API;
- возможность реализовать свои сценарии без доработок на стороне поставщика;
- поддержка подписок и разовых покупок;
- управление расчетными периодами и сменой тарифов;
- интеграция с ЮKassa;
- наличие тестового контура и качественной документации;
- скорость ответов и доступность команды поставщика.
Компании было важно выбрать не просто платежный сервис, а специализированное биллинговое решение, которое уже умеет управлять жизненным циклом подписки. Помимо LBX рассматривали альтернативное решение и вариант собственной разработки.
Решающей стала техническая готовность LBX к быстрой интеграции, а также отдельно сыграла роль работа команды. Еще до заключения договора LBX предоставили тестовый доступ к интерфейсу и API - решение принимали не по презентации, а протестировав продукт на практике. Команда провела подробную демонстрацию, изучила техническое задание, обращала внимание на неоднозначные места в сценариях и помогла разобраться в расценках и комиссиях при работе с ЮKassa. После старта работ для проекта создали отдельную группу в Telegram, оперативно отвечали на вопросы и помогали с API.
Результаты внедрения
Часть результата компания получила сразу: не пришлось разрабатывать и поддерживать собственное ядро подписочного биллинга. Это позволило быстрее запустить монетизацию и не отвлекать команду от основной функциональности - можно было сосредоточиться на AI-агентах, интеграциях и пользовательских сценариях, а не на повторной реализации стандартной финансовой инфраструктуры.
Разделение ответственности сделало и саму архитектуру понятнее: LadCraft отвечает за потребление ресурсов и кредиты, LBX - за подписку и платежный цикл. В дальнейшем такая схема упрощает:
При этом внутреннюю логику расчета кредитов можно менять и подключать новые AI-модели, не перестраивая всю систему подписок
Разделение ответственности сделало и саму архитектуру понятнее: LadCraft отвечает за потребление ресурсов и кредиты, LBX - за подписку и платежный цикл. В дальнейшем такая схема упрощает:
- изменение состава тарифов и добавление новых вариантов подписки;
- развитие командных и корпоративных тарифов;
- подключение оплаты для юридических лиц;
- развитие платного Marketplace;
- масштабирование продукта без переработки платежной части с нуля.
При этом внутреннюю логику расчета кредитов можно менять и подключать новые AI-модели, не перестраивая всю систему подписок
Совет: когда начинать думать о биллинге в AI-продукте
В AI-продукте биллинг связан не только с оплатой. Он влияет на архитектуру, сбор данных о потреблении, ограничения для пользователя и экономику каждого запроса. Если отложить вопрос, после запуска может выясниться, что продукт не собирает нужные данные, стоимость отдельных операций невозможно корректно рассчитать, а тарифы не покрывают реальную себестоимость.
Подробнее о том: Когда бизнесу нужна биллинговая система
При этом не стоит пытаться заранее реализовать все возможные сценарии. Достаточно до запуска определить базовые принципы: кто платит, за что именно, как считается потребление, что входит в подписку и что происходит при исчерпании лимита. А усложнять модель можно уже после появления реальной статистики.
Итог
В AI-продукте биллинг это часть архитектуры, а не просто модуль оплат поверх готового сервиса. Когда модель монетизации продумана заранее (подписка плюс кредиты), а ответственность разделена между продуктом и специализированной платформой, монетизацию удается запустить быстрее и без построения финансовой инфраструктуры своими силами.
Если вы сейчас проектируете оплату AI-продукта и в ней есть подписки, оплата за использование, кредиты или лимиты, имеет смысл заранее проверить, как эти сценарии лягут на биллинг - до того, как они превратятся в доработки на проде.
Если вы сейчас проектируете оплату AI-продукта и в ней есть подписки, оплата за использование, кредиты или лимиты, имеет смысл заранее проверить, как эти сценарии лягут на биллинг - до того, как они превратятся в доработки на проде.
Оставьте заявку, и мы разберем вашу модель монетизации, покажем, как связать подписки, расчетные периоды и учет потребления, и поможем запустить биллинг на ваших сценариях.
