Codesharing

[cmdrnmartin]

This subject is starting to come up in the Market Forum, as we begin to partner to open up more routes and hopefully increase are traffic volume.

The following is taken from a post i made on the subject:

If Codesharing were implemented in FLYNet, I would think it would just be a small boost to your Passenger Load.

For example, Two Airlines, X and Y. They form a codesharing alliance and it is noted as such on their VA page on FLYnet. Now at any airport where both X and Y operate out of, their passenger load would be about 10% higher than the usual, because the codesharing would promote increased travel on those airlines.

Suppose X Operates from

CYEG<-->CYYC<---->KSFO

And Y operates

KMSP<--->KLAS<--->KSFO

Flights for X from CYYC to CYEG would have the usual amount of pax, but flights from CYYC to KSFO and KSFO to CYYC would have the 10% additional pax because both X and Y operate from KSFO.

Similarily, airline Y, would have the standard Pax load from KMSP to KLAS and KLAS to KMSP. But the loads from KSFO to KLAS and KLAS to KSFO would have the +10% pax.

Now, suppose airline x

CYEG<--->CYYC<--->CYWG

and Y

CYVR<--->CYYC<--->CYWG

If the airlines were allied, then the route CYVR<--->CYYC for airline y would get a 10% boost, as would the route CYYC<--->CYEG for airline X. However, since both X and Y fly from CYYC to CYWG, then there should be no 10% bonus, since the airlines are competeing, rather than codesharing the route. This system would provide a safety against some unscrupulous person deciding to just make identical routes between cities and then "codesharing" to increase his pax load.

I believe this system allows a moderately realistic implementation of codeshairng.

I don't know if this would be to difficult to implement, but does anyone have suggestions or other ideas for codesahring?

I think this would be a really neat feature for FLYNet, not in the client, but on the website, send out tenders to airlines and form alliances (maybe place a cap on alliances, perhaps max of 5)

Ideas, comments, suggestions?

[Konny]

It's awesome, just what I have been looking for. We already had a discussion about this topic here in the forum, but nobody came up with an idea similar to yours. It's a quite realistic system for codesharing, although I think that in reality there must be a "direct" financial advantage for the airlines, too. I can't believe that they do these codesharings just to make life easier for the passengers

[cmdrnmartin]

It's awesome, just what I have been looking for. We already had a discussion about this topic here in the forum, but nobody came up with an idea similar to yours. It's a quite realistic system for codesharing, although I think that in reality there must be a "direct" financial advantage for the airlines, too. I can't believe that they do these codesharings just to make life easier for the passengers

Heh, Thanks, I was just thinking about how it could be implemented and i just figured this was realistic. The extra 10-15% is the direct financial benefit, having the extra paying passengers makes the route more profitable. More people will fly on an airline that allows them to have less of a hassle. I personnally fly to Reno From Winnipeg quite often, and I book through Air Canada instead of Westjet, because they offer connections and codesharing with United, instead of me having to go hunt down schedule times etc to connect with another independant airline of westjet (Westjet only Flies to Vegas, so I would have to connect with something to Reno on the next day) Im sure in real life theres other advantages, but in the realm of FLYnet, I think the 10-15% (maybe a random number between those calculated everytime you book a flight) is a relatively good simulatr of real life.

Glad you think my idea is good, always looking forward to helping this project! (Slowly but surely adding more aircraft to the database)

Cheers,

[Konny]

Hm, maybe one little thing I would change...
In your example the two airlines form a codesharing alliance and then any airport they both operate from is affected. But I would prefer codesharings which only affect specific routes. Therefore, I would give the airlines the possibility to offer a route for codesharing and if the partner accepts, they both can fly the flight with their own aircafts and the the pax number for this flight and all the flights to the departure airport will be increased by 10%.
Well, something like that

[cmdrnmartin]

Hm, maybe one little thing I would change...
In your example the two airlines form a codesharing alliance and then any airport they both operate from is affected. But I would prefer codesharings which only affect specific routes. Therefore, I would give the airlines the possibility to offer a route for codesharing and if the partner accepts, they both can fly the flight with their own aircafts and the the pax number for this flight and all the flights to the departure airport will be increased by 10%.
Well, something like that

I was just reviewing my idea, and I found that if it was implemented the way I wrote it down, then if both airlines operated a hub, and one of the airlines had a route connecting the two hubs, then the pax loads for every route at the hub increases by 10%. I got to thinking, is that realistic? I figured that the point of this is that more passengers will fly on the airlines, and that needs to be modeled, but how do you put an exact amount on that. I took Calgary and LAX as my two hubs and figured if a 767 flew the route, thats 250 people roughly going to LA. I'm just guessing that about 2/3 of them would be connecting, call it 190 people connecting. Another Hub probably has about 10-15 routes, so 190 over 10 is around 19 people, per each flight. Some more guessing and I figured that 10% was a good estimate on each outgoing flight from that airport (LA) as well as ingoing. But this would mean that the Bridge route, The CYYC to KSFO 767 would be full.

