Price management update

[RibeiroR]

Well, today is only possible to change prices of the routes in pairs and the overall price of the entire company, it would be useful to add the setting of prices for routes based at the airport base (per hub, specific airport), so if i wanted to just raise or lower the prices from that one airport, do not need route by route or modify all airports unnecessarily

Ex.
I have 3 airports base...
KJFK, KMCO, KSFO, but i just want to modify the all prices that start from KMCO
I do not need to do single route destination pair or all routes at once.

[d2031k]

Just what I was looking for

This option would be extrememly useful as I want to reset my prices system-wide, but I want to retain low prices at 1 hub.  Currently this means I will have to go through around 80 routes and that's not fun 

Cheers,

Dave

[raptorva]

+1 to this idea and I'd also like to add the option of adjusting route prices for specific aircraft type only.
For example I want to raise my 767 prices on a route and yet leave the current price for my MD-80's that are also flying on the same route.

[ICEcoldair881]

+2, one being for the original idea, the other being for raptor's idea.

[Danilo .S.]

+1 ... this option would be very useful  i need it
modify prices by specific airport at once

[RibeiroR]

 
haha, a month to feedback

[pkarbach]

Both ideas (base specific and a/c specific pricing) are great!

I would make one further suggestion as far as pricing is concerned:

It would be great if pricing over time was tracked. One MAJOR advantage would be the possibility to compare price vs load factor in order to "fine tune" the prices.

[Danilo .S.]

Both ideas (base specific and a/c specific pricing) are great!

I would make one further suggestion as far as pricing is concerned:

It would be great if pricing over time was tracked. One MAJOR advantage would be the possibility to compare price vs load factor in order to "fine tune" the prices.

yeah, great
maybe compare your prices vs standard prices will be fine

[RibeiroR]

yeah, great
maybe compare your prices vs standard prices will be fine

i think, this is already possible... in price page, select the route pair and click standard prices, 

[Sami]

Further threads for reference on dev.:
https://www.airwaysim.com/forum/index.php/topic,26791.0.html
https://www.airwaysim.com/forum/index.php/topic,17303.0.html
https://www.airwaysim.com/forum/index.php/topic,20363.0.html
https://www.airwaysim.com/forum/index.php/topic,26092.0.html
https://www.airwaysim.com/forum/index.php/topic,21513.0.html
https://www.airwaysim.com/forum/index.php/topic,18101.0.html
https://www.airwaysim.com/forum/index.php/topic,15689.0.html
https://www.airwaysim.com/forum/index.php/topic,18101.0.html
https://www.airwaysim.com/forum/index.php/topic,14410.0.html
https://www.airwaysim.com/forum/index.php/topic,11071.0.html
https://www.airwaysim.com/forum/index.php/topic,2671.0.html
https://www.airwaysim.com/forum/index.php/topic,15863.0.html
https://www.airwaysim.com/forum/index.php/topic,27731.0.html

[castelino009]

its a great idea,

but I think what's needed is when creating a  new route we have to have a choice of 4 tick boxes ( regional, domestic, medium haul & long haul) . So when we go to raise the prices we have option of raising prices for all or raise by  route specifics (above 4 options) or by class wise (as we have now).

Hope you get what I am on about Sami.

Cheers
VJC

[Sami]

Just my notes / collection of what has been talked (feel free to add if some selection / adjustment method of prices is missing):

SELECTION

per base
per aircraft fleet
per aircraft (reg/msn)
per aircraft model
per airport
per LF
free selection checkbox
per route type (dom/lh/sh)
per departure local time



ADJUSTMENT OF SELECTED ROUTES

per travel class:

free sum
+/- %
+/- certain $
reset all
reset selected
reset all but selected



ADJUSTMENT OF ALL ROUTES AT ONCE

per travel class:

+/- %
+/- certain $
reset all




And price management will be own page, since it cannot be neatly integrated into route management page due to different selectors/filters; but route and price management pages will be interlinked so that you can do basic price adjustments from route pages too. In the first step it's interface update only, and in the next step later on the concept of default prices will be removed / changed to price recommendations of your staff, and possibly also more revenue management style features and competition info.

[Curse]

Sounds good so far, sami!


I'm not sure if it would be too much automatism, but maybe a

"always adjust with inflation/deflation" check box.


So a route with standard price would be always lowered or increased when inflation hits - but also routes with (for example) + 35% would be increased or decreased accordingly to inflation.

