Suggestion (repost): Pricing profile

English Boards Suggestions and Ideas
1

I posted this suggestion some time ago but there was another discussion in that thread so it may have gotten overlooked, and there was no AS reply.

I would like to see if AS can acknowledge reading this suggestion and providing feedback.

PRICING PROFILE would be created, and would include price %-age for Y, C, F, and cargo (in the basic version). In the "advanced" version it could also include onboard service profile.

Pricing profile would be created the same way as onboard profile.

Usage:

Creating new flight, NOW you can select all-service price %-age wise (50-200%) and service profile.

With the PRICING PROFILE you could select the profile e.g. "Pricing for comfort plus with recliner long haul) **fictious profile name**, and in the basic version you would then select the onboard service profile. In the advanced version you would only select pricing profile, without selecting onboard service, as the onboard service would be tied to pricing profile.

Once the flight is created in scheduling, the same way as selecting price %-age and onboard profile applies it to that flight immediately, the same way by selecting the pricing profile its settings would be applied immediately to that flight number being created.

Benefits:

Using various seat types on different planes on the same route would allow applying standardized rate profile to the route.

E.g. I know that with Comfort Plus in Y I charge 105% on <800km routes, 110% on 800-1500 km routes and 115% on 1500+km routes. But I also know that I have recliner shorthaul in C and I charge 90% on <800km routes, 95% on 800-1500km routes, and 100% on 1500+km routes.

Right now the pricing %-age in flight creation is practically useless, because I always have to adjust either Y or C rate manually in the flight profile. That means opening up the flight in new tab (e.g. via "i" icon), calculating, typing, and saving the price.

If there is a pricing profile, I can create pricing profile e.g. "COMFPLS/RECSH 800" with settings 105% in Y and 90% in C, then I can create "COMFPLS/RECSH 800-1500" with settings 110% in Y and 95% in C, and "COMFPLS/RECSH 1500" with settings 110% in Y and 100% in C.

After selecting the pricing profile, it would automatically apply the selecting pricing ratio to that particular flight number.

In the advanced version, it would tie the onboard profile to it, so I would select just the pricing profile (which would be tied to onboard service) and would apply both pricing ratio and onboard service profile to the flight number when that flight number is being created in aircraft schedule.

It would allow players to create multiple pricing profiles for use with different seat type son different planes for different distances, and tremendously reducing time required for micromanagement of flights when they are created.

Flight numbers would be tied to the pricing profile, in the same way as flight numbers are tied to onboard service. Adjusting price ratio in the pricing profile would save and adjust pricing ratios in all the tied flight numbers.

2

I will quote Martins Post from the Oficial development board.

On the weekend of February 22nd, the day had come again: eight team members met for the annual team meeting, this year taking place at Leipzig. Besides taking a critical look at the past year, this year’s focus lied on listing, sorting, prioritizing and concretizing all existing and conceivable features.

 

Basically, one thing became clear: Our ideas would suffice for several years of development - 24/7. Therefore, we had to pick only a narrow selection of features for our short- and medium-term development schedule. It looks like this:

The core of medium-term development will be an entirely new concept for demand calculation and distribution. This can be seen as an experimental endeavour. On the one hand, it might solve lots of problems we are currently facing, on the other hand, we don’t know for sure whether it will work the way we image it. So we will spend the next months working on tests and prototypes in the background for this feature complex. As soon as we are sure that we are on the safe side regarding performance and concept, you will hear from us in this log.

 

As this process may take a long time and there would be no visible development, we also decided to parallelly implement features that are not related to the new feature complex. This includes several interface improvements, the revision of single features etc.

 

Additionally, we can finally provide some news concerning the aircraft configurator which we announced over two years ago. There’s reason to hope that we will finally have correct formulas for fuel consumption, payload, range and required runway length this year. These are currently in alpha stage. As soon as we know that all formulas are working as intended, we will recycle the existing code and implement it. After all, the code was almost complete when we first presented the feature back in Frankfurt.

 

Another component that’s currently in development is flexible scheduling - in theory, this allows to create schedules that are not assigned to a specific aircraft. This would address several long-wished features, like an easy change of aircraft for an existing flight, more flexible turnaround times and even delay management and possibly more realistic maintenance with longer checks. But today, these are dreams of the future. Right now we are only working on a foundation for features like these. What we plan to implement sooner is the option to move flight schedules to different aircraft and more useful transfer flights, maybe even scheduled automatically.

 

An additional advice: as mentioned above, we have collected more or less all features of AirlineSim on a single long list. Every suggestion we received in the forums or via email can be found on this list or is in some way related to a point on it. At the same time it’s rather obvious that we can not implement everything at once but have to work step by step. So please don’t fret if your suggestions are not implemented in the near future or declined due to upcoming development - we will get to it sooner or later  :)

 

Expect more information on all of the topics above as soon as there is something new to show.

 

 

