Комментарии 18
Предположим, вы предлагаете всем пользователям все имеющиеся у вас возможности, а разница в цене и версиях определяется только «количеством пользователей».
Относится не только к SaaS продуктам, к моему сожалению.
Кстати, встречала уже совсем ужасную для заказчика модель ценообразования — оплата за функциональные модули (т.е. «чем сложнее тем дороже») + оплата за рабочие места. Ценник получался — застрелиться.
У нас не совсем «чистый Saas», однако, очень близко к этому. Так вот, только на тестирование модели ценообразования точно уйдет не меньше 6 месяцев. Понятно, что разработка и продажи при этом не останавливаются, отсюда и огромная сложность — продукт меняется, каналы продаж тоже, а ты при этом еще и должен тестировать тарифы.
А как происходит тестирование тарифов? не поделитесь секретом?
И как менять тарифы, чтобы при этом не вызвать обиду прежних юзеров, которые оплатили год вперед по другим (возможно, более выгодным) ценам?
Сразу скажу, что не претендую на истину (не надо кидать в меня камни), это всего лишь наш опыт для нашего продукта, причем, на стадии тестирования бизнес-модели, когда продукт готов и надо найти оптимальный способ его монетизации. Итак, мы в основном тестируем эластичность цена\спрос. Сначала пробовали нагнать публику через freemium. Убедились, что из него в платных не конвертятся. Отменили его. Платными стали всего лишь 2% из примерно 500 freemium юзеров. Создали страницу из 4-х платных тарифов с разным функционалом и ценами — Х, 2Х, 4Х, 12Х рублей. Чтобы увеличить средний чек, дали 35% скидку за оплату 6 месяцев и 50% — 12 месяцев (у наших друзей 63% всей выручки, это пожизненный тариф, который равен по цене месячному умножить на 12). Ежедневно анализируем метрики — по какому каналу привлечения юзеров какова цена привлечения посетителя сайта, регистирующегося, начинающего юзать продукт, платящего, и пр. В течение ближайшей недели опустим все тарифы в полтора раза и продолжим мерять аналогично. Затем повторим оба эксперимента изменив наполнение тарифов функционалом. И так далее каждые две недели. Пока не поймем, при каком функционале и каких ценах на разные тарифы у нас максимальна общая прибыль. Понятно, что мы исходим из того, что наш сервис ежегодно будет получать дай бог если 3-5% от общего числа потенциальных клиентов. Поэтому мы рискуем тестировать изменение тарифов вживую, приток новых клиентов всегда в разы больше существующих. Единственное правило — клиент, оплативший тариф до повышения его цены, должен иметь возможность всегда платить ту же самую цену, даже если для новых клиентов она вырастет. Это в общих чертах.
Вдогонку: свои решения про отмену Freemium мы принимали во многом под влиянием собранных отовсюду статей, которые описывали бы чужой опыт. Часть из них мы выложили ранее здесь же на Хабре в своем блоге. Кому интересно, можете посмотреть Freemium в MailChimp: год спустя и Freemium или Free Trial — какую бизнес модель выбрать при продаже софта?. Такое большое внимание уделяю Freemium в том числе и потому, что хотим вернуть его сильно видоизмененным обратно.
Есть еще хуже варианты, когда помимо цены за доп. модуль внутри него есть своя тарификация по числу чего либо — смс, к примеру.
В целом это нормально так как речь идет не о продукте, а о пакете продуктов:
Бывают случаи когда «модули» — это фактически партнерство с кем либо для расширения своего функционала.
Ценник в целом может быть конским, но… грусть, печаль, факт.
В целом это нормально так как речь идет не о продукте, а о пакете продуктов:
- оплата за рабочие места — оплата основного продукта
- оплата за «модули» — оплата побочных/комплиментарных продуктов (при этом это могут быть совершенно другие компании)
- оплата «морковок» внутри субпродукта или в продукте.
Бывают случаи когда «модули» — это фактически партнерство с кем либо для расширения своего функционала.
Ценник в целом может быть конским, но… грусть, печаль, факт.
Я вот не смог сходу определить степень сложности услуги. Любая услуга сложная, иначе клиент давно бы сам все сделал. Пришлось сходить по ссылке на оригинал статьи, там используется термин Complexity. Это можно перевести и как «комплексность», т.е. достаточность для получения результата. Например просто отправить сообщение — это еще не комлексность, а отправить сообщения, обработать возвраты и предоставить аналитику — уже достаточность для бизнес-целей. А вы как думаете?
Хорошо что в голосовании сделали галочки, ведь все пункты важны.
Зависимость от количества мест считаю странной, как правило, она прямо не влияет на затраты компании предоставляющей услугу.
Конечно бывает дорогостоящий транскодинг аудио-визуальных данных или сервисы с привлечением усилий живых людей для каждого рабочего места клиента, но это скорее исключение.
Все остальные факторы, разумеется влияют на стоимость в той или иной мере, но в итоге все-равно все остается как было уже тысячи лет — услуга стоит ровно столько, сколько за нее готовы платить.
Выбор идеальной цены для своего предложения — это уже вопросы эластичности и исследований, за день или месяц сложно решить.
Зависимость от количества мест считаю странной, как правило, она прямо не влияет на затраты компании предоставляющей услугу.
Конечно бывает дорогостоящий транскодинг аудио-визуальных данных или сервисы с привлечением усилий живых людей для каждого рабочего места клиента, но это скорее исключение.
Все остальные факторы, разумеется влияют на стоимость в той или иной мере, но в итоге все-равно все остается как было уже тысячи лет — услуга стоит ровно столько, сколько за нее готовы платить.
Выбор идеальной цены для своего предложения — это уже вопросы эластичности и исследований, за день или месяц сложно решить.
Проблема понятна, а делать-то с ней что? Как можно оценить сложность?
Метод не универсальный, но криво-косо работающий: по трудозатратам, измеряемым в человеко-часах?! Что скажете?
Скажу, что лучше, чем ничего (но непонятно, насколько лучше). Я не знаю правильного ответа, иначе бы не спрашивал.
Исходя из понимания термина Complexity я бы оценила насколько % решение покрывает бизнес процесс, насколько требуется изменить решение под бизнес-процесс заказчика и может быть — со сколькими системами в рамках бизнес процесса необходимо интегрироваться
А еще может быть — насколько сложную логику принятия решений должна выполнять сама система без оператора.
Возьму пример с потолка:
Система согласования договоров
Вариант 1.
усложним
Еще усложним
мм?
А еще может быть — насколько сложную логику принятия решений должна выполнять сама система без оператора.
Возьму пример с потолка:
Система согласования договоров
Вариант 1.
- Договор отправляется на согласование вручную по паралельному процессу
- Согласующие отписывают в почту
- Оператор подкрепляет письма и ставит галочки согласовано, сам примнимая решения на основе бумажек — кто главнее, и что делать, если кто-то против
усложним
- Договор отправляется на согласование вручную, но по паралельному и последовательному процессу, где в последовательном — люди принимающие ключевые решения
- Согласовывать можно уже в системе
- Но в статус «согласовано» оператор переводит сам, глядя на галочки
Еще усложним
- Система сама на основе правил определяет кого как на какой договор добавить. поддерживает согласование через интерфейс, через джаббер, через почту, через смс.
- Отправляет напоминания
- Раз в сутки строит разные отчеты и отправляет разным ролям.
- Потом выставляет счета на опату в ерп системы...
мм?
Ага, именно этот вопрос и идет следующим после прочтения статьи. И это не реально фундаментальный вопрос. Для всех других ..aaS сервисов есть отличные метрики по качеству (кроме обязательного количеству оплаченных аккаунтов). Самые знаменитые и показательные — количество процессорных ядер и Гб ОЗУ в IaaS. И только SaaS как сирота не имеет ничего аналогичного.
Хорошая статья, но примеров маловато. Мне с www.fabuza.ru не помогло, а надо.
Почему не помогло:
— Функционал внутри пока кроить не можем, а это нормальная и понятная история с разницей в цене тарифов.
— Хотим продавать подписку. Пока сделали волевое решение одного и того же функционала для корп и физиков по разной цене. Ну вот — так — наш шатл, что хотим, то и делаем.
Пока остановились на том, что будем продавать разовый тест за большие деньги — месячную подписку с коэф 1,25 без ограничений
количества запускаемых тестов.
Если есть мысли, вылком на подсказки!
Почему не помогло:
— Функционал внутри пока кроить не можем, а это нормальная и понятная история с разницей в цене тарифов.
— Хотим продавать подписку. Пока сделали волевое решение одного и того же функционала для корп и физиков по разной цене. Ну вот — так — наш шатл, что хотим, то и делаем.
Пока остановились на том, что будем продавать разовый тест за большие деньги — месячную подписку с коэф 1,25 без ограничений
количества запускаемых тестов.
Если есть мысли, вылком на подсказки!
Вообще процесс выяснения идеальных цен является достаточно простой математической задачей которую проделывает 1000 раз в секунду торговый робот-скальпер и т.п. торговые автоматы (точнее не они сами в боевом режиме, а они же, но в режиме «обучения» когда по сгенерированым параметрам прогоняют тест что бы понять насколько робот эффективен).
Рассматривать юзеров стоит как множество. У множества есть ряд показателей, к примеру количество «морковок».
Делим множество на Х частей в первый раз (как угодно) и назначаем линейку цен.
Через время Х когда мы статистически можем говорить о корректности данных по конверсии мы меняем границы ограничений.
Важно понимать, что границы тарифов (ограничений) — это то чем Вы управляете размером входящих в эти границы множеств.
Стоимость тарифа в данном множестве — это то, что влияет на выбор в пользу оплаты.
К примеру у нас склад по хранению морковок.
К нам приходят люди с разным числом морковок и мы знаем некое их распределение.
Мы понимаем, что людей у которых морковок менее 10000- 5%, менее 1000 — 20%, менее 100 — 50%
Рубим тарифами на хранение по этим границам и назначаем некую стоимость.
Через цикл итерации смотрим конверсию по каждой группе и…
И если видим что в более дорогом тарифе катастрафически конверсия низкая, то есть 2 варианта:
Мы смотрим кто в данном множестве состоит, к примеру диапазон от 1 до 10 тыс морковок слишком большой и юзеры по 1 тыс морковок сравнивают себя с владельцами 10 тыс и им печально платить дорого и по этой причине мы или разбиваем на доп тарифы диапазон или если понимаем, что 1-5 тыс морковок имеют более 50% людей, то можем сместить диапазон младшего тарифа до границы в 5 тыс. Т.е. люди кто не готовы были со своими 1-5 тыс морковок платить как владельца 10 тыс уже видят более низкую цену по которой они «пролезают» и конверсия в их группе растет.
Фактически имея в наличии цену тарифа + Х параметров ограничения мы получаем X-мерный график по каждому множеству распределенный по времени (что накладывает свои ограничения, так как и трафик на сайт меняется и функционал сервиса растет).
Если сервис имеет 2-3 параметра деления по тарифам, то тест будет идти не так долго.
Кстати если параметров много, то вот как раз имеет смысл делить продукт на основу и подпродукты со своими тарифными сетками. Так просто удобно и быстро считать.
Рассматривать юзеров стоит как множество. У множества есть ряд показателей, к примеру количество «морковок».
Делим множество на Х частей в первый раз (как угодно) и назначаем линейку цен.
Через время Х когда мы статистически можем говорить о корректности данных по конверсии мы меняем границы ограничений.
Важно понимать, что границы тарифов (ограничений) — это то чем Вы управляете размером входящих в эти границы множеств.
Стоимость тарифа в данном множестве — это то, что влияет на выбор в пользу оплаты.
К примеру у нас склад по хранению морковок.
К нам приходят люди с разным числом морковок и мы знаем некое их распределение.
Мы понимаем, что людей у которых морковок менее 10000- 5%, менее 1000 — 20%, менее 100 — 50%
Рубим тарифами на хранение по этим границам и назначаем некую стоимость.
Через цикл итерации смотрим конверсию по каждой группе и…
И если видим что в более дорогом тарифе катастрафически конверсия низкая, то есть 2 варианта:
Мы смотрим кто в данном множестве состоит, к примеру диапазон от 1 до 10 тыс морковок слишком большой и юзеры по 1 тыс морковок сравнивают себя с владельцами 10 тыс и им печально платить дорого и по этой причине мы или разбиваем на доп тарифы диапазон или если понимаем, что 1-5 тыс морковок имеют более 50% людей, то можем сместить диапазон младшего тарифа до границы в 5 тыс. Т.е. люди кто не готовы были со своими 1-5 тыс морковок платить как владельца 10 тыс уже видят более низкую цену по которой они «пролезают» и конверсия в их группе растет.
Фактически имея в наличии цену тарифа + Х параметров ограничения мы получаем X-мерный график по каждому множеству распределенный по времени (что накладывает свои ограничения, так как и трафик на сайт меняется и функционал сервиса растет).
Если сервис имеет 2-3 параметра деления по тарифам, то тест будет идти не так долго.
Кстати если параметров много, то вот как раз имеет смысл делить продукт на основу и подпродукты со своими тарифными сетками. Так просто удобно и быстро считать.
Статья посвящена очень важному вопросу — выбору политики ценообразования, которая помогала бы с каждого клиента получить именно такой доход, который он реально готов заплатить за ваш продукт
Чтоа? То есть вы хотите с каждого содрать тот максимум, который он готов заплатить? А вам не кажется, что это аморально?
Любая цена аморальна в таком случае.
Можно брать максимальную цену которую каждый готов заплатить и вкладывать это в развитие создавая новый рабочие места, оплачивая налоги и т.п.
Можно брать минимальную цену и не платить налоги, кидать клиентов и прочее.
Бедняк платит 1 копейку, миллионер 1 тыс евро. В чем аморальность?
Можно брать максимальную цену которую каждый готов заплатить и вкладывать это в развитие создавая новый рабочие места, оплачивая налоги и т.п.
Можно брать минимальную цену и не платить налоги, кидать клиентов и прочее.
Бедняк платит 1 копейку, миллионер 1 тыс евро. В чем аморальность?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Модель ценообразования для SaaS: больше денег – больше проблем