So in light of this, the Bridge route would have 100% all the time, or at least 95% load. The connecting flights would vary randomly each time from 7.5 to 12.5% extra passenegers. Again, if both airlines fly the bridge route, then it should block out the beneficial effect, so no gain of PAX.

You wrote that all flights to the departure airport are increased by 10%, thats good, but shouldnt outgoing flights receive a 10% bump as well? More people would be travelling to the hub because of the partnership/codesharing, so inbound flights to the hub would have an increase in load as well, maybe only 5%, but there should still be a notable increase.

This solution/idea will promote a hub and spoke approach to building route structures, since you will have increased passenger load from that airport on your flights, it makes sense to maximize that at an airport. However, I believe that for each "Hub" you should only get an increase once (so if your allied with 5 other VA's, you don't get +50% pax) +10% should be the max, maybe 15%, its up to you.

Anyways, Im not sure about the specific routes is what im saying, I think its not necessary, if you have that one bridge route to another airport, both airlines will want to maximize their flights out of that airport, so a specific route isnt really necessary, as there will probably only be one.

The benefits of this are:
Promotes Hubs
Safeties Against people using two VAS to fly duplicate routes
Limited benefits (Maximum 15% increase in Passenger Volume)
Perhaps implementation of real world rules, (Canadaian Airlines can not fly US Domestic routes and vice versa, but international is perfectly acceptable) This structure is excellent if that gets added to FLYnet.
Benefits not dependant upon other airline not flying as frequently as you (Because arguments could spring up really fast on that)

One other thought that came to me, if you decide to cancel the codeshare it shoud be cost you money to do so, since your breaking a contract. Only the side breaking it should pay the fine, as the other partner will lose the +10% even if they wanted to still have it.

My mind is sort of foggy right now, I can probably think better tommorow, and express myself with more poise and clarity,

Cheers,

[ricchio]

I am short on time, so I didn't get to read everything, but I am looking forward to the idea. Let's go let's go!

Ciao,
Aaron

[Ionathan]

Also, something that should not be forgotten is the multiple codesharing.
Consider airlines X, Y, Z

X has a codeshare with Y on flight FLT001
X has a codeshare with Z on flight FLT001

X should have 10%+10% addiitonal passengers everytime they fly FLT001.
Y, Z should have only 10% more passengers each.

[cmdrnmartin]

Also, something that should not be forgotten is the multiple codesharing.
Consider airlines X, Y, Z

X has a codeshare with Y on flight FLT001
X has a codeshare with Z on flight FLT001

X should have 10%+10% addiitonal passengers everytime they fly FLT001.
Y, Z should have only 10% more passengers each.

Well, I now have diagrams spread out on the floor, what once was a simple idea is now, well quite convoluted and crazy, so I'm trying to break it back down to simple.

What we really want is Bridge routes, routes between two hubs, that sllow your passengers to move onto another networks flights.

You sould partner with an airline, and then declare a flight to be a bridge route. This locks the price of the route so that its equal for both airlines. Ie if one changes it, than it is automatically changed on the other side.

Second, the bridge route would probably be above the usual 70% load, I was thinking 90%.

Thirdly, at the airports on each end of a bridge route, all flights gain a 5% increase in traffic, both ariiving and departing, but only for the airlines that own the codeshare. The bridge route is not affected by this increase as it has that special status and is locked in at about 87-94 % full all the time.

Fourthly, the maximum nymber of bridge routes for an airline to on eof their airports should be three, they can have more, but the bonus stops at 12.5% increase (5, 5, 2.5)

Fifthly, it costs money to remove bridge route status, Perhaps MaxNumberPassgr x .9 x Price of Ticket

Sixtly, Airlines must declare a partnership with the other airline that they intend to codeshare with, and a single airline may have a maximum of four partners. Breaking these Partnerships should cost TotalAirlineValue x .15 for the side breaking and Total Airline Value x .05 for the other party.

I think this system is simpler than my first idea, it gets the passenger values a bit better, hopefully simulating the movement of people to and from Hubs a bit better.

Comments, additions, Suggestions?

[Lenair CEO]

Hi

The codeshare feature implemented is for Me pesonaly not 100% correct. Because if airline X flyies form A to B, codeshared with airline Y, airline Y can fly from A to B too. That means that the pilot for airline Y can fly the airline's X route. That is in My opinion and understanding of codesharing not correct. As I know and read on wikipedia both airlines still have the own routes but they sell an amout of seats to each other, to increase the route connections. That means on FlyNET that the pilot of the airline should not be able to fly the codeshared flight of the partner airline, only the own company route. but, the flight should be in the flightplan as an partner connected, codeshared and operated flight. It would be nice if the partner airline can offer a codeshare route to the other airline and fix the amout of their availiable seats for the partner 10,20,30... or so.

[CAPFlyer]

Please read the other thread I linked you to for how it is implimented and why. If you read it you will understand that codesharing in it's real-world form has no real use on the network at this time, so it was "modified" to fit FlyNET's purpose and still have utility.