Как спроектировать тарифные планы для продукта

Введение

Тарифы стоит обсуждать до публичной упаковки условий: лендинга, предзаписи, пилота, sales-презентации или pricing page.

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

По тарифам видно, какую ценность продукт предлагает оплачивать: доступ, объём, сделку, командную работу, контроль или сопровождение.

Начинать стоит с шести решений:

1. Кто пользуется продуктом, кто выбирает тариф и кто оплачивает?

2. Какой сценарий пользователь оплачивает?

3. Какая метрика ценности растёт вместе с пользой для клиента?

4. Какая единица тарификации лежит в основе тарифа?

5. В какой момент пользователю становится логично платить больше?

6. Выдерживает ли тариф экономика продукта?

В статье разберём проектирование тарифных планов для разных типов продуктов: подписочных сервисов, приложений, маркетплейсов, платформ, AI/API-продуктов, образовательных продуктов и командных инструментов.

Какие решения входят в тарифный план

В тарифе соединяются три слоя: упаковка ценности, способ оплаты и экономика обслуживания клиента.

При проектировании тарифа команда определяет цену, единицу оплаты, набор функций, лимиты, роли, уровень поддержки, условия апгрейда и правила скидок.

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

Кто пользуется, выбирает и оплачивает

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

В B2C эти роли часто совпадают. В B2B они могут быть разделены.

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

Например, в командном инструменте пользователь смотрит на удобство работы, администратор — на роли и доступы, руководитель — на пользу для команды, а финансовая сторона — на стоимость seats, скидки и условия оплаты.

Определите ценность и сценарий оплаты

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

Spotify показывает оплату за ситуацию потребления: индивидуальную, студенческую, семейную или парную. Airbnb — за доступ к предложению, доверенную транзакцию и инфраструктуру платформы. OpenAI API — за объём использования моделей и инструментов. Figma, Notion и Slack — за совместную работу, роли, доступы и управление командным процессом. [6, 8, 10, 14–16]

Цена, лимит или комиссия должны меняться там, где меняется ценность для пользователя.

Если у клиента растёт команда — логично брать за пользователей или роли. Если растёт объём транзакций — логична комиссия. Если растёт потребление модели — логична оплата за использование. Если растёт потребность в контроле — логичны business и enterprise-уровни.

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

Разведите метрику ценности и единицу тарификации

Метрика ценности показывает, где растёт польза для клиента. Единица тарификации показывает, за что клиент платит.

Они могут совпадать, но не обязаны совпадать.

В командном продукте ценность может расти от совместной работы, а оплата считаться за пользователя, роль или workspace. В API-продукте ценность связана с количеством полезных операций, а единица тарификации может считаться через запросы, токены, минуты или storage.

Хорошая единица тарификации соответствует нескольким критериям:

1. Понятна пользователю.

2. Связана с ценностью, которую он получает.

3. Растёт вместе с интенсивностью использования или размером сценария.

4. Учитывает себестоимость обслуживания.

5. Не мешает пользователю получать основную пользу от продукта.

6. Позволяет прогнозировать выручку.

7. Её сложно обходить или системно занижать.

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

Выберите принцип оплаты

Free / Pro / Business / Enterprise — один из возможных форматов тарифной сетки. В других продуктах принцип оплаты может строиться вокруг подписки, комиссии, оплаты за использование, бесплатного входа с платными ограничениями, семейного плана, пакета преимуществ, ролей в команде, условий для продавцов на маркетплейсе или индивидуального enterprise-контракта.

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

Netflix тарифицирует регулярный доступ. Airbnb использует комиссии и сервисные сборы. Stripe считает оплату от платёжной операции. OpenAI API считает объём использования. Перед таблицей тарифов нужно выбрать единицу тарификации: доступ, сделку, пользователя, роль, объём или пакет преимуществ. [7–10]

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

Spotify делит Premium на Individual, Student, Duo и Family. Netflix даёт пользователю возможность выбирать, менять и отменять подписку. OpenAI API использует usage-based оплату. Slack и Notion разделяют бесплатный и платные уровни для личного и командного использования. [6, 7, 10, 14, 16]

Распределите функции, лимиты и роли между тарифами

После выбора принципа оплаты нужно решить, какие функции, лимиты и роли входят в каждый тариф.

