Комментарии 104
А почему бы пользователя просто не считать как использованный ресурс?
Об этом написано во втором абзаце.
Кстати, забыл написать тоже самое про клиентов. Бывают клиенты которые активно пользуются системой каждый день, а бывают которые раз в месяц какую-нибудь маленькую задачку поставят или о баге сообщат… и им обоим придется платить одинаковые деньги.
Кстати, забыл написать тоже самое про клиентов. Бывают клиенты которые активно пользуются системой каждый день, а бывают которые раз в месяц какую-нибудь маленькую задачку поставят или о баге сообщат… и им обоим придется платить одинаковые деньги.
Мы в своём будущем SaaS планируем делать оплату за администраторов, которые в данный момент находятся онлайн. Т.е в самой системе может быть зарегистрировано бесконечно много администраторов, однако администраторов, которые могут совершать какие-то действия в системе, может быть столько, за скольких заплатил заказчик.
Оплата за использованные ресурсы не уместна. Приложение работает, ожидает клиента, сервера, техподдержка также в ожидании, как иначе покрывать эти расходы?
Согласен, SaaS это все-таки плата за предоставление софта как услуг. А время, которое я не использую, не есть потребленная мною услуга. Хотя, если вспомнить почасовой интернет, и он существовал. Но он ушел. Так уйдет и SaaS за время.
> предлагается платить по такой же схеме — за пользователя в месяц. Это понять еще более сложно...
(просто денег очень хочется)
(просто денег очень хочется)
Мне кажется осуждать кого-то за то что он хочет денег это немного лукавство.
Другой вопрос что на этом можно зарабатывать гораздо больше, если сделать ценообразование более прозрачным и справедливым.
Другой вопрос что на этом можно зарабатывать гораздо больше, если сделать ценообразование более прозрачным и справедливым.
а вы бесплатно работаете что-ли? =) цель любого бизнеса — деньги
Ценообразование важная и сложная штука и главная задача любой компании — найти компромисс между удовлетворенностью клиентов и прибылью для компании.
На тарифы влияют много факторов, от целевой аудитории и страны, в которой люди привыкли платить 500 рублей в месяц за «какую-нить услугу в интырнэте» до этапа развития самой компании и цен конкурентов.
Если SaaS-сервис предлагает платить за пользователей, значит это не просто так придумано
Если сервисом пользуется программист, который любит всё настраивать и разбираться в мелочах, то ему конечно удобен конструктор тарифов
Если сервисом пользуется какой-нибудь бренд-менеджер FMCG-компании, то ему вообще плевать на цену и на функционал, и конструкторы его только отпугнут… есть проблема, сервис ее решает… чек не важен
Итог такой… не стоит считать чужие деньги и узко мыслить… не нравится — ищите аналоги… аналогов нет — не лезьте в ценообразование чужой компании =)
Ценообразование важная и сложная штука и главная задача любой компании — найти компромисс между удовлетворенностью клиентов и прибылью для компании.
На тарифы влияют много факторов, от целевой аудитории и страны, в которой люди привыкли платить 500 рублей в месяц за «какую-нить услугу в интырнэте» до этапа развития самой компании и цен конкурентов.
Если SaaS-сервис предлагает платить за пользователей, значит это не просто так придумано
Если сервисом пользуется программист, который любит всё настраивать и разбираться в мелочах, то ему конечно удобен конструктор тарифов
Если сервисом пользуется какой-нибудь бренд-менеджер FMCG-компании, то ему вообще плевать на цену и на функционал, и конструкторы его только отпугнут… есть проблема, сервис ее решает… чек не важен
Итог такой… не стоит считать чужие деньги и узко мыслить… не нравится — ищите аналоги… аналогов нет — не лезьте в ценообразование чужой компании =)
Полностью поддерживаю, мой опыт использования SaaS МоеДело закончился когда они внезапно решили передумать и прикрыли базовый тарифный план (ИП без сотрудников и без отправки отчетности), который изначально позиционировали как бесплатно и навсегда (или типо того). При этом прислали слезное письмо о том почему они так сделали, в итоге у них для ИП без сотрудников остался один единственный тарифный план стоимостью 3800 в год включая сдачу отчетности через интернет, но мне он не подходит тк для сдачи я использую другой велосипед, а за половину 3800 я могу и 1с упрощенку купить. Короче полное непонимание как нужно вести дела, чтомешало добавить тариф без отчетности я не понимаю.
К слову МоеДело все же честнее оказались, рассматривал возможность перейти на Эльбу, мне тут представители компании в комментариях сказали что отчетность можно бесплатно сдавать, но потом я внимательно прочитал вот это www.e-kontur.ru/reports/PFR-FSS-Internet и просто выпал в осадок, нужно подключать другой тарифный план у партнера который стоит 4000рублей, при том что на странице Цены об этом нет ни слова.
В общем после таких ситуаций я не при каких обстоятельствах полагаться на сервисы не буду, и мое решение выбрать для сдачи отчетности другую компанию (сбис++ 900за этот год для питера) полностью себя оправдало.
К слову МоеДело все же честнее оказались, рассматривал возможность перейти на Эльбу, мне тут представители компании в комментариях сказали что отчетность можно бесплатно сдавать, но потом я внимательно прочитал вот это www.e-kontur.ru/reports/PFR-FSS-Internet и просто выпал в осадок, нужно подключать другой тарифный план у партнера который стоит 4000рублей, при том что на странице Цены об этом нет ни слова.
В общем после таких ситуаций я не при каких обстоятельствах полагаться на сервисы не буду, и мое решение выбрать для сдачи отчетности другую компанию (сбис++ 900за этот год для питера) полностью себя оправдало.
Что такое сбис++?
Аналогичная ситуация. Пока пользуюсь Эльбой для сдачи в ФНС, но продолжаю искать удобый (и дешевый) вариант сдачи и в ПФР, ФСС. Спасибо за наводку на сбис++
Да, у нас есть такая проблема, вскоре она решится, т. е. всё должно стать прозрачнее. Но возможность бесплатно сдавать отчётность в ПФР есть, но только в некоторых регионах.
Ну тут еще надо не забывать о том, что на каждого пользователя необходимо выделить ресурсы, техподдержку, и спроектировать масштабируемую систему, чтобы она могла выдержить столько юзеров. Вы же хотите пользоваться услугой в любое время, а не заранее за пару месяцев извещать о том, что будете использовать.
Ну а насчет standalone, то тут вероятно просто хотят окупиться.
Ну а насчет standalone, то тут вероятно просто хотят окупиться.
Насчет обеспечения безотказности вы правы, но так я и говорю что клиенту за его деньги должен продаваться как бы изолированный кусок инфраструктуры. А уж сколько он пользователей туда запихнет это уже его проблемы. Если пользователей станет столько что ресурсы закончатся — докупит еще.
Много где так работает. На том же basecamp например. Да и на том же мегаплане лицензий нужно столько, сколько будет использоваться одновременно.
К Basecamp вопросов нет, там нету ограничений по пользователям на всех тарифах. У Мегаплана речь идет не об одновременном использовании, а о количестве одновременно зарегистрированных пользователей, это не одно и то же все таки.
www.megaplan.ru/megaplan/order/
«Т.е. лицензия — это право доступа к системе и вам нужно столько лицензий, сколько человек в вашей компании будут одновременно работать»
«Т.е. лицензия — это право доступа к системе и вам нужно столько лицензий, сколько человек в вашей компании будут одновременно работать»
Выходит, что хочется платить за человекосекунду активного использования сервисом. Приближаемся к обычному биллингу :)
Я скорее говорю про вот такое.
Допустим есть компания из 50 человек, которая обслуживает в среднем одновременно несколько клиентов, так что общее количество клиентских пользователей ~200. И эта компания использует систему, которая стоит 10$ за пользователя в месяц
Возможно, эта компания пользуется сервисом, изначально ориентированным на другие компании.
Все тарифы обычно проектируются исходя из типовых вариантов использования сервиса, и если ваша компания тратит неоправданно много, возможно, изначально такой способ использования сервиса не был предусмотрен (например, никто не ожидал что компании будут подключать одновременно несколько клиентов) и вам стоит обсудить с поставщиком услуги индивидуальный тариф.
Все эти «типовые варианты» это как набор методов лечения на основе средней температуры по больнице. Индивидуальные тарифы это по сути и есть то о чем я говорю, но ни разу не видел реальных случаев.
Попробуйте написать в техподдержку и обсудить.
Обычно возможность обсуждения индивидуальных тарифов не афишируется на сайте, потому что люди покупают по стандартным ценам и платят больше, а если написать что можно обсудить — никто не будет покупать по стандартным ценам, все будут обсуждать.
Но при этом практически всегда есть возможность обсудить с менеджерами варианты скидок или индивидуальных тарифов в зависимости от вашей конкретной ситуации, просто ее не афишируют чтобы получить побольше прибыли. Но и совсем отказываться от клиента — тоже не выгодно.
Это как в магазинах той же самой одежды — в любом магазине, пообщавшись с менеджером, можно получить скидку 10-20% на вещь, не имея ни дисконтки, ничего. Особенно в дорогих магазинах. Но этим мало кто пользуется :)
Обычно возможность обсуждения индивидуальных тарифов не афишируется на сайте, потому что люди покупают по стандартным ценам и платят больше, а если написать что можно обсудить — никто не будет покупать по стандартным ценам, все будут обсуждать.
Но при этом практически всегда есть возможность обсудить с менеджерами варианты скидок или индивидуальных тарифов в зависимости от вашей конкретной ситуации, просто ее не афишируют чтобы получить побольше прибыли. Но и совсем отказываться от клиента — тоже не выгодно.
Это как в магазинах той же самой одежды — в любом магазине, пообщавшись с менеджером, можно получить скидку 10-20% на вещь, не имея ни дисконтки, ничего. Особенно в дорогих магазинах. Но этим мало кто пользуется :)
Гибкие политики имеют место быть (во мне Мастер Йода говорит, да)
У нас есть лицензирование по пользователям вообще и по количеству одновременных пользователей (т.е. лицензия анлим, учетки — анлим, ограничение на одновременный доступ) — кому что ближе. И да, вторая схема (называется «подписка») тоже действует.
У нас есть лицензирование по пользователям вообще и по количеству одновременных пользователей (т.е. лицензия анлим, учетки — анлим, ограничение на одновременный доступ) — кому что ближе. И да, вторая схема (называется «подписка») тоже действует.
Как бы затраты (не только денежные, но и ресурсов) на такой биллинг не перевешали бы все преимущества.
И кстати, сложность есть в планировании загрузки — одно дело пользователей запланировать, другое дело использование сервиса спрогнозировать.
Я не скажу что защищаю стандартную модель, но во всем есть свои плюсы и минусы.
И кстати, сложность есть в планировании загрузки — одно дело пользователей запланировать, другое дело использование сервиса спрогнозировать.
Я не скажу что защищаю стандартную модель, но во всем есть свои плюсы и минусы.
И еще. Чем более сложна модель, тем более сложно спрогнозировать денежные потоки.
Я имею ввиду не такой биллинг когда в конце периода выставляется счет в зависимости от использованных ресурсов, а биллинг с, грубо говоря, абонементами. В этом случае прогнозирование ничем не отличается от прогнозирования с обычными тарифами. Даже наверное еще проще, т.к. разработчику всегда точно известно количество проданных ресурсов, за которые он собственно сам платит.
А с чем был йогрут, если не секрет?
Вообще то Вы пришли к трактовке подачи SaaS от ITIL.
Там четко оговаривается что система лицензирования должна быть более тонкой, а именно:
1. Standalone лицензии для юзеров — которые часто используют систему
2. Shared (дороже первых) для тех кто использует в разное время, т.е. использование не пересекается и довольно непродолжительно.
3. Web лицензии для заказчиков/пользователей должны быть минимальны или бесплатны с доступом к облегченной версии.
Есть еще пару видов — но они относятся к типу «сервис по запросу».
Все уже давно придумано — главное использовать лучшие практики :)
Там четко оговаривается что система лицензирования должна быть более тонкой, а именно:
1. Standalone лицензии для юзеров — которые часто используют систему
2. Shared (дороже первых) для тех кто использует в разное время, т.е. использование не пересекается и довольно непродолжительно.
3. Web лицензии для заказчиков/пользователей должны быть минимальны или бесплатны с доступом к облегченной версии.
Есть еще пару видов — но они относятся к типу «сервис по запросу».
Все уже давно придумано — главное использовать лучшие практики :)
С каких пор 37signals берут деньги «per user per month»???
НЛО прилетело и опубликовало эту надпись здесь
На сколько я знаю, с самых давних. Например, highrisehq.com/signup
Are there per-user fees?
No. The prices you see above are all inclusive. For example, the Premium plan is $99/month for up to 40 users. That means you pay $99/month total no matter how many users you have as long as it's 40 or less.
А. Просто в статье разбирают управление проектами, а не контактами. С highrise собсна понятно, практически прямая зависимость нагрузки от количества сотрудников.
> мнение с другой стороны баррикад
Я не был на той стороне, но из общих соображений. Flat-rate это прежде всего предсказуемость. Большинство людей предпочтет ее некой гипотетической справедливости, которую не в состоянии компетентно проверить. Так происходит с любым массовым сервисом по достижении определенной степени зрелости рынка.
Дальше, сделать хороший биллинг ресурсов не каждая SaaS компания сможет; или может себе позволить. Представьте себе ресурсы на выработку адекватной модели, разработку, тестирование, и т.д. А главное — получить подтверждение, что все считается правильно. Амазон конечно может, а «Мое дело» вряд ли.
Да вы и сами пришли к тем же соображениям при попытке транслировать стоимость сервиса на собственных клиентов:
Еще один момент. Оплата строго «по ресурсам» ограничивает гибкость, возможность оптимизмровать расходы так или иначе. К примеру, трое сотрудников пользуются системой пару раз в месяц (начальство), зато другие пятеро вбивают документы сотнями в день. Еще неизвестно, какая модель окажется выгоднее.
Если SaaS сможет добиться масштабируемости лучшей, чем линейная, когда каждая следующая тысяча активных пользователей будет обходиться все дешевле и дешевле, тогда оплата по ресурсам станет выгодной (для сервиса). И что-то мне подсказывает, что это возможно только при масштабах порядка гугловских/амазоновских.
Я не был на той стороне, но из общих соображений. Flat-rate это прежде всего предсказуемость. Большинство людей предпочтет ее некой гипотетической справедливости, которую не в состоянии компетентно проверить. Так происходит с любым массовым сервисом по достижении определенной степени зрелости рынка.
Дальше, сделать хороший биллинг ресурсов не каждая SaaS компания сможет; или может себе позволить. Представьте себе ресурсы на выработку адекватной модели, разработку, тестирование, и т.д. А главное — получить подтверждение, что все считается правильно. Амазон конечно может, а «Мое дело» вряд ли.
Да вы и сами пришли к тем же соображениям при попытке транслировать стоимость сервиса на собственных клиентов:
Во-первых, в принципе тяжело объяснить клиенту зачем он должен платить за эту систему… Во-вторых еще тяжелее сделать эту оплату справедливой и прозрачной.
Еще один момент. Оплата строго «по ресурсам» ограничивает гибкость, возможность оптимизмровать расходы так или иначе. К примеру, трое сотрудников пользуются системой пару раз в месяц (начальство), зато другие пятеро вбивают документы сотнями в день. Еще неизвестно, какая модель окажется выгоднее.
Если SaaS сможет добиться масштабируемости лучшей, чем линейная, когда каждая следующая тысяча активных пользователей будет обходиться все дешевле и дешевле, тогда оплата по ресурсам станет выгодной (для сервиса). И что-то мне подсказывает, что это возможно только при масштабах порядка гугловских/амазоновских.
для Моего Дела это чисто бизнес решение, функционал то у них был
Извините :)
Я не говорю что все должно быть как у Амазона, зачем так усложнять? Я совсем не разбираюсь в биллинговых технологиях, но то что такие системы есть у любого хостинг-провайдера, мне кажется говорит о том что это не так дорого и сложно.
Не подменяйте понятия. Для меня это просто инструмент, от которого теоретически можно просто отказаться, а для них это основа бизнеса.
Если я правильно понял мысль, этот пример как раз иллюстрирует тот факт, что разработчики тоже должны быть заинтересованы в биллинге.
сделать хороший биллинг ресурсов не каждая SaaS компания сможет; или может себе позволить. Представьте себе ресурсы на выработку адекватной модели, разработку, тестирование, и т.д. А главное — получить подтверждение, что все считается правильно. Амазон конечно может, а «Мое дело» вряд ли.
Я не говорю что все должно быть как у Амазона, зачем так усложнять? Я совсем не разбираюсь в биллинговых технологиях, но то что такие системы есть у любого хостинг-провайдера, мне кажется говорит о том что это не так дорого и сложно.
вы и сами пришли к тем же соображениям при попытке транслировать стоимость сервиса на собственных клиентов
Не подменяйте понятия. Для меня это просто инструмент, от которого теоретически можно просто отказаться, а для них это основа бизнеса.
Еще неизвестно, какая модель окажется выгоднее.
Если я правильно понял мысль, этот пример как раз иллюстрирует тот факт, что разработчики тоже должны быть заинтересованы в биллинге.
такие системы есть у любого хостинг-провайдера, мне кажется говорит о том что это не так дорого и сложно.
Ну хорошо, поробуйте прикинуть, что в данной области будет считаться «ресурсами» для пользователей сервиса. Для хостинга модели биллинга уже отработаны и проверены рынком, есть много готовых решений, поэтому там не так дорого и сложно.
Еще неизвестно, какая модель окажется выгоднее.Если я правильно понял мысль, этот пример как раз иллюстрирует тот факт, что разработчики тоже должны быть заинтересованы в биллинге.
В примере я имел в виду выгоднее для клиента. А позицию разработчиков я бы и сам хотел услышать.
Ну хорошо, поробуйте прикинуть, что в данной области будет считаться «ресурсами» для пользователей сервиса.
Так то же самое и будет, нет? Память, процессорное время и дисковое пространство.
Ммм… кажется я потерял нить. Уточните, мы говорим о конкрентых SaaS приложениях (автоматизация бизнеса, бухучет, управление проектами и т.п.) или о вычислительной платформе (Amazon, Heroku и т.п.) для работы SaaS приложений? Это ведь принципиальная разница.
Я надеюсь очевидно, что вменяемая модель биллинга должна описываться понятиями предметной области.
Я надеюсь очевидно, что вменяемая модель биллинга должна описываться понятиями предметной области.
В чистом виде «per user per month» мало кто использует. Те же 37signals (на которых вы не тыкали пальцем) имеют несколько тарифных планов, в каждом плане N юзеров и K ресурсов. В basecamp пользователи не ограничены во всех планах, только ресурсы. Ну а дискретный планы упрощают математику. спорный вопрос как лучше — 3 фиксированных тарифных плана или сложная формула расчета стоимости с множеством переменных.
НЛО прилетело и опубликовало эту надпись здесь
У 37signals кроме Basecamp есть еще много чего, например Highrise: highrisehq.com/signup
Я привел в пример heroku, разве там сложная формула?
Я привел в пример heroku, разве там сложная формула?
В мегаплане платишь не конкретно за юзеров, а за онлайн. Скажем у нас работает человек 30, а лицензий всего на 10.
Два три человека сидят в мегалпане постоянно, юристы заходят только по каким то изменениям, бухгалтерия вообще не особо заходит, часть сотрудников ночные и в мегаплане сидят только ночью, часть удаленных сотрудников тоже редко заходят в мегаплан.
В нашем случае хватает 10 лицензий на 30 с плюсом человек, на счет работы со входом клиента не знаю как у них, но думаю что так же.
Два три человека сидят в мегалпане постоянно, юристы заходят только по каким то изменениям, бухгалтерия вообще не особо заходит, часть сотрудников ночные и в мегаплане сидят только ночью, часть удаленных сотрудников тоже редко заходят в мегаплан.
В нашем случае хватает 10 лицензий на 30 с плюсом человек, на счет работы со входом клиента не знаю как у них, но думаю что так же.
Не знал что у них такая система. Это конечно более интересно. Но что будет если вдруг сложится ситуация когда всем понадобиться зайти одновременно?
Да, лучше не ограничивать число юзеров, а ввести плату за юзеро-минуту работы, и списывать по фактически отработанному времени ))
Купите ещё лицензий.
То есть мы опять возвращаемся к тому что в общем случае количество лицензий = количеству пользователей.
Ну тут есть куда развернуться, вопрос кто и как у вас работает в компании с мегапланом.
Например ночные сотрудники ну никак у меня не смогут зайти одновременно с не ночными.
Часть сотрудников работает с 8, а часть с 9 что тоже упрощает жизнь.
В целом у меня ещё не было ситуации когда 10 юзеров мне не хватало.
Я вот не думаю что 200 ваших клиентов хотя бы раз в день заходят в мегаплан.
Часть сотрудников работает с 8, а часть с 9 что тоже упрощает жизнь.
В целом у меня ещё не было ситуации когда 10 юзеров мне не хватало.
Я вот не думаю что 200 ваших клиентов хотя бы раз в день заходят в мегаплан.
Мой опыт меня научил что если положиться на исчезающе малую вероятность какого-либо события, то рано или поздно это событие все-таки произойдет. Мы, например, работаем с серьезными людьми и допускать лажу просто не хочется. К тому же, согласитесь, сложно представить более идиотскую ситуацию, когда придется объяснять заказчику что что-то не сделано вовремя, потому что наши сотрудники не смогли зайти в систему управления проектами.
у кто то подождет 10 минут, пока кто то другой выйдет, ничего критичного тут я не вижу.
отвечу с другой стороны баррикад: разработчикам систем тоже не хочется допускать «лажу», потому издержки на сервера, каналы и поддержку приходится закладывать на максимально возможное количество абонентов
и если всем вашим сотрудникам и клиентам вдруг одновременно захочется оказаться в он-лайне на мощностях под это не приспособленных — тарифицировать вас будет тупо не за что — сервис ляжет :)
потому, подобную поминутную тарификацию могут себе позволить только сервисы, обладающие немерянными свободными мощностями или деньгами (ака амозон, гугл, етц.)
и если всем вашим сотрудникам и клиентам вдруг одновременно захочется оказаться в он-лайне на мощностях под это не приспособленных — тарифицировать вас будет тупо не за что — сервис ляжет :)
потому, подобную поминутную тарификацию могут себе позволить только сервисы, обладающие немерянными свободными мощностями или деньгами (ака амозон, гугл, етц.)
Ну так не нужно продавать несуществующие ресурсы. Я уже писал где-то в другом комменте, что речь идет о системе аналогичной той которой пользуются хостинги, когда продается, грубо говоря, изолированный кусок памяти+диска+процессора. И если клиент все израсходовал — сам себе буратино, но должна быть возможность оперативно докупить.
Вы сравниваете абсолютно одинаковые вещи. Хостинг-провайдер продает вам совершенно определенный кусок памяти, диска, процессора. Вы можете использовать 10% дискового пространства, 5% нагрузки на сервер, а заплатите все равно за 100%.
Такая же история с Мегапланом. Вы платите за 1гиг места на сервере и например за 10 лицензий (одновременно пользующихся системой сотрудников). Из расчета нагрузки на сервер 10 онлайн-юзеров и места на диске и складывается ценообразование. А используете вы его по максимуму или нет — это уже ваша проблема. Не хватает, можно быстро докупить.
Точно как в хостинге — не устраивает количество выделенных ресурсов, перешли на другой тариф.
Такая же история с Мегапланом. Вы платите за 1гиг места на сервере и например за 10 лицензий (одновременно пользующихся системой сотрудников). Из расчета нагрузки на сервер 10 онлайн-юзеров и места на диске и складывается ценообразование. А используете вы его по максимуму или нет — это уже ваша проблема. Не хватает, можно быстро докупить.
Точно как в хостинге — не устраивает количество выделенных ресурсов, перешли на другой тариф.
Да нет, разница есть. Ключевое понятие: ресурсы потребляемые пользователем. Не все потребляют одинаково. Модель Мегаплана конечно гораздо лучше чем у остальных, которые просто продают аккаунты, но все равно (ниже обсуждали) в общем случае получается что нужно покупать столько аккаунтов, сколько всего пользователей, т.к. существует ненулевая вероятность того что все вместе захотят выйти в онлайн.
Кроме того, не обязательно продавать фиксированные ресурсы, можно сделать автоматическое расширение, что бы клиент вообще ни о чем не беспокоился.
Кроме того, не обязательно продавать фиксированные ресурсы, можно сделать автоматическое расширение, что бы клиент вообще ни о чем не беспокоился.
Авиакомпании продают билетов больше, чем способен вместить салон. С расчетом на то что кто-то опоздает, передумает и т.д. Это нормальная практика и вроде проблем не бывает.
Ваша идея в теории хороша, но… Во-первых, такое ценообразование будет не реально объяснить клиенту. Поверьте, многие не могут разобраться со схемой «скидка за количество лицензий + скидка за количество месяцев». Во-вторых, SaaS на западе разлетается как горячие пирожки (для компаний важны каналы продаж, а не усовершенствование системы ценообразования), а в России SaaS до сих пор убыточное занятие и вопрос стоит о выживании. Проще снизить цены, чем придумывать сложные алгоритмы которые будет сложно реализовать, объяснить и доказать клиентам. Чтобы у клиентов не было вопросов, нужно будет делать доп. панель управления, чтобы клиент сам мог в режиме реального времени видеть свои расходы. Иначе будет куча обращений «вы мне неправильно посчитали, я не мог столько потратить». Оно пока того не стоит. Лучше заниматься усовершенствованием функционала.
Ваша идея в теории хороша, но… Во-первых, такое ценообразование будет не реально объяснить клиенту. Поверьте, многие не могут разобраться со схемой «скидка за количество лицензий + скидка за количество месяцев». Во-вторых, SaaS на западе разлетается как горячие пирожки (для компаний важны каналы продаж, а не усовершенствование системы ценообразования), а в России SaaS до сих пор убыточное занятие и вопрос стоит о выживании. Проще снизить цены, чем придумывать сложные алгоритмы которые будет сложно реализовать, объяснить и доказать клиентам. Чтобы у клиентов не было вопросов, нужно будет делать доп. панель управления, чтобы клиент сам мог в режиме реального времени видеть свои расходы. Иначе будет куча обращений «вы мне неправильно посчитали, я не мог столько потратить». Оно пока того не стоит. Лучше заниматься усовершенствованием функционала.
Ну я же тут просто теоретизирую и не предлагаю никому завтра же все это внедрять. И потом я говорю о технической идее, а то что вы пишете это маркетинг в котором я не очень разбираюсь. Не знаю что тут сказать. Да, надо чтоб было понятно для клиента. Разумеется, нужна панель управления.
Поверьте, у авиакомпаний проблемы бывают. Буквально месяц назад был свидетелем того как две пары с детьми не пустили на рейс как раз из-за овербукинга — предложили подождать следующего, который завтра. Естественно я теперь этой авиакомпанией никогда не полечу и всех буду отговаривать.
Поверьте, у авиакомпаний проблемы бывают. Буквально месяц назад был свидетелем того как две пары с детьми не пустили на рейс как раз из-за овербукинга — предложили подождать следующего, который завтра. Естественно я теперь этой авиакомпанией никогда не полечу и всех буду отговаривать.
Про авиакомпанию ничего не скажу. Может все на 5% билетов больше продают. а они на 20%. Но практика эта нормальная. Так же как и фитнес-центры продают абонементов больше чем способен физически вместить зал.
Возвращаясь к нашим баранам :) Повторюсь, ваша техническая сторона хороша, но над ее реализацией саас-компании не задумаются еще как минимум года 3 точно
Возвращаясь к нашим баранам :) Повторюсь, ваша техническая сторона хороша, но над ее реализацией саас-компании не задумаются еще как минимум года 3 точно
Вот это грамотно.
За ресурсы, часто вызывает сложность в определении менеджеров, то есть очень трудно донести до менеджера, который к ИТ не имеет никакого отношения, как будет рассчитываться стоимость данной услуги. У нас пытаются ввести ограничение по пользователям, еще и по транзакциям на пользователя (то есть верхний порог, он достаточно высок, но все что бы отсечь большую нагрузку на одного пользователя)
Самое главное — «финансовый рычаг» при продаже сервиса. Так бы потратил много денег, а с нашим сервисом всего кусочек, жалкие 500 у.е. в месяц за аккаунт :) Будут колоться, плакать, рассказывать об охреневших придурках, но жрать кактус с помесячной оплатой.
Без этой темы с прямой выгодой даже самая тонкая тарифная сетка не заставит пользоваться сервисом, если им можно не пользоваться.
Рассуждения в стиле «24000 $ за клиентов много» не имеют смысла. Если это десятая часть от прибыли с одного клиента, то это наоборот мало.
Например, офисный интернет интереснее брать «канал с помесячной оплатой», чем платить за фактические гигабайты, учитывать кто из сотрудников сколько скачал и т.д. Интернет в структуре затрат не делает погоды, но учет трафика будет тратить нервы и ухудшать рабочую обстановку.
Если такая тема в принципе возможна, чтобы три сотрудника легко и непринужденно вели 200 клиентов — вам с радостью процент от оборота откинут за сервис и партнером сделают, а не месячную абонентку. :)
Другой деликатный момент. Saas не должен быть распиаренным говном, под которое надо перевернуть весь бизнес.
Без этой темы с прямой выгодой даже самая тонкая тарифная сетка не заставит пользоваться сервисом, если им можно не пользоваться.
Рассуждения в стиле «24000 $ за клиентов много» не имеют смысла. Если это десятая часть от прибыли с одного клиента, то это наоборот мало.
Например, офисный интернет интереснее брать «канал с помесячной оплатой», чем платить за фактические гигабайты, учитывать кто из сотрудников сколько скачал и т.д. Интернет в структуре затрат не делает погоды, но учет трафика будет тратить нервы и ухудшать рабочую обстановку.
Если такая тема в принципе возможна, чтобы три сотрудника легко и непринужденно вели 200 клиентов — вам с радостью процент от оборота откинут за сервис и партнером сделают, а не месячную абонентку. :)
Другой деликатный момент. Saas не должен быть распиаренным говном, под которое надо перевернуть весь бизнес.
Сегодня есть достойные SaaS решения для управления проектами, которые предоставляются бесплатно — без ограничений по юзерам, аккаунтам, онлайну, месяцам пользования и пр.
Например, TeamLab- www.teamlab.com — о котором здесь мы недавно писали: habrahabr.ru/company/ascensio/blog/116414/
Например, TeamLab- www.teamlab.com — о котором здесь мы недавно писали: habrahabr.ru/company/ascensio/blog/116414/
Разработчики должны считать свои расходы по-честному и оптимизировать затраты.
разработчики никому ничего не должны. У них товар, у вас купец, и т.п. Если бы модель была нежизнеспособна, то ей бы никто и не пользовался. А так, для 99% проще заплатить прямо скажем небольшую сумму за +10 пользователей, чем вникать в какие-то там подсчеты потребленных ресурсов.
Читаю и думаю, что вы смотрите на систему как клиент, но клиент-разработчик.
Т.е. вам понятно, что такое потребляемые ресурсы. Да, в общем, и оба примера, которые вы привели — это клауд от Хероку и клауд от Амазона — очень специфичные СааСы, где именно ресурсы и продают.
Ни один менеджер по управлению проектами не сможет подсчитать, сколько ему надо компьютерных ресурсов, для обслуживания своей компании. Он с ума сойдёт.
И будет считать, что его пытаются наебать. Причём обоснованно :)
Для того, чтобы стоимость была прозрачной, владельцу сервиса понимать, кто аудитория сервиса и выдавать ей расчёт стоимости от понятной ей (айдитории) условной единицы.
В Бейскемпе — проекты, в Мегаплане — онлайн-юзеры. В амазоне — процессорные часы.
Это понятно для потенциальных покупателей этих сервисов. Они могут посчитать — адекватна эта цена или нет. И принять решение о покупке или поиске более адекватного сервиса.
Если же предложить на амазоне считать в пользователях или на бейскемпе в процессорных часах, то всё у клиентов случится ступор и никто ничего не купит.
Не усложняйте — дайте людям то, что они понимают.
Т.е. вам понятно, что такое потребляемые ресурсы. Да, в общем, и оба примера, которые вы привели — это клауд от Хероку и клауд от Амазона — очень специфичные СааСы, где именно ресурсы и продают.
Ни один менеджер по управлению проектами не сможет подсчитать, сколько ему надо компьютерных ресурсов, для обслуживания своей компании. Он с ума сойдёт.
И будет считать, что его пытаются наебать. Причём обоснованно :)
Для того, чтобы стоимость была прозрачной, владельцу сервиса понимать, кто аудитория сервиса и выдавать ей расчёт стоимости от понятной ей (айдитории) условной единицы.
В Бейскемпе — проекты, в Мегаплане — онлайн-юзеры. В амазоне — процессорные часы.
Это понятно для потенциальных покупателей этих сервисов. Они могут посчитать — адекватна эта цена или нет. И принять решение о покупке или поиске более адекватного сервиса.
Если же предложить на амазоне считать в пользователях или на бейскемпе в процессорных часах, то всё у клиентов случится ступор и никто ничего не купит.
Не усложняйте — дайте людям то, что они понимают.
Именно. А иначе получится как со стоимостью интернета в роуминге.
Если честно, я предлагаю именно продавать ресурсы + права на использование и некоим образом это не скрывать, потому что это реально и есть то, что продается в SaaS. Только не надо понимать слишком буквально. О том что написано на сайте разработчика в разделе «pricing» должны заботиться маркетологи, это их работа, я говорю только о принципе. Тем не менее я уверен что с помощью простых примеров, понятных среднему менеджеру, процессорное время и память можно конвертировать в пользователей, проекты и все остальное.
Не скрывать — это хорошо.
Вопрос в том, хотят ли покупатели знать то, что вы не хотите скрывать. Старая же поговорка «меньше знаешь — крепче спишь».
Зачем показывать менеджерам простые примеры по переводу, если всё это могут сделать «маркетологи в разделе pricing».
Каждый повод клиенту задуматься о чём-то непонятном — это минус клиент.
Хотите считать от нагрузки — считайте, хотите считать от кол-ва серверов в вашем ДЦ — считайте, да хоть от фазы луны.
Только клиенту показывайте то, что он поймёт. И сможет сравнить.
Вопрос в том, хотят ли покупатели знать то, что вы не хотите скрывать. Старая же поговорка «меньше знаешь — крепче спишь».
Зачем показывать менеджерам простые примеры по переводу, если всё это могут сделать «маркетологи в разделе pricing».
Каждый повод клиенту задуматься о чём-то непонятном — это минус клиент.
Хотите считать от нагрузки — считайте, хотите считать от кол-ва серверов в вашем ДЦ — считайте, да хоть от фазы луны.
Только клиенту показывайте то, что он поймёт. И сможет сравнить.
Не, извините, но я считаю что это ущербный подход. Так реально инновационные вещи никогда бы не продавались, потому что при продаже их нужно было бы сравнивать с чем-то старым, что было бы невозможно, т.к. ничего похожего раньше не было.
При этом я естественно против запугивания потенциально клиента непонятными умными словами и считаю что можно все изложить так чтобы он все понял и даже мог сравнить. Да, для этого может понадобиться некая номинальная умственная деятельность, но если клиент сделать не в состоянии, то может ну его?
При этом я естественно против запугивания потенциально клиента непонятными умными словами и считаю что можно все изложить так чтобы он все понял и даже мог сравнить. Да, для этого может понадобиться некая номинальная умственная деятельность, но если клиент сделать не в состоянии, то может ну его?
Тут мы можем уйти далеко :)
Не поймите меня неправильно.
Я не против разных способов расчёта.
Я лишь за то, чтобы результат этих расчётов подавался в понятном для клиентов виде. Иначе всё напрасно, как бы «честно и правильно» ни вёлся этот расчёт.
Ну а про инновационные штуки — почему их нужно сравнивать с чем-то старым??
Их нужно сравнивать с чем-то понятным.
Очень мало инноваций, которые инновации сами в себе (закон Ньютона, теория относительности, нанотехнологии опять же). Да и то, чтобы их поняли покупатели (не редкие, а массовые) их нужно объяснить.
Что такое нанотехнологии — для людей, которые не очень в теме, всё плохо понятно, хотя может уже сегодня всем нужны нанороботы :)
А если рассказать, что 3 таблетки, наполненные нанороботами, брошенные на пол будут чистить пол как пылесос в течение года, а потом сядет батарейка — сразу всем объяснит что же это такое и очередь построится, по-круче чем за Эпплом.
Вообще, я, наверное, далёк от очень инновационных инноваций, но нам нужны примеры пользовательских.
Вариант: Пока диод — это мифическая хрень, его никто не купит. Но как только сказано, что это лампочка (и 10W = 100W, а ещё работает дольше), продажи обеспечены (если не обманывают).
Что ещё из пользовательских инноваций — айПед («великая революция», засчитывается?) — планшетный компьютер, но ооочень удобный и пальцами можно водить…
SalesForce (первый, вроде, крупный SaaS) — а говорил, что CRM-система.
Так и тут, если хотите инновационно считать стоимость СааСа для широкого покупателя — считайте, но объясняйте потом знакомыми понятиями.
Может в конце концов все придут к вашему способу считать, но это «долгий путь и нужно вырастить не одно поколение» :))
Не поймите меня неправильно.
Я не против разных способов расчёта.
Я лишь за то, чтобы результат этих расчётов подавался в понятном для клиентов виде. Иначе всё напрасно, как бы «честно и правильно» ни вёлся этот расчёт.
Ну а про инновационные штуки — почему их нужно сравнивать с чем-то старым??
Их нужно сравнивать с чем-то понятным.
Очень мало инноваций, которые инновации сами в себе (закон Ньютона, теория относительности, нанотехнологии опять же). Да и то, чтобы их поняли покупатели (не редкие, а массовые) их нужно объяснить.
Что такое нанотехнологии — для людей, которые не очень в теме, всё плохо понятно, хотя может уже сегодня всем нужны нанороботы :)
А если рассказать, что 3 таблетки, наполненные нанороботами, брошенные на пол будут чистить пол как пылесос в течение года, а потом сядет батарейка — сразу всем объяснит что же это такое и очередь построится, по-круче чем за Эпплом.
Вообще, я, наверное, далёк от очень инновационных инноваций, но нам нужны примеры пользовательских.
Вариант: Пока диод — это мифическая хрень, его никто не купит. Но как только сказано, что это лампочка (и 10W = 100W, а ещё работает дольше), продажи обеспечены (если не обманывают).
Что ещё из пользовательских инноваций — айПед («великая революция», засчитывается?) — планшетный компьютер, но ооочень удобный и пальцами можно водить…
SalesForce (первый, вроде, крупный SaaS) — а говорил, что CRM-система.
Так и тут, если хотите инновационно считать стоимость СааСа для широкого покупателя — считайте, но объясняйте потом знакомыми понятиями.
Может в конце концов все придут к вашему способу считать, но это «долгий путь и нужно вырастить не одно поколение» :))
То есть вы серьезно предлагаете Zoho, Мегаплану и подобным продавать процессорное время или мегабайты памяти?
Но это же абсурд. Как объяснить клиенту, что формирование одного отчета занимает 10 попугаев, а другого — 1000? Для клиента это всегда будут именно попугаи, так как невозможно «процессорное время и память конвертировать в пользователей, проекты и все остальное». Даже если допустить, что вы (клиент) во всем этом разбираетесь, система все равно остается для вас «черным ящиком».
Да вы сами первый сбежите от такого провайдера, как только ваши ежемесячные расходы вдруг превысят ожидаемые.
Но это же абсурд. Как объяснить клиенту, что формирование одного отчета занимает 10 попугаев, а другого — 1000? Для клиента это всегда будут именно попугаи, так как невозможно «процессорное время и память конвертировать в пользователей, проекты и все остальное». Даже если допустить, что вы (клиент) во всем этом разбираетесь, система все равно остается для вас «черным ящиком».
Да вы сами первый сбежите от такого провайдера, как только ваши ежемесячные расходы вдруг превысят ожидаемые.
Я никому ничего не предлагаю, просто высказываю идею.
Но ведь согласитесь, что на самом деле действительно один отчет «стоит» 10 попугаев, а другой 1000? И в этом смысле система действительно является черным ящиком. И говорить что например 100 попугаев = 1 пользователь это обман.
Вопрос только в том как рассказать об этом клиенту так чтобы он понял сколько попугаев ему нужно. Я не думаю что это невозможно.
Но ведь согласитесь, что на самом деле действительно один отчет «стоит» 10 попугаев, а другой 1000? И в этом смысле система действительно является черным ящиком. И говорить что например 100 попугаев = 1 пользователь это обман.
Вопрос только в том как рассказать об этом клиенту так чтобы он понял сколько попугаев ему нужно. Я не думаю что это невозможно.
Это очень просто. Пользователю не нужно 100 попугаев, ему нужна лицензия на одного пользователя.
Это один путь, простой. Другой, сложный и затратный, — это построить биллинг ресурсов конкретного приложения. Например, для бухучета это будет количество вводимых первичных документов, количество субсчетов, операций и т.д. Для системы управления проектами что-то свое. Если рынок примет SaaS приложения и они наберут популярность, это будет сделано.
Это один путь, простой. Другой, сложный и затратный, — это построить биллинг ресурсов конкретного приложения. Например, для бухучета это будет количество вводимых первичных документов, количество субсчетов, операций и т.д. Для системы управления проектами что-то свое. Если рынок примет SaaS приложения и они наберут популярность, это будет сделано.
И еще надо не забывать о тех, кто сидит с «той стороны». У них в общем-то программисты, админы и прочий суппорт на зарплатах сидят, которую надо как-то планировать, чтобы не остаться с голым задом. Проданные «человеко-месяцы» можно как-то оценить, а вот будущее потребление «часов» — ну, знаете ли…
при платных апгрейдах придётся поддерживать старые версии. эффективнее поддерживать только последнюю версию, а пользователям старой предлагать бесплатное обновление.
Справедливое ценообразование может быть не только по затратам. Вспомните бизнес-класс в самолетах. И если вы лично им не летаете, то это не значит, что он плох.
Поэтому нельзя говорить о том, что модель «за пользователя» в стэндэлон версиях — плоха. Цена многие товары складывается из возможности клиента за нее заплатить.
Поэтому нельзя говорить о том, что модель «за пользователя» в стэндэлон версиях — плоха. Цена многие товары складывается из возможности клиента за нее заплатить.
Я думаю что в долгосрочной перспективе это работает только для статусных вещей.
Скажем так, такого рода модель сильно оттталкивает от сервисов.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Почему модель оплаты per user per month плохая