AI-монетизація: чому ціна стала частиною UX

Уявімо, що ви працюєте над AI-функцією для SaaS-продукту. Користувач вводить запит, отримує результат, але він не зовсім відповідає очікуванням. Людина змінює промпт, запускає генерацію ще раз, потім ще раз. На четвертій спробі результат нарешті вдалий.

З погляду продуктового дизайну ми бачимо проблему: користувачу знадобилося чотири спроби, щоб виконати одне завдання. З погляду бізнесу: компанія заплатила за чотири генерації, хоча цінність створила лише одна. А тепер уявімо, що за кожну спробу користувач також витрачає кредити зі своєї підписки. Виходить, він платить не тільки за результат, але й за невдалі спроби системи.

То хто має оплачувати ці спроби? Чи повинен користувач знати вартість генерації до її запуску? Як зробити так, щоб компанія не втрачала гроші на надмірному використанні AI, але водночас не змушувала людей боятися кожного натискання кнопки?

Мені здається, саме тут починається одна з найцікавіших задач сучасного продуктового дизайну. AI-функції змінюють економіку SaaS: кожен запит, генерація чи агентний процес можуть створювати додаткові витрати. Традиційної підписки не завжди достатньо, тому компанії експериментують із кредитами, лімітами, оплатою за використання та результат. Але кожна з цих моделей формує поведінку людей: від частоти використання до готовності платити й довіряти продукту.

“

AI-монетизація є не просто способом виставити рахунок. Це система правил, яка формує поведінку користувачів і безпосередньо впливає на економіку продукту.

Тому дизайнери мають брати участь у її створенні, а не лише оформлювати готову pricing page.

AI змінив не лише продукти, а й ціну кожної взаємодії

У традиційному SaaS додаткова дія користувача нерідко має невелику граничну собівартість. В AI-продуктах ситуація інакша: генерації, великі контексти, складні моделі й автономні агентні процеси споживають ресурси. За даними ICONIQ State of AI 2026, середня валова маржа AI-продуктів у дослідженій вибірці за 2025 рік становила 45%, а прогноз на 2026-й становить 53%. Для традиційного SaaS Bessemer наводить орієнтир близько 80–90%. Це різні вибірки та бізнес-моделі, тому порівняння показує масштаб виклику, а не універсальний закон.

І навіть падіння ціни токенів не гарантує, що функція стане дешевшою. Дешевші моделі відкривають можливості для довших запитів, більшої кількості перевірок і складніших агентних ланцюжків. Компанії потрібно рахувати не лише ціну одного API-виклику, а вартість виконаного завдання. Саме на неї впливають і продуктові рішення: чи можна уточнити результат без повної перегенерації, чи запускається дорога модель за замовчуванням, чи знає користувач, що спричиняє додаткові витрати.

За що користувач насправді готовий платити?

Перше запитання, яке я б поставила команді перед створенням кредитного балансу: яку одиницю цінності купує людина? Токени й API-виклики є зручними одиницями обліку інфраструктури. Але користувач не приходить до продукту заради 100 000 токенів. Він хоче створити презентацію, знайти помилку в коді, обробити документи, вирішити звернення клієнта чи запустити робочий процес.

Ця різниця важлива, тому що обрана одиниця оплати впливає на продуктову поведінку. Якщо людина платить за генерації, кожна повторна спроба зменшує її баланс. Якщо вона платить за успішний результат, інтереси компанії та клієнта потенційно стають ближчими: продукту вигідніше допомогти завершити завдання з меншою кількістю спроб. Наприклад, Intercom Fin використовує оплату за визначене вирішене звернення, а Salesforce Agentforce пропонує облік окремих агентних дій через Flex Credits.

Втім, outcome-based pricing підходить не всім. «Згенеровано документ» ще не означає, що документ якісний; «виконано агентну дію» теж не означає, що людина отримала бажаний результат. Тому дизайнеру разом із продуктом, інженерією та бізнесом варто визначити, що є завершенням сценарію, як вимірюється якість та які помилки система повинна обробляти за власний рахунок.

Психологія кредитів: коли користувач перестає розуміти ціну

