Самые выгодные тарифы
Суть проекта
Stage помогает облачным сервисам вырабатывать и поддерживать оптимальную систему тарифных планов — выгодную для себя, но приемлемую для пользователей.
Для этого первым делом надо добавить в код своего сервиса вызовы API Stage — свой вызов в каждый модуль, который отвечает за реализацию какого-либо из свойств сервиса.
После этого продуктовики и маркетологи могут составлять и выкатывать в бой любые варианты линеек тарифных планов без участия программистов — используя лишь панель управления Stage.
На базовом уровне мы можем объявить любой из свойств платным и приписать его к определённому тарифу — после этого им может пользоваться только подписчик этого тарифа. Если на ссылку (кнопку) свойства нажмёт кто-то другой — платформа покажет пользователю приглашение перейти на один из тарифов, включающих это свойство.
Приписывание свойства к тарифу может производиться не только по двоичному принципу «есть/нет». Можно при этом задавать ещё количество единиц (максимальное количество групп, проектов, полей и т. д.), имеющих отношение к свойству, или количество вызовов самого свойства за период (максимальное количество преобразований, импортов и т. д.).
Платформа позволяет создавать не только линейки тарифов, но и систему дополнительных модулей (add-ons) и пакетов (bundles):
- «Дополнительный модуль» — это когда свойство не входит ни в тариф, но его можно докупить к нему за отдельные деньги.
- «Пакет» — это когда набор из нескольких дополнительных модулей вместе можно купить дешевле, чем каждый по отдельности. Тут можно задавать либо конкретные цены пакетов, либо размер скидок при покупке нескольких модулей.
Аналогичным образом создаются и пробные (trial) тарифы. С технической точки зрения это просто возможность указать в панели управления тарифами, какое количество дней конкретное свойство можно использовать в данном тарифе, после чего оно автоматически отключится.
Пробная версия — это набор из нескольких свойств, которые работают всегда, или набор большего количества свойств, которые работают в течение только короткого времени. Или любое сочетание этих крайностей
Функциональность платформы на этапе составления тарифных линеек не заканчивается. Критерием истины, как известно, является только практика. Поэтому все наши предположения, что «такая конфигурация тарифов окажется для нас более выгодна» или «это свойство точно будет востребованным в этом тарифе» — нуждается в проверке в боевых условиях.
На специальном дашборде мы можем следить за тем, насколько то или иное свойство востребовано пользователями в каждом тарифе, в которое оно входит. И это даёт нам количественные обоснования для дальнейшего перемещения свойств между тарифами или изменения лимитов на его использование в тарифе.
Кроме того, мы можем выкатить в бой даже несколько альтернативных тарифных планов — и посмотреть в реальных условиях, какой из них приносит нам больше денег — чтобы оставить самый выгодный для нас. Учитывая при этом как и конверсию из охвата в переход на тариф, так и абсолютное количество заработанных на нём денег.
У Stage на самом деле реально пока работает только двоичное («есть/нет») приписывание свойств к тарифным линейкам. Всё остальное помечено как «скоро будет». Несмотря на это, они сумели поднять на свою платформу первые 5.14 миллионов долларов инвестиций. То есть инвесторы рассчитывают, что такая платформа должна «зайти» разработчикам облачных сервисов.
Что интересного
В последнее время среди облачных сервисов начала расти популярность такого метода тарификации как «Usage-based pricing» — оплата за реальное использование ресурсов, противопоставляемая модели подписки с фиксированной оплатой.
Модель оплаты за реальное использование более приемлема для пользователей (так как позволяет платить меньше, когда потребность в сервисе уменьшается), но может оказаться даже более выгодна для разработчиков (так как позволяет больше зарабатывать на активных клиентах).
В реальной же жизни очень часто используется некоторое сочетания обеих моделей, при которой тариф может иметь и набор входящих в него свойств, и абонентскую плату (которая может включать в себя определенное количество использований) и соответствующую этому тарифу стоимость на дополнительное количество использований. Типа «99 долларов в месяц, в которые входит 1,000 вызовов ресурса, каждый дополнительный вызов сверх этого обойдётся в 10 центов» или «199 долларов, в которые входит 2,000 вызовов ресурса, каждый дополнительный вызов сверх этого обойдётся в 5 центов».
Если же речь идёт о B2B-продуктах, то такие тарифы могут составляться индивидуально под каждого клиента, исходя из его планирумых нагрузок и нашего желания или нежелания его при этом потерять
Другими словами, система тарификации облачных сервисов становится геморроем, плавно переходящим в кошмар:
- Во-первых, нужно ухитриться так составить тарифные линейки, чтобы и для пользователя это выглядело привлекательно, и мы бы на этом больше заработали.
- Во-вторых, тестируя или выкатывая клиентам тестовые или индивидуальные тарифы, нужно учитывать параметры их индивидуальных планов при выставлении очередных счетов.
- В-третьих, нужно иметь возможность постоянно отслеживать сочетание выгодность/приемлемость и иметь возможность «переобуваться» (менять тарифы) буквально на ходу — не перепахивая каждый раз исходный код платформы и не отвлекая на это программистов.
Там, где появляется геморрой — там возникает рынок
Соответственно, начали появляться стартапы, которые с разных сторон подходят к решению задачи гибкой и эффективной тарификации облачных сервисов, которая может реализовываться на уровне продуктовиков, а не программистов. Несколько стартапов по подобной теме встречалось даже тут среди обзоров:
- Subscript (мой обзор) — платформа для финансового анализа облачных B2B-сервисов, работающих по модели подписки. Подняли 3.75 миллионов долларов инвестиций.
- Subskribe (мой обзор) — платформы для создания индивидуальных тарифов и последующего биллинга для B2B-клиентов. Подняли 18.4 миллионов долларов.
- Metronome (мой обзор) — платформа для реализации модели оплаты за использованные ресурсы. Подняли 35 миллионов долларов.
Сегодняшний стартап — из того же тренда. Правда он пока фокусируется на создании линеек фиксированных тарифов. Но, во-первых, широкая линейка фиксированных тарифов — это по сути та же оплата за использованные ресурсы, но «нарезанная кусками»
Во-вторых, я уверен, что рано или поздно возможности динамической тарификации у них просто обязана будет появиться.
Куда бежать
Общее направление движения — к платформам для гибкой тарификации облачных сервисов.
Вариантов нет. Тут либо самим надо начать использовать одну из подобных платформ (если у нас есть свой облачный сервис), либо начать разрабатывать подобные платформы для других.
Хотя есть ещё один вариант — начать разрабатывать подобную платформы в качестве внутреннего продукта для себя, чтобы потом начать продавать её в качестве отдельностоящего продукта для других
Сегодняшний стартап делает платформу для создания линеек фиксированных тарифов. У такого подхода есть свой психологический плюс — с фиксированными тарифами клиенты могут быть уверены, что они ни при каких условиях не заплатят сервису больше, чем планировали (на что подписались). Что бы не случилось — например, типа нашествия ботов, криворукого программиста или сотрудника, нажавшего не на ту кнопку.
С другой стороны, широкая линейка разнообразных тарифов, как я отмечал выше — по сути близка по сути к модели оплаты за использованные ресурсы. Но поддержка «широкой линейки разнообразных тарифов» практически невозможна без внедрения технологической платформы для создания, тестирования и модификации таких тарифов — построенной, например, по образу и подобию сегодняшней платформы.
О компании
Stage
- Сайт: heystage.com
- Последний раунд: $5.14M, 07.06.2022
- Всего инвестиций: $5.14M, раундов: 1