Pricing Rules for Early On Sale?

Hi there,

I was wondering if anyone uses pricing rules to initiate a MOS shift based on a constituency. We have an early on sale (not including a discount), and segments that qualify for the early access will have specific constituencies on their record. We have been planning on setting up rankings which would be triggered by the constituencies, but the question recently came up wondering if pricing rules could do this instead. 

My understanding is that pricing rules can't initiate a MOS shift without an offer, so I'm expecting to hear no. But I figured I'd ask in case! 

Essentially, what I'm looking to happen is:

1. Patron has a constituency in account

2. When patron logs in, a MOS shift occurs to a MOS that has the product(s) on sale. 

3. All is right with the world. :) 

If rankings is the correct way to manage this, then yay! If you have any other methods, I'd appreciate your thoughts. Thanks! 

Kim

Parents
  • Hi Kim

    We use rankings to *** MOS for our 'industry members', and then have a mix of specific price types only available in that MOS and pricing rules. It works well.

    From memory there aren't any front-end tools to easily add/adjust rankings on constituents so you'll either need to do it manually or get someone to whip together some SQL.

    dgh

Reply
  • Hi Kim

    We use rankings to *** MOS for our 'industry members', and then have a mix of specific price types only available in that MOS and pricing rules. It works well.

    From memory there aren't any front-end tools to easily add/adjust rankings on constituents so you'll either need to do it manually or get someone to whip together some SQL.

    dgh

Children
  • Yeah we currently use rankings for our subscribers to get their discounts online, wiith a SQL stored procedure that runs daily to update constituencies based on purchase history. But that was built by an old employee who is no longer here, and as we're trying to execute this I know that if I just add the constituencies in the rankings will update, but then be wiped out when that stored procedure runs. So we were looking for an easy work around, as adjusting the stored procedure at the moment is proving difficult. Thanks for your thoughts!