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=====
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