Кредити здаються простим рішенням. Компанія може продавати один пакет для різних AI-функцій, хоча реальна собівартість генерації зображення, аналізу документа й агентної операції суттєво відрізняється. Але що означають 2 000 кредитів для користувача? Це багато чи мало? Скільки конкретних завдань можна виконати? Чи залежить ціна від вибраної моделі та кількості спроб?

Це питання не лише інформаційної архітектури, а й поведінкової економіки. Дослідження pain of paying, mental accounting та схильності до фіксованих тарифів допомагають зрозуміти, чому люди не люблять невизначені рахунки. В експериментах Raghubir і Srivastava (2008) менш прозорі способи оплати були пов'язані з більшими витратами, а надання зрозумілої інформації про вартість послаблювало цей ефект. Це дослідження не про AI-кредити безпосередньо, але його механізм корисний для осмислення продуктового UX.

Коли дія коштує «150 кредитів», користувач може не відчувати її реальної ціни. Коли ми показуємо «150 кредитів ≈ $1.50», залишок після операції та приблизну кількість доступних результатів, людина отримує більше контролю. Водночас не потрібно показувати нав'язливе підтвердження перед кожною дешевою дією: надмірна увага до платежів створює тертя. Важливо узгодити рівень прозорості з ризиком витрат.

“

Кредити можуть спростити оплату, але не повинні приховувати її реальну вартість.

Як проєктувати монетизацію, яка не руйнує досвід

Тут робота дизайнера починається не з pricing page, а з користувацького сценарію. Вартість має бути зрозумілою в тому місці, де виникає рішення щось запустити, продовжити або зупинити. Для дорогої генерації чи агентного процесу корисно показати оцінку до дії, бажано в одиницях, які люди розуміють: грошах, кредитах і приблизних результатах. Якщо точну ціну неможливо визначити, чесний діапазон із максимальним бюджетом кращий за вигадану точність.

Після виконання продукт має допомогти зрозуміти фактичну вартість. Особливо якщо вона відрізняється від оцінки: наприклад, агент витратив додаткові ресурси на перевірку, а генерація потребувала більшої моделі. Це формує передбачуваність використання, а не змушує людину здогадуватися, чому баланс змінився.

Не менш важливе розрізнення між алертом і лімітом. Попередження на 80% бюджету не означає, що витрати гарантовано зупиняться на 100%. Користувачеві потрібні зрозумілі режими: просто сповістити, запитати дозвіл на перевищення, автоматично перейти на дешевший режим або зупинити дорогі операції. І система повинна чітко пояснювати, які правила діють саме зараз.

А що трапляється, коли баланс стає нульовим? Поганий сценарій: перервати процес посеред складного завдання і показати помилку. Кращий: попередити завчасно, дати зберегти прогрес, пояснити можливості безкоштовного чи дешевшого режиму та запропонувати поповнення без примусу. Якщо користувач уже опублікував результат, варто окремо пояснити, чи продовжить він працювати після вичерпання кредитів.

У B2B-продуктах важливо пам'ятати, що платник і користувач часто є різними людьми. Працівник хоче швидко завершити завдання, а адміністратор хоче знати, скільки команда витрачає, хто споживає найбільше, чи можна встановити бюджет та як погоджувати додаткові ресурси. Отже, продукту потрібні не просто індикатор балансу і кнопка Upgrade, а окремі сценарії контролю, звітності та дозволів.

Ці принципи можна перевіряти ще на рівні прототипу. Наприклад, дати користувачам завдання оцінити вартість трьох генерацій, встановити бюджет на місяць і розібратися, що станеться після досягнення ліміту. Якщо людина не може відповісти без підказки, навіть візуально чистий billing UI ще не вирішив проблему.

Як дизайн може зменшувати AI-витрати

Найцікавіше, на мою думку, починається там, де ми перестаємо розглядати монетизацію лише як екран оплати. Якщо користувач знову й знову генерує весь документ заради зміни одного абзацу, це одночасно проблема usability, якості результату та собівартості. Можливість точкового редагування, збереження версій, попереднього уточнення вимог або використання дешевшої моделі для простих операцій здатна змінити економіку сценарію.