Платные тарифы могут добавлять объём, командность, контроль, профессиональные инструменты, поддержку или снижение операционного риска.

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

Спроектируйте бесплатный вход

Бесплатный план, trial или демо-доступ нужны, когда пользователь должен проверить пользу продукта до оплаты.

Такой вход должен довести пользователя до первого полезного результата. Весь продукт отдавать не нужно.

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

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

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

Спроектируйте причину апгрейда

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

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

Family-план в Spotify решает отдельную ситуацию: несколько людей в одном household-сценарии. В Slack переход на платные планы связан с командной продуктивностью, историей, внешней работой и уровнем управления. [6, 16]

Проверьте экономику тарифа

Тариф может быть понятен пользователю и не сходиться по экономике обслуживания.

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

Для AI/API-продукта особенно важны инфраструктура и переменная себестоимость. Для маркетплейса — модерация, платежи, поддержка и риск обхода платформы. Для образовательного продукта — стоимость контента, наставников, проверки работ, кураторов и удержания студента. Для enterprise-продукта — продажи, внедрение, безопасность, юридические согласования и customer success.

Перед запуском тарифа нужно проверить:

• себестоимость продукта;

• инфраструктуру;

• поддержку;

• комиссию платёжных систем;

• возвраты;

• скидки;

• стоимость контента;

• расходы на привлечение;

• ручной onboarding;

• партнёрские выплаты;

• модерацию;

• fraud / risk costs;

• нагрузку на customer success.

Экономику лучше смотреть по каждому плану отдельно.

В подписке риск — высокий churn и слабая частота использования.
Во freemium — большая бесплатная база без конверсии в оплату.
В маркетплейсе — уход участников в обход платформы.
В usage-based — непредсказуемый счёт и страх клиента пользоваться продуктом.
В bundle — разрыв между воспринимаемой ценностью и реальным использованием.
В enterprise — дорогие продажи и поддержка.

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

Задайте правила скидок

Скидки лучше проектировать как часть тарифной модели. Для них стоит заранее определить размер, срок действия, условия продления и влияние на маржу.

Без правил скидки быстро становятся частью ручных договорённостей. В B2B и enterprise-продажах это особенно важно: разные условия у похожих клиентов усложняют прогноз выручки и поддержку тарифов.

Если тарифы уже запущены

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

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

Изменение тарифов можно запускать поэтапно: сначала для новых клиентов, затем для отдельных когорт или новых контрактов. Такой подход помогает сравнить конверсию, ARPU, churn, обращения в поддержку и маржу до перевода текущей базы.

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

Как меняется тарифная модель в разных продуктах

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

AI/API-продукт

В AI/API-продукте единый фиксированный тариф плохо подходит клиентам с разным объёмом использования. Один клиент делает 100 запросов в месяц, другой — 10 миллионов. Поэтому базовая модель часто строится вокруг usage: токенов, запросов, минут, хранения или вызовов инструментов. Управленческий вопрос — контроль расходов для клиента и маржа по объёму. [10]

Маркетплейс

В маркетплейсе тарификация часто строится вокруг комиссии, service fee, продвижения или инструментов продавца. Комиссия работает лучше, когда пользователь связывает её с ценностью платформы: доверием, платежами, безопасностью сделки, арбитражем, потоком спроса или продвижением. [8]

Образовательный продукт

В образовательном продукте тариф зависит от обещанного результата. Подписка на каталог подходит при регулярном обучении. Для разовой задачи может подойти курс, интенсив, сертификат, сопровождение, проверка работ или карьерный пакет. [12]

Как использовать рыночные ориентиры

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

Spotify может делать семейный план, потому что музыка потребляется регулярно и несколькими людьми. OpenAI API может брать за usage, потому что ценность связана с объёмом использования. Airbnb может брать service fee, потому что платформа участвует в создании и защите сделки.

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

Пять опорных взглядов на тарификацию

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

Эти рамки не заменяют расчёт экономики и тестирование тарифов. Они помогают не сводить тарификацию только к сравнению цен с конкурентами. [1–5]

Финальная проверка тарифной сетки

1. Тарифы собраны по пользовательскому сценарию, а не по внутренней архитектуре

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

По внутренней архитектуре:

• 5 объектов;

