Connecticut offers a CT Summer Free at the Museum program where museums get grant money to cover the cost of adult tickets that get purchased with children's tickets. The exact discount is "1 Free Adult (or Senior) with purchase of Child ticket."
Last year we set this up as a source code that was attached to a pricing rule. That works great for our online sales (and we plan on doing it that way for TNEW this year), however for in person sales it was difficult for our VSA staff to constantly switch between Source Codes. They would forget to switch back in between sales and our data coming out of last year is a little skewed because of it.
To make their lives easy, I just want to set up a discount. The problem is it looks like there is no way (as far as I understand) to only put the discount on X number for each ticket type. It'll let me give a 100% discount on the adult ticket type, but it will not limit it to only 1 ticket.
For example, if a VS Associate sells 2 adults and 2 children, we only want the discount pulling off of one of those adult tickets, not both.
Is it possible to do this via discounts, or are we stuck using the Source Code attached to the pricing rule like last year (which wasn't useful and was difficult)?
Hi Chelsea,
At the Wadsworth, we only offer this discount (and many others) in person, not through TNEW - primarily because of these types of difficulties. We just use a separate Parent ticket type and rely on the front desk to administer the program correctly. Generally, though 90%+ of our sales are walk up!
We're about 50/50 here at NBMAA (though I'd love to get more online pre-sales).
So at the Wadsworth your VS staff sells, for example, the 1 adult and however many kids, and then does the second adult in a separate order? We were doing it that way for other things when we still had Altru and found that method just as tedious and time consuming (and our patrons hated it).
No, they are all still in the same order. We would have 1 Adult ticket, 1 Parent ticket, and 2 Youth tickets.
Ah, so you guys just created another Ticket Type. How do you then report on it later? Do you just have to remember that Parent Ticket = CT Summer Free attendance? Since we used a source code last year we were able to run a discount report that had CT Summer Free specifically labeled.
I pull most of my numbers using Analytics, so I just change the time frame to the relevant dates and it totals the Parent tickets. We also use the Ticket type during Festival of Trees and sometimes Fine Art and Flowers but thankfully none of them overlap so reporting is clear.
Ok, that might work for us. Do you just double the number then to get the number of kids as well?
Because we run ours where the number of kids is unlimited per 1 adult (since here kids 12 and under are free anyway). Our Devo and Marketing departments want total number of patrons participating in CT Summer, so kids, adults, seniors...everybody. This is why it gets so complicated. lol
Ah, okay, I haven't been asked for that level of specificity, just totals and revenue for over 18 / under 18 for the application, then program participation for our reporting. We offer free admission to youth 17 and younger so it dovetails nicely with how the program is setup and I count everyone. I use the parent ticket type to figure out how many adults the program covered and the lost revenue. I haven't been asked to provide information about any members of the party who did pay.
You can accomplish this with a Multiple Price Type rule, which is triggered based on a combination price types purchased together, such as a mix of Adult and Child tickets.
This should get you a rule that is automatic with no source codes required. I did a quick test in my system just now and it worked pretty well.
Normally I would love this, but it is for CT residents only. We do get patrons that would fit this description from out of CT (who wouldn't be eligible for this pricing rule).
I see. You could set up CT resident price types to use during the time period when this offer is active, and then only have those price types trigger the rule. It would increase your setup somewhat, and require a bit of extra training for your operators, but the advantage to going that route over the source code route is that it's not sticky. The choices they make in one order wouldn't affect the next order. And if they make the wrong choice (choose the resident price types when they shouldn't or don't select them when they should) it would become apparent fairly quickly based on the application or non-application of the rule. You could even use pricing rule messages to make it clear what they are selecting (the message displaying with the rule is applied as well as a rule that just triggers a message when a non-resident price type is selected to ask the operator if that is what they meant to do).