So all in all, even if we are not answering every post we are reading in the Forum and make our notes and discuss those things in team meetings. I highlited these passages in Martins statement  because your suggestion is part of the easier scheduling/ making the game a bit more user friendly. Saying that, one of the foundation and main Principles in the game is that we purposely don't want a game that can be managed by 3 clicks. You should only have a size of an airline that you can handle. So your suggestion is noted and we have and will have long discussions on what can we simplify in the game and what features we don't want to be modified because to keep the standard and realism and complexity in the game to make it more interesting to come and look every few days at least how your airline is doing. In other words we will see what the outcome will be. It will take some time and of course everything new will be announced by Martin or SK as usual.

3

Thank you.

My point is, there is already "default price", which sets up price for all the flights on that route.

There is pricing tool that changes prices of all flights in a certain class, on a specific route.

There is a %-age tool in new flight creation, as well as selecting service level.

Implementing at least basic version of pricing profile (without linking to service profile, just %-age ratio for Y,C,F, cargo) goes along the lines of the tools that have been implemented already.It is actually combining them and only adding very little. It is combination of pricing tool, and price-selection option when creating the new route.

It is like putting 4 price-selection options when creating flight number (50%-200%) for each Y,C,F, and cargo on flight creation tool, but rather than putting 4 selection tools there, combining them into single one.

P.S. If, for whatever reason you decide that the pricing profile makes the game "too easy" (which I do not thing, again, that it would make it so much easier, it would only reduce certain redundant steps), or if that would take long development time, could you at least (in the meantime) implement 4-pricing ratios (Y,C,F,cargo) when creating new flights, instead of a single one? That would not be that much difficult, just adding some HTML code, and instead of programming a routine "change all rates by X%" it would have routine "change Y by X1%, then change C by X2%, then change F by X3%, then change cargo by X4%". Just a bit HTML programming which could be implemented pretty fast. Again, this would be an interim solution, because pricing profile would be the solution.

P.S. EDIT: At this very moment, players must make decision about what service profile to use, and how much more to charge on that route. That means they have to take into consideration plane, seats, service, AND competition, many times consulting ORS. I do not see a difference in "making game easier" if I have to calculate manually the ratio, or the computer does it for me. It is me who must decide how much more to charge (e.g. I have better seats in C so I can charge 30% more, etc, but this route is very short so I can only charge 20% more because it is expensive to have 3 bars in business on 500km route, so I only have 1 bar, and therefore even though I have better seats and can charge more, I cannot charge the same surcharge as I would do on 1500km route with 5 bar service in C, etc.) The "logic" that goes into the decision is player's NOT the computer's.

So if a player already makes that decision, why make him spend even ore time clicking and clicking.

This is a strategy business/simulation game, not a clicking game. :)

One more thing, a real life analogy:

An airline creates groups of fare buckets and puts inventory of multiple seats in every fare bucket. It does not create different fare bucket for every seat. And when the airline decides to increase/decrease tariff for a fare bucket, it changes tariff for all seats inventory in that fare bucket. It does not go seat by seat changing the rate for every single seat. (yes, an example from a different area, but shows "logic" of grouping).

4

So all in all, even if we are not answering every post we are reading in the Forum and make our notes and discuss those things in team meetings. I highlited these passages in Martins statement  because your suggestion is part of the easier scheduling/ making the game a bit more user friendly. Saying that, one of the foundation and main Principles in the game is that we purposely don't want a game that can be managed by 3 clicks. You should only have a size of an airline that you can handle. So your suggestion is noted and we have and will have long discussions on what can we simplify in the game and what features we don't want to be modified because to keep the standard and realism and complexity in the game to make it more interesting to come and look every few days at least how your airline is doing. In other words we will see what the outcome will be. It will take some time and of course everything new will be announced by Martin or SK as usual.

I don*t want to push the suggestion, as I basically agree, that it is already recognized and discussed by the team.

However, I am a bit concerned about the underlying argumentation, why this feature might be implemented or not. You are saying, it has to keep realism and complexity. Fair enough. But further your are saying, that features that reduce clicks are checked in regard of the reduction of limiting growth. To give an example:  Today, there is a process, that needs three clicks, that can be easily reduced to one click, saving 1 hours a month per 100 aircrafts, without effecting realism, that wouldn*t necessarily be implemented for the reason of limiting growth?

I think that*s quiet a principal decision, so please correct me, if I got you wrong.

5

As said before ... we are discussing these things but as you also know we all have sometimes different opinions plus there might be other things involved like from the programming point of view. All those factors need to be considered and then we will find within the team an agreement. My statement above was more general speaking and not reffering to 100% on the suggestion of rubiohiguey2000. There has been some improvement on those things in the past few month ..... but we have a game philosophy and for example there has been suggested that we should show the demand that exists on the routes.... that is something that we won't do. But if you send us an Idea via supportmail or place it here in the forum we will read it and we will discuss it and then will decide it it will be implemented soon, if it will be combined with other projects where it fits at a later date or we will not consider it for the moment. 

6

Thanks for the comment. I will get back to the point when it will be more relevant, i.e. less abstract.