Модель ценообразования SaaS: больше денег, больше проблем

[cigulev]

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

[smiHT]

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

[datacompboy]

Где рассказ как именно это позволило переработать ваши тарифы, и чем они стали лучше?

[smiHT]

Вот это как раз касается нас:

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

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

[Yoschi]

Странно, что SAAS встречается прямо в заголовке. Мысль то более общая, зачем ограничивать свою читательскую аудиторию облаками?

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