• 20 сущностей;

• 3 внутренних модуля;

• 100 условных операций.

По пользовательскому сценарию:

• личное использование;

• команда;

• профессиональный сценарий;

• крупная организация;

• большой объём;

• больше видимости;

• отсутствие рекламы;

• больше контроля.

2. Подписка соответствует регулярному сценарию

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

3. Бесплатный тариф оставляет путь в оплату

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

4. Причина апгрейда понятна

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

5. Готовность платить проверена отдельно от интереса

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

Перед запуском тарифа важно проверять не только интерес, но и willingness to pay — готовность платить.

6. У тарифов есть владелец экономики

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

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

Как тестировать тарифы

Тарифы нельзя проектировать только в таблице.

До запуска стоит проверить:

1. Как пользователи описывают ценность продукта своими словами.

2. Какие альтернативы они используют сейчас.

3. Какой вариант упаковки они выбирают и почему.

4. Что кажется им честным ограничением, а что — искусственным.

5. Где возникает готовность платить.

6. Что становится причиной апгрейда.

7. Какие части тарифа вызывают вопросы.

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

Методы проверки:

После запуска важно смотреть не только оплату.

Метрики:

• конверсия в оплату;

• конверсия free → paid;

• средний чек;

• retention;

• churn;

• доля пользователей, упирающихся в лимиты;

• обращения в поддержку по billing;

• маржа по тарифам;

• доля скидок;

• окупаемость привлечения;

• expansion revenue;

• уход в обход платформы, если речь о маркетплейсе.

Если пользователи часто спрашивают, какой тариф выбрать, упаковка плохо объясняет ценность.

Шаблон проектирования тарифа

Чек-лист перед запуском тарифов

Перед публикацией pricing page стоит ответить на 15 вопросов:

1. Какой сегмент покупает каждый тариф?

2. Кто пользуется продуктом, кто выбирает тариф и кто оплачивает?

3. Какое позиционирование поддерживает тарифная сетка?

4. За счёт чего продукт конкурирует: цены, отличия или фокуса?

5. Какую экономическую ценность получает клиент?

6. Есть ли у продукта pricing power — способность удерживать цену без постоянных скидок?

7. Какая метрика ценности растёт вместе с пользой для клиента?

8. Какая единица тарификации лежит в основе тарифа?

9. Понятна ли разница между тарифами за 10–15 секунд?

10. Где пользователь получает первую ценность?

11. Что становится причиной апгрейда?

12. Покрывает ли каждый тариф cost to serve?

13. Какие скидки допустимы и на какой срок?

14. Что происходит с текущими клиентами при изменении тарифов?

15. Что команда будет измерять после запуска?

Если на эти вопросы нет ответа, тарифная сетка требует дополнительной проработки.

Источники и материалы

Книги и авторские рамки

1. Филип Котлер, Кевин Лейн Келлер — «Маркетинг менеджмент».

2. Майкл Портер — «Конкурентная стратегия: Методика анализа отраслей и конкурентов».

3. Герман Симон — «Признания мастера ценообразования. Как цена влияет на прибыль, выручку, долю рынка, объем продаж и выживание компании».

4. Томас Нэгл, Рид Холден — «Стратегия и тактика ценообразования».

5. Мадхаван Рамануджам, Георг Таке — «Монетизация инноваций. Как успешные компании создают продукт вокруг цены».

Официальные страницы продуктов

6. Spotify Premium — Individual, Student, Duo, Family.

7. Netflix Help Center — ежемесячная оплата, выбор, изменение и отмена плана.

8. Airbnb Help — сервисные сборы за услуги и впечатления.

9. Stripe Pricing — транзакционная модель оплаты.

10. OpenAI API Pricing — токены, минуты, storage, tool calls.

11. Super Duolingo — обучение без рекламы и поддержка бесплатного доступа.

12. Coursera Plus — доступ к 10 000+ курсов, проектов, специализаций и профессиональных сертификатов.

13. Amazon Prime Benefits — delivery, shopping, streaming, reading и другие преимущества.

14. Notion Pricing — Free, Plus, Business, Enterprise.

15. Figma Pricing / Figma plans — Professional, Organization, Enterprise.

16. Slack Pricing / Slack plans — Free, Pro, Business+, Enterprise+.