IMO this should function similar to SQL statements where players can make their own rules. This would allow for maximum expansion in the future and allow players to manage pricing the best. So you could simply have a list of rules ordered by priority, then simply go from the lowest priority to highest (the highest would overwrite the lowest). So if you had 3 rules with the first being highest priority with actions (INCREASE, DECREASE, or MODIFY--modify would increase/decrease based on the inputs):
1. "MODIFY flights BY 1% WHERE departure>5 and departure<23 and target=85%" (this will increase prices +1% routes with LF>85% and decrease prices -1% for routes with LF<85%)
2. "DECREASE flights BY 1% WHERE marketshare<(myseats/allseats)" (this will decrease prices on flights where you aren't getting proportional marketshare)
3. "INCREASE flights BY inflation WHERE price<suggested" (increase prices by inflation rate where they are less than suggested)
These rules could be setup to run as a cron job every Sunday for the following week. Thus, players could create an incredibly complex revenue management model. There could be 3-5 click and deploy models for players who don't want to tinker with it, but IMO if you want to setup pricing in a way to satisfy those demanding it, then this is the way I would do it.
These are the other factors not on your list which need to be considered:
-Route Image
-Seats Avail (airline)
-Seats Avail (aggregate)
-Marketshare
-Maintenance--if a competitor is in maint then LF are artificially high and decieving, thus the reason aggregate seats avail is a must
-Average pax per flight (aggregate pax/aggregate flights) versus absolute pax carried. i.e. if there is a route with 100pax and there are two airlines flying 100seater aircraft for 200 total seats, then the expected value (EV) would be 50 pax per flight. If your flight is only getting 30 pax, you'd want to decrease prices to capture your fair share because your competitor is likely undercutting you.
-Profit margin--if a route isn't turning a certain profit margin, you want to increase the prices most likely
-Route distance--to separate out the short hops vs ultralonghaul and adjust pricing accordingly.
Also, it would be nice to have some of this data stored to measure price elasticity based on pricing changes. For example, if I increase prices by 5% and demand drops 25%, then demand is very elastic and responsive to price changes (i.e. leisure travelers in economy). If I increase prices by 5% and demand drops 1%, then demand is very inelastic (i.e. first class). This is significant in determining pricing and with city-based demand having leisure travel components and business travel etc. it would add another layer of strategy to the game.
IMO I think "blanket pricing" where you adjust all prices per base, per fleet, etc. is way too elementary as we should be thinking in terms of pricing models (i.e. a series of rules used to micromanage that supports an overall strategy) versus a blanket pricing change based on "feelings" or macro conditions. I have custom JavaScript code I wrote to manage my airlines pricing based on load factors and have experienced firsthand the weaknesses in using blanket pricing based on LF. The huge weakness being that your LF will spike when competitors on in a C-check, so then you increase prices and then they come out of maintenance and you're losing marketshare and giving up profits due to a lack of information. If I were able to view load factors and compare it against my seats provided against the aggregate, my pricing decisions would make a heck of a lot more sense. However, that is several clicks away and way too tedious to do for all routes, so blanket pricing it is.
Additionally, a pricing model/strategy opens the door for future expansion with auxiliary fees for checked bags, charging for in-flight food/entertainment, etc. That's it for now, but I'm sure I'll add more to this later
Topic: Price management update (Read 7476 times)
