Hi everyone,
I am starting to investigate using pricing rules to administer our member and patron benefits.
We offer X number of a lower benefit price type per production season, with the number based on the member level.
My understanding is that pricing rules only operate on a per-order basis, not a constituent record basis.
I want to get around this using an exclusion list, with the list being those folks who have already used their allotted number of lower priced benefit tickets for the show in question.
Having not fully thought this through, I think I'd need a dynamic list for each production season for each member level.
I'm worried about the database-tax for scheduling the Generate a List utility for this many lists. And I'm not sure there is a low enough interval for list generation we'd be comfortable with. Even every 5 minutes would not prevent someone from logging right back in to get another pair.
Any other ideas? Or anyone very frequently generating lists for pricing rules yet?
Thanks,
Frannie
If your list is looking at ticket sales, that can be one of the more taxing queries. Alternatively, if it's looking at ticket history it may not be up-to-date.
Pricing Rules themselves are going to let you down here, as well. It's not coming to me right now, but I think there is an issue with pricing rule limits where if you have a limit of 4, and buy three, you'll be allowed to make another order, but with as many tickets as you like (i.e. you could add two more as long as you hadn't previously exceeded 4).
Hi Frannie
Have you considered using rankings?
You could conceivably use a special ranking, which was augmented with the number of special price tix due from the membership, then decremented by one each time one was purchased. Then the pricing rule could be based on that ranking being above zero.
A bit of coding involved, of course (maybe using interceptors, or possibly just plain old SQL, to set the ranking value), and it's subject to the same caveat that Gawain mentions - if you have one left, it'll probably let you buy more, because the ranking hasn't been decremented until after the order is saved.
But possible, I think. (...not that I've done it myself...)
Ken
Thanks Ken & Gawain for the feedback and warnings.
I like the ranking idea - our current benefits administration relies in some part on Ranking and I wouldn't be adverse to using something like that.
I guess I was hoping pricing rules would make this entirely configurable by a front end user (imagine having Box Office be able to configure benefits...!) but that may be too much to hope for.
Ken's idea is really good, I'll have to keep that in mind for future sales we might do.
It reminds me, though: if you need something a little more granular, Tessitura sells a plug-in solution for things like this called "Entitlements".