Как справиться с понижением подписки для приложения SaaS

В настоящее время я запускаю веб-приложение SaaS. Я хочу иметь такие пакеты подписки, как:

  • Премиум: 5 пользователей, 20 виджетов, 20 МБ хранилища
  • Базовый: 2 пользователя, 10 виджетов, 50 МБ хранилища

Я хочу разрешить компаниям обновлять и понижать пакеты в любое время.

Проблема, с которой я столкнулся, заключается в том, что, если компания использует премиум-пакет, имеет 5 пользователей, 20 виджетов и хочет перейти на «базовый» пакет. Как мне с этим справиться?

Должен ли я отметить ошибку и сказать: «Вы не можете перейти на более раннюю версию» или перенаправить их на страницу, чтобы удалить «лишних» пользователей и виджеты?

Любые советы или примеры того, как это делают другие компании, было бы здорово !!


person user635800    schedule 24.04.2011    source источник


Ответы (3)


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

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

person Matti Virkkunen    schedule 24.04.2011
comment
Спасибо, Матти! Еще одна проблема, которую я пытаюсь решить, - это бесплатные пробные версии. Такие компании, как Zendesk.com, предлагают бесплатную пробную версию и ставят для клиента лучший пакет, который они предлагают, чтобы пользователь мог испытать все приложение. Через 30 дней они заставляют покупателя заплатить. Если я это сделаю, а клиент заполнит свое приложение, как мне позволить ему удалить что-то? Могу ли я временно позволить им очистить данные или я просто заставлю их подписаться на лучший пакет и позволить им перейти на более раннюю версию позже? - person user635800; 24.04.2011
comment
@userrandomnumbers: это немного более сложный вопрос. Заставить людей подписаться на лучший пакет - это немного грубо, но необходимость реализовать весь режим, позволяющий людям удалять только данные, - это большая работа (если у вас не было действительно гибкой системы контроля доступа с самого начала). Как Zendesk справляется с этим? - person Matti Virkkunen; 24.04.2011

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

На панели инструментов я показываю пользователю их текущие уровни плана и лимит элементов, которые в настоящее время есть в их плане. Так например:

Campaigns: using 8 out of 10

Если они перейдут к плану с, скажем, 5 кампаниями, будет сказано

Campaigns: using 10 out of 5

Это явно неубедительно, поэтому мое решение - отображать оставшиеся как

 Campaigns: using 5 out of 5 (3 campaigns inactive - UPGRADE)

Теперь, с точки зрения бизнеса, я думаю, что имеет смысл деактивировать последние созданные ими кампании, пока они не обновятся до плана. Это означает, что мы блокируем все кампании, кроме X первых созданных кампаний. Это будет хорошим стимулом для них либо обновить, либо начать удалять старые предметы (согласно ответу Матти Вирккунена)

У меня есть логика в приложении, которое запускает метод isItemActive, который проверяет, основан ли на их текущем плане и уровнях этого плана, должен ли этот элемент быть активным каким-либо образом (IE: отображать его в интерфейсе для посетителей или что-то еще). Естественно, это зависит от самого приложения, но я думаю, что подход LIFO (последний в первом деактивирован) имеет наибольший смысл и заставляет пользователей либо обновлять, либо, по крайней мере, удалять свои старые элементы.

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

person stueynet    schedule 29.11.2011

Мы столкнулись с аналогичной проблемой и все еще обсуждаем, как лучше всего это сделать на основе собранных данных.

Как бы то ни было, у нас тоже есть разные «размеры тарифных планов», и мы позволяем нашим клиентам сохранять в Интернете свою работу.

Когда один из наших клиентов хочет перейти на более раннюю версию, мы всегда позволяем ему это сделать и скидываем все остаточные деньги с его предыдущего плана (например, начиная с плана 100 долларов в месяц и переходя на план 50 долларов в месяц после использования 20-дневного плана). при смене плана они получают скидку в размере 33 $. Если скидка превышает стоимость плана с пониженной версией, их первый новый платеж будет отложен соответствующим образом. Таким образом, их первоначальные вложения всегда сохраняются).

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

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

Удаление лишних данных, которые не соответствуют плану с пониженной версией, это, безусловно, большой стимул не переходить на более раннюю версию, и мы тоже думаем о переходе на эту модель.

person Sergio    schedule 24.11.2011