Agent-as-a-Service: как SaaS переходит на оплату за результат

В 2024–2025 годах крупные SaaS-вендоры один за другим объявили о том, что берут деньги не за доступ к софту, а за работу, которую выполняет ИИ-агент внутри него. Salesforce запустила Agentforce с тарификацией порядка 2 долларов за одно завершённое взаимодействие агента (цена указана на момент анонса, актуальную сверяйте на сайте вендора). Intercom продаёт бота Fin по цене за решённый обращение клиента, а не за оператора. Zendesk и ServiceNow в 2025 году добавили в прайс отдельную строку за «автоматические разрешения». Так оформилась модель, которую уже называют Agent-as-a-Service: вы платите не за лицензию, а за результат.

Что именно поменялось в модели продаж

Классический SaaS двадцать лет строился на подписке per-seat: сколько сотрудников заведено в систему, столько лицензий и оплачено. Метрика проста и предсказуема, но у неё есть неудобная для вендора черта — она не растёт вместе с ценностью продукта. Компания на 50 человек платит за 50 мест независимо от того, обрабатывает система десять заявок в день или десять тысяч.

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

• Оплата за действие (per-action) — списывается за каждый запуск агента: ответ, обновление записи в CRM, отправленное письмо.
• Оплата за результат (outcome-based) — деньги берут только за успешно закрытую задачу: решённое обращение, назначенную встречу, оформленный возврат. Неудачные попытки не тарифицируются.

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

Подписка продавала возможность. Agent-as-a-Service продаёт закрытую задачу — и вместе с ней перекладывает на вендора риск того, что агент задачу не закроет.

Сравнение с привычными моделями

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

Главная скрытая проблема правой колонки — определение успеха. Что считать «решённым обращением»: клиент не написал повторно в течение суток или он подтвердил, что вопрос закрыт? От формулировки в договоре напрямую зависит ваш счёт.

Откуда берётся такой агент

Под капотом Agent-as-a-Service почти всегда лежит связка большой языковой модели с доступом к вашим данным и инструментам. Агент^* получает запрос, обращается к базе знаний через RAG^**, вызывает API вашей CRM или тикет-системы и формирует ответ или действие. Вендор в такой схеме отвечает за оркестрацию: как агент решает, что делать, когда эскалировать на человека и как логировать каждый шаг для биллинга.

^* Агент — программа на базе языковой модели, которая не просто отвечает текстом, а выполняет цепочку действий: читает данные, вызывает внешние сервисы, принимает решения в рамках заданных правил.

^** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные документы из вашей базы, чтобы отвечать на основе актуальных данных, а не только на том, что было в обучении.

Кому это пригодится, а кому нет

Модель выигрышна не для всех. Она хорошо ложится на процессы с большим объёмом однотипных задач и понятным критерием завершения.

Пригодится

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

Скорее навредит

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

На что смотреть в договоре

Переход на оплату за результат меняет структуру риска, поэтому проверьте несколько пунктов до подписания.

1. Точное определение «успешной задачи» и кто её фиксирует.
2. Тарифицируется ли эскалация на человека — во многих схемах передача оператору не считается решением, но и денег не стоит, а в некоторых стоит.
3. Есть ли верхний потолок счёта на месяц, чтобы всплеск нагрузки не обернулся неожиданной суммой.
4. Доступ к логам действий агента для самостоятельной сверки биллинга.
5. Что происходит при массовой ошибке агента — есть ли перерасчёт.

Куда это движется

Пока рынок не устоялся, и единого стандарта тарификации нет. Часть вендоров оставляет гибрид: базовая подписка плюс оплата за действия сверх лимита. Аналитики называют outcome-based ценообразование одним из главных сдвигов в SaaS, но осторожно — предсказуемость счёта для покупателя здесь падает, а определение результата остаётся зоной конфликта. Прежде чем менять модель на весь контур, разумнее запустить пилот на одном процессе и сверить реальный счёт с прежней подпиской за тот же период.