Hello network
We are about to delve into ‘dynamic pricing’ for the first time, at least in a properly planned and deliberate way.
(By “dynamic’ we mean changing prices and/or price zone configurations on the fly, to maximise revenue based on actual demand).
An important part of the exercise is reporting on the success or otherwise of these changes, and I am interested to hear any other user’s ideas and experience in this area.
What seems most difficult to track is the point in time when elements change (and I confess I’m not sure I can picture how reporting would look using this as a factor/measure, but thought I’d ask anyway …).
Prices:
It feels like there are a number of ways to approach this.
1. Time-out one Price Map and replace it with a new map by ‘starting’ one map when the other ‘ends’. (Added benefit would be you’d retain the history of the changes in the price map detail.)
Does anyone do this routinely and are there risks with changing a price type’s mapping mid transaction, as our plan potentially includes making these changes during a hot on sale? Particularly concerned about how exact the start/end date functionality is as we don’t want to have both maps active (or for that matter inactive) at the same time, even momentarily.
2. Re-map the price type by replacing one map with another. This seems easier in terms of a setup action, but can the time that a replace/change is done in this way be reported on?
Zones:
We are considering the idea of using Holds Codes to hold a buffer around certain seat areas, and then changing prices by re-Zoning prior to making the seats available (releasing the “buffer” codes).
I notice “Seat History” does time stamp this Price Zone Change; has anyone done before-and-after type reporting on this action?
Thanks as always for any comments/insights.
Peter Nelson
Business Analyst, Information Systems
T 02 9250 7180 M 0401 714 246
Sydney Opera House Bennelong Point
GPO Box 4274 Sydney NSW 2001 AUSTRALIA
Please consider the environment before printing this email.=====This message is intended for the addressee(s) named and may contain confidential information.If you are not the intended recipient, please delete it and notify the sender.Views expressed in this email are those of the individual sender and are not necessarily the views of the Sydney Opera House Trust=====
Re-map the price type by replacing one map with another.
It's my understanding that this should not be done with pricetypes that have been used, which would make it an unlikely option as a route to dynamic pricing. You also couldn't report on if/when it got changed as far as I know. There's no create_dt or last_updated on tx_perf_pmap.
We just started doing dynamic pricing and went the "end the old pmap start the new one" route. We decided to have a script that runs nightly while web sales are down anyway to eliminate the possibility of someone, say, browsing for seats at one point during the day, coming back an hour later, or even 15 minutes later and finding the price has gone up. This eliminates the possibility of it changing mid-transaction, and we thought, avoided a potential customer service issue. Plus box office staff can use the phrase 'the price today is', which I think some others have mentioned doing as well in other threads. But if you wanted the price to go up during a hot onsale, then that approach wouldn't really be of use.
The other option I know of is just adding a second pmap that is the difference between the old price and new, so they're active simultaneously and add up to the new price. That makes it easy to separate the added amount, but the downside is if the second pmap has category "tickets" seats are double counted in season overview and some reports, and if it has a different category, the money shows up under "other" instead of tickets. Probably simpler for setup, though.
Hi Peter!
We usually use Option #2 for pricing. It is a lot easier and I don't have nightmares about accidentally having the times incorrect and accidentally selling tickets for the wrong price. I know a lot of people follow your Option #1, but I'm just not as comfortable with that way. We also like Option #2 because if we have exchanges we want the new tickets to sell at the new price and if it is date driven if you kept the exchange in an old order the old price would still be honored based upon the order date. Another thing that we now do with Price Types as part of our settlement process when the performance is being taken off sale is take the original price maps and create a Price Type to be for historical purposes that we then mark as "Base Price" so that T-Stats will show incremental income. Basically, the "loss to discount" measure in the seats cube would show you the extra money you made by increasing prices.
Regarding Zones we have been known to purposefully keep some sections off sale so that the house loads the way we want. That being said, we usually just have a zone at one price and then change the whole of it or a portion of it later if we want. We do not have SYOS, so I know that if you change zone configuration like we do it might not work properly with SYOS. When we move to SYOS I plan to have lots of zones so we can really micromanage them if necessary. We are doing what we can to maximize the revenue for each show.
Have fun with Dynamic Pricing!
Nicole
We use the second option currently, applying additional price maps as the perf hits 70%, 75%, 80%, 85%, 90%,95%, for example. These "On Demand" price maps share a designation and remain in the "Ticket Price" category. I use that designation to keep our $ and seat counts true in the reports and season overview, counting all designations for $ and excluding the "On Demand" designation for seat counts. Our NScan availability is off but our Front of House folk are flexible, thank goodness.
Our SOP is to end the old price map at 11:59:59 and begin the new price map at 12:00:01 that way we are at a low traffic time. And we don’t have to turn the show on and off to make the changes.
So far it has worked well for us.
The other thing that we do is keep the original Base Prices “Clicked” that’s for the Season Overview’s budgeting functionality. Makes quoting prices a little tougher but we train our staff to not use the “hover” method.
~Ginger M
TPAC - Ticketing Manager
desk 615.782.4063
cell 615.473.0027
In accord with our PCI compliance agreement, TPAC email is now set up to bounce any email
with a credit card number in the body of the message. Please call us to make any such payments.
From: Tessitura Ticketing Forum [mailto:forums-ticketing@tessituranetwork.com] On Behalf Of Chris Hipschen Sent: Thursday, April 07, 2011 1:27 PM To: Ginger Muse Subject: Re: [Tessitura Ticketing Forum] Dynamic Pricing - best practice for reporting
From: Amanda Freeman <bounce-amandafreeman5080@tessituranetwork.com> Sent: 2/11/2011 2:51:30
This message was sent automatically to you by www.tessituranetwork.com because you subscribed to the Tessitura Ticketing Forum. You may reply to this message to post to the Ticketing forum or visit the site to search, read and post to the forums. In the interest of keeping the forum posts from becoming cluttered, we encourage you to delete previous message text from your reply before sending. Thank you!
We also end the first map and start the new price map during off hours. We have made the change during a regular work day as well without issues, but agree that keeping it to off hours helps avoid any complications.
Has any one found a good method of indicating in any reports which performances have been moved to a dynamic price? We utilize sales notes for the Box Office Staff but when pulling reports we have to cross reference it with an external "Dynamic Pricing" cheat sheet. We'd like to have everything show up in one place, but not sure if that's possible.
You could add the sales notes to display on your sales report if the sales are broken down by perf.
Thanks Amanda! Is there a Tessitura report that already has that option or would that need to be added in?