Little bit of background. We have a custom website with custom code to handle our member on sale each year. The code determines if the logged in patron meets the criteria in order to purchase tickets. When a patron arrives at SYOS, if logged in and meets the criteria, they continue as normal. If not logged in, they are prompted to. Once logged in but not meeting the criteria, they are presented with a popup to explain that we are currently only accepting orders from x member level and giving info on when other levels as well as general public can purchase.
The snag...for our 2019 member on sale, at the point of receiving the popup, those not at the proper level can choose to continue, but have limited zone access - essentially access to our lowest zone in two of our venues.
Our initial thought was to create a source code, tied to a new MOS that has access to some new price types that are exact copies of our regular price types (that can't be altered because our members still need to be able to use them to purchase) but are limited to the zone we want to offer. Login with the promo code will prompt MOS switch and will limit the zones.
The problem with that is that we have 7-10 standard price types that would need to be copied, therefore adding those 7-10 additional price types to our pricing grid that is already way too large. Can anyone think of any way to accomplish this WITHOUT creating new price types and using Tessitura native functionality.
Michele
I think Allocations may be what you're looking for.
The only problem is that we do not use ranking. We haven't really explored allocations at all so I may not be as up on how they would work. Would you be willing to expand? Note that we are also still fully SOAP.
You mean you are not using Web Rankings, or just Rankings generally? You are using different Modes of Sale, though, right? Different allocations can be attached to different modes of sale, and then those can be used to control which seats within a performance are available to that Mode of Sale. So API manipulation necessary.
Thanks Gawain! We're going to try this route.
Hope it helps! It does sound like the right thing for your project. We've not actually used allocations extensively in the past, but are starting to use them with the Goldstar integration.