Hello,
Our organization recently finished a crowd-sourced Kickstarter project for our outdoor movie theater events. We were successfully funded and able to get a bigger screen, better audio equipment, and lighting. As part of our Kickstarter campaign, we are giving rewards to those who help fund the project. There are different levels of rewards, but basically, we wanted to give the people that funded it free tickets to a "Films on the Lawn" event of their choice. Based on how much they funded, they would get more or less "free tickets". Ideally, I would like to create promo codes for each reward tier.
For example:
Tier 1 = 2 tickets for any Films on the Lawn Event
Tier 2 = 4 Tickets
Tier 3 = 1 Season Pass
Tier 4 = 2 Season Pass
Tier 5 = 4 Season Pass
Some of these Backers may not be in our system yet. Which is good for us, because it forces them to create a constituent account. Which is sort of why I'm leaning towards promo codes in general and I think they would work great for tickets, it's another story for a Season Pass (not sure how to accomplish this). However, the biggest issue, is the sharing of these promo codes to people who may not necessarily deserve these rewards. So what are some measures we can take to minimize the sharing of these promo codes?
Heck, maybe we don't even use promo codes, there could be another way to do this.
Any advice is appreciated, thank you in advance.
Hi Cody,
If you are on v12.5, pricing rules would be an excellent tool for this. Using constituent criteria on a rule you could set things up so that people automatically receive their comp tickets when they log in to their account so that there isn’t a promo code they can share. To mark people for the different reward tiers you could use an attribute, constituency, or a source. If you use a source, you would promote the source to the constituents at a particular tier and then set the pricing rule to look at promotion source; the result being if a constituent doesn’t have a promotion for the source on his account, he won’t get the discount.
Here’s a link to the pricing rule constituent criteria help topic: http://www.tessituranetwork.com/Help_System_v125/Content/Pricing%20Rules/Constituent%20Criteria%20Tab.htm
For the rule type, you probably need just a Product Only rule, as the only condition on the rule is that they are a constituent marked with the appropriate reward tier. And you’ll need a separate rule for each reward tier in order to manage the sliding scale of comps.
Kevin Sheehan
Senior Technical Writer & Consultant
Tessitura Network
+1 888 643 5778 x 329
ksheehan@tessituranetwork.com
Yep, I always forget about pricing rules. Probably the easiest way to go about it.
Travis
Yes!
Alright I've chosen to go with the Pricing Rules. I compiled a list of constituents from the Kickstarter Backer information and Imported them into Tessitura. Saved all the constituents to a List and used that list as Criteria for the Pricing Rules.
As it stands now, I have 2 Lists of Constituents and 2 Pricing Rules. One for Tier 1 Backers, the other for Tier 2.
However, there is a problem with this system (and maybe I just don't know how to solve this). I can't limit the discount to only apply once per account/constituent. The only limitation I can offer is "Apply Rule Once Per Order Only", but I'd like for the Pricing Rule to apply once per constituent only. So, a constituent can claim 2 free tickets, only once Per Production Season.
Not sure if this is a built-in feature. Any advice?
Current Criteria:
For each of these "1 Production Season" <--- Season contains all performances where the discount should be applied
at these price types "(2 values selected)" <--- Each performance has two price types: Member and Non-Member, discount needs to apply to each
Apply the Rule to a maximum of "2 seats" <--- Limit the number of 'discounts' a constituent on the list can have. In our case I chose 2 because the Tier 1 Kickstarter Backers should only be able to apply the discount twice, whereas the Tier 2 Kickstarter Backers are allowed 4. This issue is this rule applies more than once per constituent, and it's unclear how to give it a limit.