Dynamic pricing automation?

Hi all,

First time posting on the forum so I'm interested to hear what everyone has to say.

Last year we used a dynamic pricing model based on performances ticket availability and it seems to work quite well. We set up the incremental revenue price maps with their own price map category and would use the performance base price and availability report to see how many tickets were available and then estimate a start date for the incremental revenue price map. 

Although it worked well, we were looking to streamline this procedure and was wondering if anyone has managed to implement an automated solution to dynamic pricing, either through a local procedure or another way?

 

Michael Cuffaro
Systems Integration Coordinator
CTA



[edited by: Michael Cuffaro at 10:22 AM (GMT -6) on 6 Jan 2012]
Parents
  •  

    I have a mostly automated way of doing it, but there are still some kinks to it. I'm actually in the process of reworking the whole thing. It's a bit clunky, and involves a handful of local tables, one to hold the thresholds for each prod_season, one for which pricetypes should be affected, one for any perfs that should be excluded, and one that holds at what level each perf is currently.

    We use the "end the original pricemap, start the new one" method of dynamic pricing, not just adding an additional map that is the difference. We set up all the possible maps on the perfs, with the base having real start and end dates, and the increases having dates far in the past. I have a scheduled job that runs nightly that basically goes through and checks what level each perf is currently on, if it should be on a different one and if so changes the end date on the current active pmaps, and then starts the new appropriate pmaps and changes the enddates to the perftime. 

     



    [edited by: Amanda Freeman at 12:37 PM (GMT -6) on 6 Jan 2012]
Reply
  •  

    I have a mostly automated way of doing it, but there are still some kinks to it. I'm actually in the process of reworking the whole thing. It's a bit clunky, and involves a handful of local tables, one to hold the thresholds for each prod_season, one for which pricetypes should be affected, one for any perfs that should be excluded, and one that holds at what level each perf is currently.

    We use the "end the original pricemap, start the new one" method of dynamic pricing, not just adding an additional map that is the difference. We set up all the possible maps on the perfs, with the base having real start and end dates, and the increases having dates far in the past. I have a scheduled job that runs nightly that basically goes through and checks what level each perf is currently on, if it should be on a different one and if so changes the end date on the current active pmaps, and then starts the new appropriate pmaps and changes the enddates to the perftime. 

     



    [edited by: Amanda Freeman at 12:37 PM (GMT -6) on 6 Jan 2012]
Children