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.
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 :P
Cheers,
Dave
+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.
+2, one being for the original idea, the other being for raptor's idea. ;D
+1 ... this option would be very useful :) i need it
modify prices by specific airport at once
:P
haha, a month to feedback
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.
Quote from: pkarbach on October 18, 2010, 09:58:20 AM
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
Quote from: Danilo .S. on October 22, 2010, 02:08:02 PM
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, ;)
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
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
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.
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.
Quote from: CUR$E on February 15, 2014, 01:14:51 PM
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.
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 :)
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.
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.
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.
No, the whole concept of default prices will be faded away (and hence any % or $ comparisons vs. default won't happen)... (discussed previously, .. somewhere)
Quote from: sami on July 29, 2014, 06:38:25 PM
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.
Quote from: sami on July 29, 2014, 06:38:25 PM
No, the whole concept of default prices will be faded away (and hence any % or $ comparisons vs. default won't happen)... (discussed previously, .. somewhere)
My understanding is that the ticket price is a basic function of a line - slope intercept:
y = mx + b
Where:
y - is the price
m - slope - price per nm
b - intercept - base price, distant independent, to pay for passenger handling, customer service, landing fees etc.
x - distance
deriving these key variables
m and
b is absolutely impossible for average player to derive reasonable values for these, and it is the most helpful that the system derives them for us in form of a default price.
Pushing us into the wilderness by denying us this basic guide will result in a lot of players being completely lost...
Any sort of price management that does not start from this basic formula as a base (automatically adjusted for inflation, general cost of business), and let players go up / down from this base is just going to turn into a dead end, IMO.
Quote from: LemonButt on July 29, 2014, 06:44:23 PM
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.
So if a newb prices his ticket at $100, would you be fine to derive your pricing from that?
Stand back and take a deep breath Jumbo, lol.
I'm just talking about aggregate pricing on the price management page, not individual routes. I'd be interested to know two things. First is how my pricing stacks up to my competitors on a percentage basis--I know my prices are higher, I just don't know if it is 5% or 25%. Second would be the overall pricing for everyone else, i.e. am I the most expensive airline in the gameworld or one of the cheapest? It wouldn't reveal anything about a user's route pricing, but be a result of their overall pricing strategy for all their routes.
For pricing, I believe sami said it would work like pricing for aircraft where there is a low/high suggested price and you can pick a value in between or go wild and price it lower/higher. Nonetheless, I am still a believe in default prices over a range as AWS is already micromanagement hell compared to other airline simulators, which is both a good (immersion) and bad (tedious) feature of AWS. We're paying a bunch of staff to do stuff so being able to set strategy/policy and delegate is the logical next step in improving pricing IMO. This would also allow you to charge dynamic versus static prices. For example, every seat in coach costs $150 right now whereas IRL the first 30% sold might be $100, the next 30% $150, the next 20% $175, and the last 20% $250. The last seat on an aircraft is always the most expensive.
Quote from: LemonButt on July 29, 2014, 08:39:19 PM
Stand back and take a deep breath Jumbo, lol.
I'm just talking about aggregate pricing on the price management page, not individual routes. I'd be interested to know two things. First is how my pricing stacks up to my competitors on a percentage basis--I know my prices are higher, I just don't know if it is 5% or 25%. Second would be the overall pricing for everyone else, i.e. am I the most expensive airline in the gameworld or one of the cheapest? It wouldn't reveal anything about a user's route pricing, but be a result of their overall pricing strategy for all their routes.
On individual route, I doubt that Sami will reveal your competitor pricing - even though, in real life, it is not difficult to find out what a competitor is charging.
Globally, I am sure there are 10s if not 100s of players in the game who did not touch their pricing for a decade. Does it make sense for you to take their pricing as and input for your pricing, even on the routes no one else but you is flying?
Quote from: LemonButt on July 29, 2014, 08:39:19 PM
For pricing, I believe sami said it would work like pricing for aircraft where there is a low/high suggested price and you can pick a value in between or go wild and price it lower/higher. Nonetheless, I am still a believe in default prices over a range as AWS is already micromanagement hell compared to other airline simulators, which is both a good (immersion) and bad (tedious) feature of AWS.
Pricing is micromanagement hell, which could either get better, by giving up the ability to price our routes as a percentage of the "default" pricing, or it could get a lot worse by removing the guide of default pricing.
Right now, at least we have a partial answer to the micromanagement hell: Reset to default, repeat annually, spend more time with your family.
Hi,
i want to add something for better price management. It would be nice to have an selection of the average price for the route. It makes price Management much easier and faster...
SELECTION
average of competitors on route
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
Another one of those features which would just make the game that much better. I agree
Price management is a major issue with the game IMO. It's really starting to annoy me. It's fiddly and unrewarding. I'm starting to dread it, especially with 7 day schedules increasing the number of flights that have to be price managed. There's no logical reason that a 7 day flight has to become a flight multiplier, from a price management perspective.
In any case, price management shouldn't require microing every price for every flight, it should be automated. It's not hard to do. It doesn't have to be triggered automatically, give us a button to trigger it and some options we an set prior to this, such as if an LF if > x%, increase the price by y%.
Why do we have to price resets for inflation? Prices should just match inflation, automatically, unless we want to turn it off, surely. It feels like I'm fine tuning my pricing based on demand, then it either goes out of date because of inflation, or because I have to reset it (for inflation). The only reason I should have to reset prices is because of a change in demand, or because I want to for some reason.
This is a serious playability issue in my opinion. It's getting on my goat BIG time and I would have to consider carefully before I'd embark on another epic GW again based on this, i.e. do you really want to go through the price reset cycle another 100 times?
Anyway, just my tuppence.
Update to my recent post:
It has been brought to my attention that the "Destination view" filter (via number 1 in below illustration) on the manage routes screen, allows updating all sub-routes in one go (via number 2 in below illustration), this alleviates the 7 Day schedule multiplier effect.
(https://i.imgur.com/4tVMjNH.png)
Other aspects of the request stand, just wanted to share in case this was also news to anyone else. Thanks to Groundbum for the info.