[dasherhalo]

Sounds good so far, sami!


I'm not sure if it would be too much automatism, but maybe a

"always adjust with inflation/deflation" check box.


So a route with standard price would be always lowered or increased when inflation hits - but also routes with (for example) + 35% would be increased or decreased accordingly to inflation.

I think it's a great idea. Surely it's not too automated to be able to link your prices to inflation increases - it's an idea that I've thought would be useful for a while, though with all the other price management features coming, it probably won't be as essential.

[LemonButt]

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

[KEMKid]

That's what I was coming to comment on: the need for Price Management by aircraft type. As a jet and a turboprop don't have the same operating cost, you should be able to set them separately.

[LemonButt]

I think I've got the solution for a super simple price management system anyone can understand.

The basic hierarchy is the following:

Pricing Model
-Rules
--Conditions

There could be multiple click and deploy pricing models to meet goals, such as Max Profit, Max Marketshare, etc. that will eventually get into business plans (LCCs, ULCCs, Legacy, Regional, etc).  Rule conditions will be processed line by line, so if the first condition is satisfied, then it goes to the next, and only if all conditions are satisfied so the final pricing adjustment happen.

So a sample for Max Profit would look like this:

Pricing Model: Max Profit
-Rule: Increase High LF
--$flight[time] >= 500
--$flight[time] < 2300
--$flight[load factor][all] >=  90%
--price[all] = 1.05

-Rule: Decrease Low LF
--$flight[load factor][all] <= 60%
--price[all] = 0.90

-Rule: Increase C Fares
--$flight[load factor][c] >= 50%
--price[c] = 1.10

The first rule checks the flight time to be between 500-2300, then checks the load factor for all classes combined.  If met, the price gets multiplied by 1.05 (a 5% price increase).

The second rule checks for low load factors and multiplies the price by 0.90 (a 10% price decrease).

The third rule increases C class fares where C class load factors are greater than 50% with a 10% increase.

The beauty of doing it this way is the flexibility.  Since multiplication is commutative (i.e. it doesn't matter which numbers you multiply first as you will always get the same answer no matter the order) we don't have to worry about what order the rules process.  So if a flight is >90% LF and you increase prices by 5% (1.05) and have C class LF >50% and increase prices by 10% (1.10) the net result would be a 15.5% price increase (1.05 * 1.10 = 1.155).  Obviously, there should be some additional rules in place to decrease the C class prices to ensure we don't have runaway price increases.

Since we have conditional lines, we can add as many conditions as we want without having some ridiculously long string of ands and ors (they could be added in later though).  Since we are using various variables such as load factor etc. we can expand the system to include additional variables in the future as requested, such as number of seats on a route or aircraft size or number of seats etc.  Pricing updates could happen when an aircraft goes into an A or B check (I prefer weekly A-check updates, but may be too resource intensive).  This system would be simple enough for beginners to use, but robust enough for power users to go crazy.

So for an initial roll out, we'd just need a front end interface with a few simple variables to get started, such as flight time, load factor, and route image.  Anything more complex than that should be easy to implement in the future.

[LemonButt]

sami--would it be relatively easy/possible to add average default price to the price management page?  This would help players figure out if they need to reset prices due to inflation, but also give players an idea as to where their prices are at currently on the aggregate.  Something like the attached screenshot with the new values in red behind average price.

You could also add this to the statistics page and display the most expensive and cheapest airlines in the game world, which would help other players better understand what they are competing against without divulging specific prices.  Every airline IRL has a price "reputation" such as Ryanair being ridiculously cheap and this would be roughly the equivalent of that.

You could also tweak the basefinder to factor in airports/airlines where pricing is way above average, which would indicate the market is ripe for a new competitor to enter.

[Sami]

No, the whole concept of default prices will be faded away (and hence any % or $ comparisons vs. default won't happen)... (discussed previously, .. somewhere)

[LemonButt]

No, the whole concept of default prices will be faded away (and hence any % or $ comparisons vs. default won't happen)... (discussed previously, .. somewhere)

I understand, but certainly you don't plan on having every player inputting a price on every route?  Even if you don't compare against the default price, perhaps a value comparing against the average price on the routes you fly?  So if you fly LHR to JFK and the average price is $1000 and yours is $1100 then you would simply do sum(your price on all route pairs) / sum(avg price on all route pairs) = your pricing vs average.

This would compare your pricing against everyone else's without using the default values.