Hey all!
Our guest experience team has implemented a Surprise and Delight initiative where we offer select patrons upgraded seats at no extra charge at many of our shows. Currently, that is done by adding an NScan CSI so the customer is notified upon their arrival and then they are given a pre-printed complimentary ticket for the new seats. Their original seats are not returned and the new complimentary tickets may or may not be booked under the appropriate constituent record.
As the systems admin, I hate this process. :)It double counts the tickets and may not even link back to them to show that they were given new tickets. Plus it eats up inventory we could be selling during the pre-show.
I'm wondering how other organizations doing the S&D for upgraded tickets are doing this successfully. Ideally, I'd like to see this done properly - ie. as an exchange rather than a complimentary ticket. But there are several issues with that.1) Sometimes people don't want the new seats so we can't make the assumption and pre-exchange the tickets before the show.2) Even if we wanted to risk it and pre-exchange the tickets, NScan would give them a bad ticket error when they show up with their original tickets - definitely not the way we want to start their evening!3) If we exchange their tickets on the fly after they walk in the door, we have concerns with the amount of time that will take; particularly if the box office is already overwhelmed and can't address it right away. Would implementing TRBO be useful for this or is that not something TRBO can really do?4) How can we make the revenue balance? I'd prefer to stay away from a dummy payment method to make up the difference because it will inflate our revenue dollars in our reporting and analysis... but that might be the best way. I tested editable price types here but there are a couple of problems there. We have too many varieties of price types (adult, student, senior, youth, packages vs single, etc....) and we definitely do NOT want to make our standard price types editable due to audit concerns. But if we create one new price type to generically handle all of them, we lose the level of detail from their original price type. Also, we have a custom report that we rely on quite heavily for ticket sales and reporting that can't handle multiple prices per price type/zone so our report would suddenly be useless in this case.I think that covered the bulk of my concerns!If you have successfully implemented a smooth S&D program and you'd like to share please feel free to reach out either on the forum or by email.
bhawryluk@winspearcentre.com
Thanks!Beth