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.
How about creating a second, dynamic list for everyone who has claimed the offer. Then modify your original list to exclude anyone who’s already claimed… Gradually, they’ll move from your original list into the second list, and the pool will get smaller and smaller.
Is that a bit Heath Robinson (I think you’d say Rube Goldberg in the US)…? Maybe, but it might work nicely. I don’t see why it wouldn’t.
Good luck!
C.//
X.
Hmm..
To begin testing, I've set up a Dynamic list that Generates with the Criteria:
And it's populated with 5 people (who have obviously bought tickets already). However, I have also purchased tickets using the discount on my account through TNEW, and I'm not being added to this Dynamic list.
I've checked my Orders under my constituent, the order is in there, and I even show up in the "Attendance by Performance" report if I run it for the performance.
What could be going on here?
Hi Cody,
I had this happen with a list when I was testing it, and it's because the database needs to run a procedure to populate the list - and that usually happens at night, when the system isn't busy. Your purchase should show up on the list tomorrow! :)
Amanda
Cody,
There is no standard List Manager criteria named "Bought Tickets", this must be a custom criteria you are using. I'd be happy to help if you want to contact me off line. You can find my phone number and email under my profile.
Amanda,
Does this procedure need to be set up? Or is this something that is built-in to Tessitura?
Terry,
I'm using "Ticket History in Season Production", which is basically, "This person bought tickets." Sorry, should've been more descriptive.
Thanks for all the advice so far!
It happens automatically. Pretty sure your constituent will show up on the list tomorrow!
Hi all,
I wanted to add some clarifications on how pricing rules work with lists.
While dynamic lists are usually regenerated any time they are used by a system process, like a report or another list, pricing rules are an exception. Pricing rules do not trigger the regeneration of dynamic lists referenced by a rule (in order to avoid the potential performance issues of regenerating a list ever time an order is priced). If you need a list used by a rule to have it's contents regularly regenerated, we suggest scheduling the Generate a List utility to regenerate the list daily, twice a day, hourly, or whatever period you feel is appropriate.
Since all the standard list criteria reference the Ticket History, and as Amanda said, the ticket history is updated nightly, there wouldn't be a point to regenerate a list referencing the ticketing history any more frequently than daily.
Based on all of that my suggestion would be to use both the List and Exclusion List criteria on the Constituent Criteria tab of your pricing rules. For the List criterion, you would continue using your Kickstarter Backer list. For the Exclusion List you would select the list of everyone who already bought tickets (this list does not need to be dynamic). Then schedule the Generate a List utility to regenerate the exclusion list daily.
Now this will prevent someone from redeeming the reward today and trying again tomorrow, but it won't prevent them from doing it multiple times in the same day. To do that your exclusion list would need to be referencing more current data. It might be feasible to change your ticket history procedure to run twice a day instead of just once a day (and then you would schedule the exclusion list to be regenerated twice a day). Doing any more real-time excluding is going to require some custom work, which may or may not be worth it depending on how worried you are about abuse. If you are feeling like most people probably won't abuse it, then I would probably just stick with updating the exclusion list daily and then also checking occasionally for the few people who do abuse it and revoking their extra tickets (and also clearly message the limits in the rule messaging).
Hope that helps,
Kevin
Great post Kevin,
I've set up a scheduled list generation everyday at 1am on my dynamic list
Thank you all for your help,
Cody