Важливо не плутати вартість виклику з вартістю успіху. Умовно, Model A коштує $0.20 за спробу й успішно завершує 80% незалежних спроб. Тоді очікувана вартість успішного результату становить $0.20 / 0.80 = $0.25. Model B дешевша: $0.15 за спробу, але успішність становить лише 50%, тому очікувана вартість успіху становить $0.15 / 0.50 = $0.30. Ми знизили вартість окремого виклику на 25%, але отримали дорожчий успішний результат. Це спрощена модель із припущенням про незалежність спроб і незмінну ймовірність успіху; реальну систему потрібно вимірювати на фактичних сценаріях.

Саме тому я б запропонувала дизайн-командам звертати увагу не лише на кількість генерацій або рівень використання AI, а й на частку повторних спроб, час до корисного результату, редагування вихідних даних і витрати на успішно виконане завдання. Це метрики, де дизайн та unit economics перестають існувати окремо.

Як перевірити, що монетизація працює

Навіть якщо користувачі купують кредити, це ще не означає, що ми створили хорошу систему. Висока частка поповнень може свідчити про сильний попит, але також про те, що базового тарифу критично не вистачає. Велика кількість AI-викликів може означати залученість або нескінченні спроби виправити результат. А зростання доходу від перевитрат не обов'язково сумісне з довгостроковою довірою.

Тому я б дивилася на кілька груп показників разом:

Окремо варто аналізувати сегменти. Користувач із 20 запитами на місяць і людина, яка запускає сотні агентних операцій, можуть мати однаковий тариф і зовсім різну собівартість. Ілюстративний приклад: за ціни $0.13 за завдання 20 завдань коштують $2.60, 400 обходяться в $52, а 2 000 в $260 лише змінних AI-витрат. Це не реальні тарифи певної компанії, а пояснення того, чому середній показник може приховувати ризик.

Перш ніж масштабувати модель, я б протестувала кілька типових сценаріїв: чи розуміє людина, за що платить; чи може передбачити витрати; чи знає, як зупинити перевищення бюджету; чи вважає справедливими списання за невдалі спроби. Кількісні дані про конверсію потрібно доповнювати цими поведінковими та якісними сигналами. І, наскільки можливо, окремо перевіряти вплив зміни ціни й зміни інтерфейсу, бо інакше буде важко зрозуміти причину результату.

Яку модель монетизації обрати?

Єдиної правильної відповіді немає. Модель повинна враховувати і спосіб створення цінності, і передбачуваність собівартості, і те, наскільки легко клієнту оцінити власне використання. Growth Unhinged за результатами дослідження понад 240 компаній повідомляв, що частка гібридних моделей зросла з 27% до 41% за рік до 2025-го. Це важлива тенденція, але не причина автоматично обирати гібрид для кожного продукту.

Як практичний старт для багатьох SaaS-функцій можна розглянути невеликий включений обсяг AI-використання, прозорі правила його списання та чіткий шлях до додаткової оплати. Але цю гіпотезу потрібно перевіряти на реальних сегментах, готовності платити й витратах, а не сприймати як універсальний шаблон.

Що це змінює для продуктового дизайнера

Я не думаю, що дизайнер має самостійно визначати ціну за токен або відповідати за всю фінансову модель. Але він має бути присутнім у розмові значно раніше, ніж з'являється завдання «намалювати баланс кредитів». Саме дизайнер може поставити питання, які поєднають поведінку людей з економікою продукту: що користувач називає результатом, як він сприймає витрати, чому повторює генерації, що відбувається на ліміті та чи є оплата зрозумілою без додаткових пояснень.

У AI-продуктах проєктування взаємодії дедалі частіше означає проєктування умов, за яких виникає і оплачується цінність. Те, як ми організовуємо сценарій, впливає на успішність результату, кількість викликів моделі, маржу, лояльність і готовність користувача продовжувати роботу.

“

Хороший AI-дизайн оптимізує не кількість генерацій, а цінність кожного успішного результату, для користувача і для бізнесу.

Можливо, наступну розмову про AI-функцію варто починати не з того, яку модель підключити або скільки кредитів видати на місяць. А з простішого питання: яку роботу ми допомагаємо людині виконати, скільки це коштує і чому вона буде готова за це платити? Лише після цього є сенс вирішувати, чи потрібні нам кредити взагалі.