Jump to content

Plans & Promos


SaranacLake

Recommended Posts

My website allows users to purchase various membership plans which in turn gives them varying degrees of access to content and features.

I was going to create a "membership_plan" table and call it quits, but then the marketer in me stepped in and posed some interesting questions...

- What happens when a given "membership_plan" has a price change?  How do you keep track of that?

- What happens when a given "membership_plan" has a change to its features?  How d you keep track of that?

I am more concerned with how do I manage evolving "membership_plans" with what has already been sold?!

For example, maybe I sell @requinix a "Platinum" plan today for $50/year, but then this summer i add in free podcasts in that plan, and decide to increase the price to $70/year.

I need some way to make sure that Requinix doesn't see a price increase, because he should be locked in for $50/year until the end of his term.

The more i think about this the more of a mess it becomes.

I suppose all of this is more of a database question, but I figured i would ask it hear since it is also a programming rpblem.

I am thinking I have data entities here like: MEMBERSHP_PLAN and PROMOTION and maybe PLAN_HISTORY or PLAN_DETAILS?

Looking like there is a many-to-many here, but I could use some advice on how to build this out?!

Thanks!

 

Link to comment
Share on other sites

Just now, requinix said:

It's actually pretty simple: you create a brand new plan and make sure people can no longer choose the old one.

But doesn't that create a lot of fragmentation?

Because now I have "Platinum_v01" and "Platinum_v02" and so on in my database.

I was thinking something like this would be better...

	MEMBERSHIP_PLAN -||--------|<- PROMOS
	

or

	MEMBERSHIP_PLAN -||--------|<- PLAN_HISTORY
	

 

The idea being that the "Platinum" plan for the msot part is the same old "Platinum" plan, but the price will certainly change over time and maybe a few features.

 

Link to comment
Share on other sites

11 minutes ago, SaranacLake said:

But doesn't that create a lot of fragmentation?

Fragmentation? I don't see how.

Quote

Because now I have "Platinum_v01" and "Platinum_v02" and so on in my database.

Yeah. So? What's wrong with having multiple plans? Your business needs change over time, it's okay.

Quote

I was thinking something like this would be better...

 


	MEMBERSHIP_PLAN -||--------|<- PROMOS

or

 


	MEMBERSHIP_PLAN -||--------|<- PLAN_HISTORY

 

The idea being that the "Platinum" plan for the msot part is the same old "Platinum" plan, but the price will certainly change over time and maybe a few features.

And you could, if you wanted. But isn't it starting to get rather complicated? You have to look up pricing at that time, features at that time... It sounds cooler and making it more complex might seem like it's better, but what are you really gaining from it? How much time is it going to take to make this work? What is the risk of something going wrong?

Multiple plans fits better into your structures, covers all the requirements, and is easy to implement. I mean, surely you're not going to be changing plans every week, right? You design your plans now because you think they will last, and then you find out later that something needs to change or that you can get more conversions if you alter pricing or features, then you roll out a new plan for those people.

Link to comment
Share on other sites

44 minutes ago, requinix said:

Multiple plans fits better into your structures, covers all the requirements, and is easy to implement. I mean, surely you're not going to be changing plans every week, right? You design your plans now because you think they will last, and then you find out later that something needs to change or that you can get more conversions if you alter pricing or features, then you roll out a new plan for those people.

I see your points, except for maybe the last thing...

if the only thing that changes on a plan is a rate change, then should I create an entirely new (and basically identitcal) plan just for the rate increase from say $50/yr to $55/year?

I could do this this...

	MEMBERSHIP_PLAN -|----|<- PRICING_HISTORY
	

 

That way if the price goes up of down I'm covered and don't have to muck up my database with clone records.  However, to your earlier point, if things like features change, then sure, create a new record in MEMBERSHIP_PLAN with a comment like "Platinum (Winter 2019)", "Platnum (Summer 2020)", etc.

Yes or no?

 

Link to comment
Share on other sites

Still no. I myself have tried the path you're looking at and believe me, it's not fun to work with. There are too many moving parts. Database queries suck. Adds joins to queries that didn't need them. It's just too complicated - and that's really something coming from me because I love over-engineering these things.

Maybe don't think of it as changing the price but as taking one plan that was fairly successful and setting up another similar plan with a slightly different price.

Link to comment
Share on other sites

Just now, requinix said:

Still no. I myself have tried the path you're looking at and believe me, it's not fun to work with. There are too many moving parts. Database queries suck. Adds joins to queries that didn't need them. It's just too complicated - and that's really something coming from me because I love over-engineering these things.

Maybe don't think of it as changing the price but as taking one plan that was fairly successful and setting up another similar plan with a slightly different price.

Fair enough!

 

Psst...  I created a most excellent thread asking for help on MVC...  ?

 

Link to comment
Share on other sites

Another option would be to record the package cost to the customer with the specific customer row. A 'current_rate' field or a many-to-many table with `customerID`, `planID`, and `rate` fields. This way you could give discounts or charge somebody more depending on what mood you're in.

Link to comment
Share on other sites

27 minutes ago, maxxd said:

Another option would be to record the package cost to the customer with the specific customer row. A 'current_rate' field or a many-to-many table with `customerID`, `planID`, and `rate` fields. This way you could give discounts or charge somebody more depending on what mood you're in.

I decided to go with a m-to-m before you posted.  Similar to a textbook Orders ==> Order Details <== Products set up where you have a unit_price and a sale_price, I will do the same (as you also suggest) to allow me the ability to keep track of what price I sell a subscription at to an individual.

 

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.