How to handle downgrade subscription for SaaS application_问答_开发者

I am currently launching a SaaS web application. I want to have subscription packages such as:

Premium: 5 users, 20 widg开发者_开发技巧ets, 20 MB storage
Basic: 2 users, 10 widgets, 50 MB storage

I want to allow companies to upgrade and downgrade packages at any time.

The problem I am having is what if the company is on the premium package and has 5 users, 20 widgets, and wants to downgrade to the "basic" package. How do I handle that?

Do I flag an error and say "You cannot downgrade" or do I take them to a page to remove the "extra" users and widgets?

Any advice or examples of how other companies do it would be great!!

I don't think you need a separate special page with functionality to aid people downgrade. Just show them how much they're using and how much their new plan allows, and tell them to go delete stuff if they still want to downgrade.

If you're lucky, seeing how much they'll need to get rid of might convince them to not downgrade afterall...

I am dealing with this exact conundrum. I am offering 3 paid plans (and a totally free plan), with very easy to use upgrade downgrade functionality. My app is not storage intensive so I don't care about keeping data that is currently not active.

In the dashboard I show the user their current plan levels and the limit of items they currently have on their plan. So for example:

Campaigns: using 8 out of 10

If they downgrade to a plan with say 5 campaigns, it would say

Campaigns: using 10 out of 5

This is obviously lame so my solution is to display the remaining as

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

Now from a business perspective I think it makes the most sense to deactivate the last campaigns they created until they upgrade to a plan. This means we lock all campaigns except for the X first campaigns created. This will be a good incentive for them to either upgrade or start deleting older items (as per Matti Virkkunen's answer)

I have logic in the app that runs a method for isItemActive which checks if basedon their current plan, and the levels of that plan, should this item be active in whatever way it is supposed to (IE: display it on the front end to visitors or whatever). Naturally this depends on the app itself but I think the LIFO approach (last in first deactivated) approach makes the most sense and forces users to either upgrade,m or at least delete their older items.

In your case you could potentially do the same thing except that you may want to add a warning or time limit after which they user's data above their limit will be deleted permanently.

We faced a similar problem and are still debating on how best to do it based on collected data so far.

Anyhow, we too have different "billing plan sizes" and allow our customers to save online their work.

When one of our customer wants to downgrade, we always let him do that and discount any residual money from their previous plan (e.g.: starting from a 100$/month plan and downgrading to a 50$/month plan after using 20 days worth of service, they get a 33$ discount when changing plan. If the discount exceeds the value of the downgraded plan, their first new payment is posticipated accordingly. This way their initial investment is always preserved).

As for the saved data, we keep that but do not allow the customer to use it in any way, so that if one day he re-upgrades he recovers it.

This has pros and cons. One pro is that it facilitates "seasonal" users, one con is that you may end up storing a lot of data for little money.

Deleting the excess data that does not fit in the downgraded plan, well, it surely is a big incentive not to downgrade and we too are thinking about switching to this model.