Try to structure your service with monthly allotments. So instead of a total of 5GBs, allow 1GB per month.

Also, from an implementation perspective; make sure that to run an upgrade/downgrade all you need to do is change some database field values. You do NOT want to be running code that has to go through and change a bunch of stuff.

For users... keep them around; just disable their login. We're going to be implementing multiple users in our application and we are going to handle downgrades by simply maintaing an "ordered list" of users. So you have 20 users on your account w/ 20 max in that plan. If you downgrade to a 10 user plan, we "gray out" and "disable" the "bottom 10" users. The administrator can rearrange the disabled users towards the top of the list, which will "re-enable" them.

This raises another important point with our approach; we keep all of the users data so that when they downgrade, they can see that all of their shit is there but some of it might be disabled (don't hold your users data hostage or they will get PISSED! Note how for our users approach we don't just disable users willy nilly. The admin/user has control). If they can see their data is there, just not "usable" w/o an upgrade... they might be tempted to upgrade again.

Good luck implementing all of this! It truly is a pain in the ass. Just keep it all data driven and your life will be much easier.

This is definitely the best way to do it that I've seen in this thread. Kudos!

Ummm, normally you wouldn't let a user downgrade until they remove enough data that they fall under the lower limit. Doesn't seem that difficult...

Right, that's the obvious solution. I'm still curious to see if anyone has come up with a different way of doing things, though.

You don't need to make downgrading easier than this ;)

Most of the time you can't downgrade if you're over a limit. You would have to delete users, files, whatever, and then downgrade.

Or, you're charged an overage fee until you've cleaned out the excess bits.

not letting users downgrade, seems a broken model. Let them downgrade then - gray out.

I don't think there's a "hard and fast" rule you could apply here, it would have to depend on the service. I'd probably do something along these lines:

* Warn the user with as much notice as possible that they're over or close to the limit of their downgraded plan. It should be painfully obvious to the user that they're about to lose their extra privileges and data. (a red bar with warning always displayed along top of site, for example)

* On the day of the downgrade, send them another email saying the changeover is imminent.

* Actually don't downgrade them for a couple of days, but keep the message up.

* After those couple days, do switch over, and don't allow any write accesses other than deletes until the user has cleared the excess. Make sure your app handles this gracefully. If your app is mostly write once, read many, then put random data over the limit (their most-used files?) into "holding" where they can't get to it until they delete files to get under the quota. (and give a hint that they wouldn't have this problem with the more expensive account type)

* If they don't clear out their stuff after 2-4 weeks, just automatically delete enough data to enforce the quota. Email them a final warning a few days before the deletion.

But maybe that's just me and my naturally customer-friendly point of view. :)

For us:

We have 'tiers' and bill a user based on which tier their use fits in, if they increase enough to be in the next tier, they get everything that goes with it, if they only have a small increase, they get an overage, that is some cost between the two tiers.

The problem with this is that you are not allowing the user to decide which tier they are in, and you'd probably piss a lot of them off by automatically moving and charging them in the next higher tier.

Overage fees are terrible for user retention, because they just irritate people unless it is extremely obvious and normal in your market to charge such fees.