I am investigating how we can have our staff book their comps and staff rate tickets through tnew. In testing, I’ve created a “staff tickets” mos, and was going to use an offer to open that mos and limit the number of staff rate tickets (understanding that it’s per order and trusting the honor system). Then I was going to use a pricing rule based on staff constituency and an exclusion list for the comps- because I can have that exclusion list generate every so often and more tightly control the comp limit per customer.
BUT, here’s the stumbling block I have. Full time staff get 4 comps and 4 staff rate tickets, and part time staff get 2 comps and 2 staff rate. Am I correct in thinking that I would need to have two MOS - one for the full time staff, and one for the part time staff? Because if I have two similar offers on one mos (“get 4 staff rate tickets; get 2 staff rate tickets”), it’s going to apply the top one.
Or, if anyone has any better ideas, I’m all ears!(Cross posting to the ticketing forum, too)
If you're using Pricing Rules instead of Offers, this should be no problem, you might not even need an MOS? If you have four Pricing Rules in this order?
Now, a lot of questions: do you have specific staff comp allocations (we do)? Is that limit per season or per event? Are you v15 or v16?
Thank you, I don't know why I was having such a brain block. We *don't* currently have a specific staff allocation, though I like to say that's always subject to change. So, I'm considering a MOS shift for that reason, as well as because we only offer staff tickets for preview performances- If I deep link an offer that does an MOS shift, the calendar will only display dates that can actually be booked for staff tickets. The ticket limits are per production, which I can limit fairly tightly using exclusion lists in the pricing rule (set up a sql job to generate the lists every x minutes). We're still on v15, but am already looking forward to the options in 16 ;-)
Kathleen, I assume your SQL Job executes an existing non-custom stored procedure that regenerates the list. What is it and what are the parameter settings? I like your concept of using the SQL Job as a work around the issue of the limitation of a list can only generate every hour.
super simple :
exec rp_generate_list@list_no=xxxxx and then just schedule it to run however often you want!
Well, that is too easy. Can't do that. lol. I appreciate the information!
I don't have any rules quite like that running, so take it with a grain of salt. There's something about tickets being reviewed for one rule maybe not being reviewed by a second? I don't quite remember how that manifests, but it seems like it might cause some problems here.