

Ask YC: How do you deal with account downgrades? - jam

Tons of web services use progressively higher account limits based on a pay scale. Take Basecamp, for instance: http://www.basecamphq.com/signup<p>My question is: how does your company deal with users downgrading their accounts to a level that they are already over?<p>For example: someone has a Basecamp Premium account with 60 active users and 5 GB stored on the servers, and then decides to downgrade to a Plus account.
======
bradg
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.

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

------
RyanGWU82
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...

~~~
jam
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.

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

------
brk
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.

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

------
pmjordan
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. :)

------
izak30
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.

~~~
dcurtis
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.

