Rails - Jun 2006 - [Slightly Off Topic]How to handle downgrades

Let''s say that there is a web application which comes in several 
different plans.  Each plan has a different number of  users and content 
items allowed for an account.  Obviously we can allow the user to 
upgrade to a higher level plan by just increasing their limits but how 
do we handle downgrades?  If the user is only allowed x items on the 
downgraded plan and they currently have x+10 items what do we do?

The way I see it there are a few options.
1.  Don''t let a user downgrade their plan until they have deleted
enough
users and items to meet the requirements for the plan they are 
downgrading to.
2.  Let a user downgrade but don''t let them add any new users or items 
until they are below their new plan''s requirements.  Allows for people 
to kind of cheat the system.  I believe that overall people are pretty 
honest and this would not be much of an issue.  I do however think this 
might be confusing for a customer.
3.  Don''t allow for downgrades at all.  This would make it easier on
the
developer but would pretty much suck from the customer perspective.

What have you all done and what approach would you recommend for an up 
and coming web application?


Thank you,
Matthew Margolis
blog.mattmargolis.net

Matthew Margolis wrote:
> Let''s say that there is a web application which comes in several 
> different plans.  Each plan has a different number of  users and content 
> items allowed for an account.  Obviously we can allow the user to 
> upgrade to a higher level plan by just increasing their limits but how 
> do we handle downgrades?  If the user is only allowed x items on the 
> downgraded plan and they currently have x+10 items what do we do?
> 
> The way I see it there are a few options.
> 1.  Don''t let a user downgrade their plan until they have deleted
enough
> users and items to meet the requirements for the plan they are 
> downgrading to.
You could do a variation on this theme. When they select to downgrade, 
display a screen saying that the new account can only have x users/items 
and that they currently have more than this. Then display a list of what 
they have with checkboxes and ask them to select the users/items that 
they want to keep up to a max of x.

You could even just disable the unselected ones, so that if they upgrade 
again in the future they are there again and they don''t have to
re-input
that data - again, depends on what the application does.

hth

-- 
R.Livsey
http://livsey.org

Richard Livsey wrote:
> Matthew Margolis wrote:
>> Let''s say that there is a web application which comes in
several
>> different plans.  Each plan has a different number of  users and 
>> content items allowed for an account.  Obviously we can allow the 
>> user to upgrade to a higher level plan by just increasing their 
>> limits but how do we handle downgrades?  If the user is only allowed 
>> x items on the downgraded plan and they currently have x+10 items 
>> what do we do?
>>
>> The way I see it there are a few options.
>> 1.  Don''t let a user downgrade their plan until they have
deleted
>> enough users and items to meet the requirements for the plan they are 
>> downgrading to.
>
> You could do a variation on this theme. When they select to downgrade, 
> display a screen saying that the new account can only have x 
> users/items and that they currently have more than this. Then display 
> a list of what they have with checkboxes and ask them to select the 
> users/items that they want to keep up to a max of x.
>
> You could even just disable the unselected ones, so that if they 
> upgrade again in the future they are there again and they don''t
have
> to re-input that data - again, depends on what the application does.
>
> hth
>
Sounds like a good idea.  I do think that approach #1 is probably the 
nicest to the user and just disabling their content would be pretty cool 
if they ever wanted to upgrade again.  I don''t know if disabling will 
mesh too well with my product''s requirements but I will give it a shot.

Thank you,
Matthew Margolis
blog.mattmargolis.net