Hi,
On our current custom site - shop.strazcenter.org - we use "donor tiers" and hard-coded logic to decide who should get the donor on-sale content, and when it should appear.
We have two tiers. Let's call them Tier 1 and Tier 2.
Donors are bucketed into one of these tiers by a SQL job that runs every night.
Donor on-sale dates for Tier 1 and Tier 2 are handled using Offers in Tessitura that have date ranges to control when they're considered "on" or not.
When the user logs in to our site during one or both of the date ranges, there is custom code that checks if the user is in one of the tiers, and then acts appropriately based on the tier they are in. This is all hard-coded, effectively saying:
"If the user is a Tier 1 donor and Offer 1 is in effect, present the content for Tier 1 onsale"
This is probably not the best way to do this and we are looking for insight from other organizations regarding how this can be done in a more automated and flexible way.
For example, how would we leverage Tessitura's data and setup to have 3 tiers instead of 2, utilizing the REST API and not having to make code modifications. We'd like to offer 3 tiers for some things, 2 tiers for others, etc.
The question then is: how are YOU handling donor on-sales on your website? Do you only have a member/not member model, or is there a way we can configure memberships, data, etc. to control tiered member on-sales.
Thanks!
For Donor On-sales (i.e. donors getting early access) we use Web Rankings. Donors are ranked based on membership level in Tessitura, and those rankings are then tied to specific Modes of Sale used by the website. Then the Modes of Sale can be used to have staggered on-sales dependent on MOS dates. The plus side is that all the configuration is then done in Tessitura: we're a TNEW user, to the less custom site code the better.
The down side to this is that if you offer an array of benefits for different customer attributes, rather than just a hierarchical list based on a single membership ladder, things get difficult fast. We've been able to use a mix of Web Rankings and Pricing Rules to cover most of it, and then some slightly complicated ranking value tricks to cover the rest.
Our "tiers" of what I call "Web Benefits" are now pretty complex: we have 11 "Web Benefit" Modes of Sale (on top the default web MOS and our web subscription sales MOS), providing a variety of benefits from early onsales, access to special products, access to specific price types and reduced fees.
Let me know if any of that is interesting to you.
Gawain,
Thanks so much! This is exactly the type of thing we're looking for. It makes sense that we should tap into experience from TNEW users because you're not using custom code. We'd like to have our solution work leveraging the existing capabilities of Tessitura.
So yes we are interested in how you are doing that. We don't have complex tiers. We just want Tier 1 donor On-Sales to start on one day for people in a specific rank, Tier 2 to start on one day for people in the ranks defined for Tier 2, Tier 3 the same. That's pretty much what we're trying to do.
So if I understand correctly, we would update the customers rankings on a nightly basis for example, then we create specific Modes of Sale that are tied to the rankings. The MOS dates drive when the performances can be accessed to be purchased.
We don't offer an array of benefits on the website so I don't think we need to worry about the complexity you mentioned - not at this point - but I think your approach opens some doors for us to get creative in the future.
I'm going to have a meeting with our Ticket Sales people and discuss this then meet with our in-house Web developer and the IT director.
Thanks for your help. I may ask you some more questions, but does what I'm describing to you sound like I have a firm understanding of the way forward?
Yes, it sounds like you have it. MOS configuration is all done by the box office, but the act of computing rankings for customers will still require custom code in SQL. You can either do it as a nightly job using SQL Server Agent, or you can add code to a procedure created for this purpose called LP_CUSTOMER_RANK. That procedure is designed to run pretty much every time a customer record is updated, and is generally expected to be used to recompute that specific customer's rank (or ranks).
Your scenario sounds like exactly what Web Rankings was designed for. Basically, if the benefits you want to offer are strictly linear (Tier 2 has everything Tier 1 offers and more, Tier 9 is better than all lower Tiers, etc.) then it's very straightforward. Things become harder if you have a case like "Tier A gives you access to the presale, Tier B gives you access to a discount price type", as a customer can only ever be sorted into one Mode of Sale.
Oh, do you have a custom site?
In any event, a configuration item sometimes forgotten is that new Modes of Sale to be used online need to be configured for the website user group in the Security Tool.