Unlocking Ticket Price in TNEW

Rashida,

This sounds more like Offers than a Pricing Rule.  If you add the Special price type to the performance and make it available in the MOS, you can then put two Offers on that MOS and Price Type.  One to lock it up with a hidden source code (e.g. an internal one that is never shared online and thus will never be entered by a patron) and then a second source code which is tied to your promo code.  Thus, when a patron enters that promo code, it will unlock that Special price type but the regular Single Full option will still be there for the patron.

Hope that helps!

John A. Moskal II

Hi John,

Thank you for sharing! Could you say more about what you mean to "lock up" a price type using a hidden source code? I have an offer set up to make the student ticket price available alongside the standard ticket price with the use of a certain source but it is not working.

My guess is that maybe its because the special price type is on the list of excluded price types in the TNEW backend. I've set it up this way because otherwise, the special price will appear as an option to everyone. So based on your explanation it sounds like I might need to remove the special price type from the excluded list in the TNEW backend and instead hide the price using the hidden source code created in an offer. I hope all that made sense...

Thanks!

Rashida Asante-Eccleston,

Basically you have the idea correct there.  We have an Appeal that is just called "Web Master Key" which has one source number in it that is never promoted to anyone and never shared with anyone.  Then, we associate all of our discounted price types with our Web MOS and the TNEW web usergroup.  That way, anytime we want to make a new discount, no one has to worry about which price types are associated with which MOSes or the web usergroup.  What we then have to do is simple.  On any performance where we add a discounted price type that we do not want to be available to the public OR require a MOS shift, say for example a Single 20% Off discount for a group of people in the community using the promo word "local" is add that price type to that performance and then add 2 offers.  The first offer ties it to the one source number I mentioned above.  The second offer ties it to the "local" source number.  Thus anyone who enters that promo code can access that price type, and anyone who has not entered that promo code cannot.

One of the key benefits to operating this way is it allows us to not have to worry about start/end dates to the price types and when they might be active in which MOS at which time for when staff have to worry about exchanges or some customer service reason after the fact.  The only place you have to control the start/end date of the promo is in the Offer and Source Number.  The locking Offer we set from the moment the price type is active until it is no longer active.  So it truly is only available for those who have the second Offer.

By no means is this the only way to operate.  But this is our primary method of operation.

John A. Moskal II

Hey Rashida,

Everything you say in your original senario from 

Patron enters promo code

Promo code unlocks Special price type

You have to have the Special Price type locked in the first instance by a (i call generic) sourcecode.  Price types are visible by default

(I DO have an entry in TR_WEB_SOURCE_NO for our hidden promo/source number, so that I can use it for testing, because sometimes it is helpful to see exactly what the web is pulling no holds barred.  But again, no one knows that, and believe me, I would notice if orders started being placed with that source number anyway.)

(I DO have an entry in TR_WEB_SOURCE_NO for our hidden promo/source number, so that I can use it for testing, because sometimes it is helpful to see exactly what the web is pulling no holds barred.  But again, no one knows that, and believe me, I would notice if orders started being placed with that source number anyway.)