United MileagePlus (Consolidated) - March 3, 2012 - integration day for SHARES res. system.

Was chatting with a CSR today about .bomb, and was told that March 3,2012, is the date when UA migrates to the unified SHARES system to be operated by PMCO and PMUA.

His/her advice was, and I quote, "you might think twice about flying us for a few weeks starting March 3rd."

A CO phone agent told me the same thing today as well.

Was chatting with a CSR today about .bomb, and was told that March 3,2012, is the date when UA migrates to the unified SHARES system to be operated by PMCO and PMUA.

His/her advice was, and I quote, "you might think twice about flying us for a few weeks starting March 3rd."

What a professional response from the CSR. :rolleyes::rolleyes:

What a professional response from the CSR. :rolleyes::rolleyes:

Perhaps it wasn't a "professional response", but from everything that has been discussed, I might agree with her recommendation.

That's my birthday...

and I have a trip planned 9 days later... Happy birthday to me...

I hope (in vain?) that UACO do thorough testing... surely you can do lots of dummy tests...

Was chatting with a CSR today about .bomb, and was told that March 3,2012, is the date when UA migrates to the unified SHARES system to be operated by PMCO and PMUA.

His/her advice was, and I quote, "you might think twice about flying us for a few weeks starting March 3rd."

I love how you think outting the CSR's gender will lead the draconian UA mgt to trying to track "him/her" down. This isn't going to effect 90+% of us. I'm sure there is going to be a lot of training and testing between now and then, let's try to be optimistic that most of the hiccups will be worked out. As long as the NE winter doesn't stretch into March (massive disruptions/IRROPS) we should be ok.

I love how you think outting the CSR's gender will lead the draconian UA mgt to trying to track "him/her" down. This isn't going to effect 90+% of us. I'm sure there is going to be a lot of training and testing between now and then, let's try to be optimistic that most of the hiccups will be worked out. As long as the NE winter doesn't stretch into March (massive disruptions/IRROPS) we should be ok.

In exchange for a few UA vouchers, i'd like to think UA would hire Flyertalkers to do at least some of the testing. We know the website in and out from basic to advanced and while not UA employees, probably care just as much about making sure it goes live with as few snags as possible.

In exchange for a few UA vouchers, i'd like to think UA would hire Flyertalkers to do at least some of the testing. We know the website in and out from basic to advanced and while not UA employees, probably care just as much about making sure it goes live with as few snags as possible.

^^^

In exchange for a few UA vouchers, i'd like to think UA would hire Flyertalkers to do at least some of the testing. We know the website in and out from basic to advanced and while not UA employees, probably care just as much about making sure it goes live with as few snags as possible.

^
Excellent!

Perhaps it wasn't a "professional response", but from everything that has been discussed, I might agree with her recommendation.

That doesn't matter. The CSR is some random joe on FT, he or she is a company employee and needs to be professional. Not to mention its one of the all time classic UA customer service issues is that UA has way too many lone wolf customer facing employees.

Not to mention, what does this CSR actually know about the transition? No doubt it will be challenging, but I doubt this person is the expert. The CSRs should keep it to themselves and save the griping for the break room.

Not to mention, what does this CSR actually know about the transition? No doubt it will be challenging, but I doubt this person is the expert.

Perhaps this agent has begun "SHARES training" and has seen how well or poorly they and their colleagues are equipped to handle a non-Fastair system?

Honestly I don't see why this is such a big deal. UA should just hire a bunch of travel agents with 20+ years experience as temporary workers and let them handle booking and reservations for a few months -- surely if you can handle SABRE, it's no big deal to learn another res system.

What a professional response from the CSR.
Its highly professional, a good rep will advise customers of possible issues arising from their itinerary (such as a tight connection).

Awesome I have 2 UA flights on March 9, 2 more on March 10, 1 on March 11, and 2 on March 12.

4 more on March 17 - UA flights booked as CO flight numbers :D

This is gonna be fun :D

Does the current CO.com take e-certs? Or will they need to figure out a way to accommodate those?

Its highly professional, a good rep will advise customers of possible issues arising from their itinerary (such as a tight connection).

We're also not all informed of the entire context of the conversation.

If a CSR that I knew or had held a lengthy discussion with said that to me, I would not a problem. We all know that there will be plenty of complaints from folks once the new system is in place, why would not want honesty? I think customer service has to be based in some sort of honesty....

I think weather it was professional or not is much more gray than folks are making it out to be. It would be much different if said CSR was in a terminal sharing the comment will all pax.

I'll be an early tester of the merged system - must fly CLE to BWI on March 3rd and return March 4th. I'm booking as UAL to use a Type B voucher from UAL, but the flights are operated by ExpressJet (dba CO Express) and Colgan Air (dba CO Connection.)

Oh Joy...flying UA March 4th :D

What's the SHARES system? Does it relate to reservations or operations?

Does the date indicate anything about the merger of OnePass and MileagePlus? I will likely not make 2P this year but will make MM when lifetime miles are merged so I'm trying to figure out whether I'm going to have to fly as zero at some point in the first quarter.

Aargh...I already have a trip planned with a return on 3/3. I might look into rescheduling if this date holds. I flew US LGA-BUF on its first day using SHARES a few years ago and it was a mess. Do not want a repeat.

What's the SHARES system? Does it relate to reservations or operations? ....SHARES is the internal system CO uses to manage reservations. It is used by reservation agents, gate agents, ....


The issue is UA has middleware that provides an improved UI over the command line approach in the CO implementation.

SHARES is the internal system CO uses to manage reservations. It is used by reservation agents, gate agents, ....


The issue is UA has middleware that provides an improved UI over the command line approach in the CO implementation.

There are other differences as well, some of them reasonably significant from a user (res/cs agent) perspective. Apollo (with or without the fastair shell on top of it) was (is) a more robust system that seems to me, at least to provide better real time responces when booking non UA/CO flights, some etkt functions when not flying on original ticketed flight, and gate management systems.

Something that doesn't apply to most of you, but when NRSA traveling, Apollo uses date of hire, while shares uses completed years of service....while it may seem like not a biggie to a customer, to an employee who is senior by under a year to another employee, getting on a flight (which is curruntly on UA dones by senority, down to the day) sorted by year instead of year/month/date, it is a biggie 15.99 years is different than 15.00 years. Lots of little things where the power and completeness of apollo are being replaced (IMHO again, others may differ) by a less powerful, slower, less robust tool.

It is, what it is though...will there be bugs? Most likely. Have they (and do they continue to) beta tested it? Of course. Will they be fully staffed on and around the cutover date, I have heard they will be staffed like an apple store on the date of a new iphone release.

Google says that airline GDS fees are over $7 billlion worldwide/yr, and looking at UA's 10k, they break "distribution costs" (GDS fees, credit card fees and commissions) at $912 million for 2010, of which, I think GDS fees account for the majority of that, if a significant portion of that can be reduced by using CO's system, there can be some big savings. I mean other airlines have "gone to war" over GDS fees (AA and Sabre) with the courts having to step in. ANy real savings without reducing distribution channels has got some positive impact to the bottom line.

Perhaps this agent has begun "SHARES training" and has seen how well or poorly they and their colleagues are equipped to handle a non-Fastair system?

The CSR had indeed started SHARES training, and isn't hopeful about the transition being all that smooth. Given how poorly COdbaUA rolled out the "new and improved" boarding process, I don't see how people can honestly expect this change to go any better.

As far as the "unprofessional" comments go, to each their own. I appreciated the heads up, and will not book any flights in early March. I realize a certain percentage of CO defenders will regard this agent's advice as treasonous, but I regard it as just the opposite. I appreciate the heads up, and this makes it just a bit more likely that I'll stay with UA, as I appreciate honesty more than I do "rah, rah, we're the best" cheerleading. ^^

Awesome I have 2 UA flights on March 9, 2 more on March 10, 1 on March 11, and 2 on March 12.

4 more on March 17 - UA flights booked as CO flight numbers :D

This is gonna be fun :D

Its all good :)

It's November 6, 2011 right now, so my guess is any current "target" date for the transition to SHARES for March 2012 (almost 4 months from now) changes at least once by then, and maybe twice or more before the switch actually takes place.

In exchange for a few UA vouchers, i'd like to think UA would hire Flyertalkers to do at least some of the testing. We know the website in and out from basic to advanced and while not UA employees, probably care just as much about making sure it goes live with as few snags as possible.

It's not the website. Too many FTers seem to think Airline IT=Airline Website, when in reality any airline's website is just a very limited-functionality view into a very limited subset of all the things that have to go on behind the scenes.

Just like Charles Schwab's online brokerage website is NOT Charles Schwab's brokerage system.

It's November 6, 2011 right now, so my guess is any current "target" date for the transition to SHARES for March 2012 (almost 4 months from now) changes at least once by then, and maybe twice or more before the switch actually takes place.

Let's start a game...

My guess: July 23, 2012

In exchange for a few UA vouchers, i'd like to think UA would hire Flyertalkers to do at least some of the testing. We know the website in and out from basic to advanced and while not UA employees, probably care just as much about making sure it goes live with as few snags as possible.

=================
You would have to be standing on our side of the counter to "test" it. Your knowing and using the UA or CO website is entirely different than the computer system we will be using (SHARES). Training has started - two weeks for agents that work lobby and gates and one week for agents who do not work the gates.
Keep in mind we are learning a new "language". CO formats in SHARES has some similarities to Apollo but there are also many differences.
I have not yet gone to training. Feedback from coworkers who have gone through training is mixed. They all seem to agree that we will learn it (especially anyone who was originally trained on United's Apollo); obviously we have to; we have no choice. Let me just say that what we can currently do in 2-3 keystrokes in Fastair will now be, literally, much longer formats and entries in "sentence" form. This will be everything from booking and ticketing reservations, exchanging tickets, pricing, seat changes,... everything. Like anything else, there will be those who adapt quickly and efficiently and those that will be "stumbling around" for awhile. We will, however, not be left without help. Our helpers will be current CO employees who will be working with us and assisting us as one team at our counters and gates. I wish all of my UA coworkers well with their training. I don't think we can really guess how the transition will actually go until it happens in early March 2012.

Flyingnone - has the rationale for adopting a system that is not as efficient than the one it is replacing been explained to the PMUA employees?

SHARES is cheaper.

I don't know the specifics about the differences and don't really care, unless it helps me clear the WL quicker.Tthey won't change it based on anyone's post on FT. Let the training begin and we shall see what happens come spring.

I really enjoy talking to CSR agents, but I hope this system doesn't cause us more phone calls.

Its highly professional, a good rep will advise customers of possible issues arising from their itinerary (such as a tight connection).

No, it really is not professional. UACO is not advising them to be saying these things so they should keep it to themselves. You all complain about consistency of service on UA...this is part of the equation...rogue employees who are out and about doing things their own way.

As much as Halls120 and Friendlyskies want to deny everything, shares has a higher level of functionality and is cheaper than APOLLO. While it may take some time to learn the system, it is a change that people will like.

You all complain about consistency of service on UA...this is part of the equation...rogue employees who are out and about doing things their own way.
I don't complain about any UA inconsistency... UA is able to do things at the airport in seconds that CO could only dream of. I appreciate the heads up .

Let me just say that what we can currently do in 2-3 keystrokes in Fastair will now be, literally, much longer formats and entries in "sentence" form. This will be everything from booking and ticketing reservations, exchanging tickets, pricing, seat changes,... everything.

And honestly, this is my biggest fear.

Not that it won't be learned (it will), but using this commandline approach is prone to errors (make a typo or get the syntax wrong, and it won't work, and you have to look up the correct command).

Again, not insurmountable, but IME, what this translates to on the CO side, is a downgrade in customer service. An agent who is looking at a huge line of customers is more likely to say no to a reasonable request because of the time it will take them to handle it. Why bother trying to rebook the customer on AA in an hour when the customer is already reprotected on CO/UA in 8 hours? Especially if it will take 15 minutes of clumsily clunking around with SHARES commands to get it to take?

Does the current CO.com take e-certs? Or will they need to figure out a way to accommodate those?

Not only does Co.com take e-certs, but it also allows the use of canceled reservation credits when booking new ones. I couldn't believe the lack of functionality on .bomb regarding the latter.

Not only does Co.com take e-certs, but it also allows the use of canceled reservation credits when booking new ones. I couldn't believe the lack of functionality on .bomb regarding the latter.

I suspect that "deathly silence" will be the response to this from the usual suspects. There is an agenda to be furthered after all - balance doesn't come into the equation.

I suspect that "deathly silence" will be the response to this from the usual suspects. There is an agenda to be furthered after all - balance doesn't come into the equation.

Sometimes I think that I'm in the "P/R" version of the United forum, what with the illogical, agenda-driven fervor that permeates many of these discussions.

I just posted in another thread that after a year of flying UA almost exclusively I have come to the conclusion that UA FAs are not as customer-oriented as CO ones*. This is not agenda-driven; it is an observation that has become especially apparent with the PDB-refusal fiasco. I would be more than happy to report otherwise, but sadly, I cannot. I wonder how many others posting on this forum have as much experience on the two airlines as I do in the last several years? Some no doubt do, but I'll bet that I'm a fairly rare bird.

*I have met some excellent UA FAs, and some indifferent CO ones, of course.

previous debates on SHARES vs APOLLO/FASTAIR

http://www.flyertalk.com/forum/continental-onepass-pre-merger/1162922-rumor-co-computer-system-survive-post-merger.html
http://www.flyertalk.com/forum/united-mileage-plus-consolidated/1252964-fastshares-delayed-but-shares-isnt.html
http://www.flyertalk.com/forum/united-mileage-plus-consolidated/1216238-so-who-cio-now.html
and others (http://www.flyertalk.com/forum/search.php?searchid=11668816)

I was passing through BWI a few weeks ago and needed to do some ticketing on the UA side, I was talking with the Ticketing Agent and she said that SHARES is going to take some getting used to it, could she handle it, most likely, it is just going to be difficult at first without a question.

She explained that the ticketing issues that I had to have corrected is a fairly easy process in the legacy UA system, but much more labor intensive in CO's SHARES system.

Dan

I have a sick feeling that I'm going to get a lot more "I can't fix this in 5 minutes" like I did from a CO CSR at the LAX elite line. Only this time, he can't send me back to United to fix it in 30 seconds.

What a professional response from the CSR. :rolleyes::rolleyes:

Actually, part of professionalism is honesty, and that is what Halls got.

SHARES is cheaper.

Yes.

As much as Halls120 and Friendlyskies want to deny everything, shares has a higher level of functionality and is cheaper than APOLLO. While it may take some time to learn the system, it is a change that people will like.

You are kidding, right? Higher level of functionality? Not when it comes to doing what CSRs really have to do, like reissuing and rebooking. FastSHARES would have made this much better, and Fastair/APOLLO is better still.

Not only does Co.com take e-certs, but it also allows the use of canceled reservation credits when booking new ones. I couldn't believe the lack of functionality on .bomb regarding the latter.

UA.bomb has its definite foibles, but its better than CO.bomb in other ways. For example, finding confirmable upgrade inventory and using upgrades. It also has a much better multicity search function. It is also much less cluttered. That said, I doubt you get many PMUA loyalists here who don't welcome some of the features of CO.bomb.

Anyway, the website has little, if anything, to do with the GDS.

As much as Halls120 and Friendlyskies want to deny everything, shares has a higher level of functionality and is cheaper than APOLLO. While it may take some time to learn the system, it is a change that people will like.

Well, with all of the evidence here, why do you continue to defend SHARES? It's an older program that requires much more work for simple issues.

Well, with all of the evidence here, why do you continue to defend SHARES? It's an older program that requires much more work for simple issues.

+1. If after all their years with the wonderful SHARES program, CO agents still take fare longer than UA agents doing similar tasks - isn't that proof enough?

UA.bomb has its definite foibles, but its better than CO.bomb in other ways.

Such as?? There's a reason they call UA's website .bomb . You'll never see references to that in the PMCO side.

Well, with all of the evidence here, why do you continue to defend SHARES? It's an older program that requires much more work for simple issues.

Not really. The difference is that it doesn't have the FastSHARES skin on it, not that it is worse than Apollo. That's coming soon, though a bit later than desired, and it will certainly help things. But knowing that the UI skin is coming it is foolish to bemoan the underlying system as so bad. Because it isn't. There will be some training/growing pains, just like it will take some time to get wifi deployed or the CO planes reconfigured for e+. Nothing in a merger like this happens instantaneously. And once all is said and done there is no reason to believe that the long-term functionality of the system is going to be significantly limited based on one underlying technology versus the other. Certainly not to the extent being bandied about here.

I'm not saying that SHARES without the UI is going to be faster or better than FastAir. But I am saying folks are comparing different things and not looking at the bigger, long term picture with most of these comments.

As much as Halls120 and Friendlyskies want to deny everything, shares has a higher level of functionality and is cheaper than APOLLO. While it may take some time to learn the system, it is a change that people will like.

Where did I ever claim SHARES wasn't cheaper than Apollo or had less functionality?

The sole question I've raised in this thread is why COdbaUA is adopting a system that is less efficient. You know, more keystrokes per transaction equals longer transaction time.

If you are going to criticize my posts, please have the common decency to state my position correctly.

Thanks! :D

Not really. The difference is that it doesn't have the FastSHARES skin on it, not that it is worse than Apollo. That's coming soon, though a bit later than desired, and it will certainly help things. But knowing that the UI skin is coming it is foolish to bemoan the underlying system as so bad. Because it isn't. There will be some training/growing pains, just like it will take some time to get wifi deployed or the CO planes reconfigured for e+. Nothing in a merger like this happens instantaneously. And once all is said and done there is no reason to believe that the long-term functionality of the system is going to be significantly limited based on one underlying technology versus the other. Certainly not to the extent being bandied about here.

I'm not saying that SHARES without the UI is going to be faster or better than FastAir. But I am saying folks are comparing different things and not looking at the bigger, long term picture with most of these comments.


While I see your point, I think the big concern is the pain in the near term, and then how long that near term may be, combined with the architecture choice and what it means on a day-to-day basis in the long term.

Keep in mind that they've already scrapped FastSHARES and are doing something different. This delay and sometimes get scrapped. But I agree with you, it will probably be a good thing to give the CO staff the tools they need, and to restore for the UA staff the tools they had taken away.

The next is the architecture choice. CO tends to think the back-end system is secondary and likes programming everything in ancillary systems. That's fine on paper, but in reality, what we've seen is that you lose the robustness and related functionality with some ancillary apps since they're not as tightly integrated (e.g., the inability to waitlist with EUA, or the inability to pull miles at the gate). There are also some reliability concerns (e.g., the dropped partner space issue), but I'm not sure why that happens to CO records as often as it does.

Native SHARES is an old, outdated system just like Apollo (Apollo is actually older if you want to get technical).

It's not a horrible program to learn, however, but I will concede that the company should have kept Apollo (with FastAir only as Native Apollo is just as labor intensive as SHARES) OR waited to roll out a new integrated SHARES system with a GUI overlay.

But that's just one little cog's opinion.

Not really. The difference is that it doesn't have the FastSHARES skin on it, not that it is worse than Apollo. That's coming soon, though a bit later than desired, and it will certainly help things. But knowing that the UI skin is coming it is foolish to bemoan the underlying system as so bad. Because it isn't. There will be some training/growing pains, just like it will take some time to get wifi deployed or the CO planes reconfigured for e+. Nothing in a merger like this happens instantaneously. And once all is said and done there is no reason to believe that the long-term functionality of the system is going to be significantly limited based on one underlying technology versus the other. Certainly not to the extent being bandied about here.

I'm not saying that SHARES without the UI is going to be faster or better than FastAir. But I am saying folks are comparing different things and not looking at the bigger, long term picture with most of these comments.

I agree with all you have said...and when FastSHARES is in place, it will probably be as rapid for CS as FastAir. The problem is that instead of waiting for the FastSHARES to be implemented, UA/CO management decided to introduce a less CS friendly process for over half of their flyers (PMUA)

Unfortunately, I...and many of my employees have to travel in "weather" more often than we would like, and need to alter flights on a regular basis...UA (AA and DL as well) has always been able to do this rapidly and without much stress...our experiences with CO have not been as positive. UA/CO "suits" have indicated to me that this is primarily a result of the different booking systems and that they hope to have a unified FASTShares in place by the end of 2012...which means we (PMUA fliers) have nearly a year with the "old" SHARES. For an airline to make it more difficult on their best travellers just does not make sense...but common sense is a casualty of the new corporate style:rolleyes:

On another, but related, subject, my nephew who is completing his Ph.D. in Management at Warton told me that the UA/CO merger is all the rage in classrooms there...and that there is one professor that is using the post merger IT shakeup at UA as an example of the pathology of dissimilar cultures in mergers!...No kidding!!

I was passing through BWI a few weeks ago and needed to do some ticketing on the UA side, I was talking with the Ticketing Agent and she said that SHARES is going to take some getting used to it, could she handle it, most likely, it is just going to be difficult at first without a question.

She explained that the ticketing issues that I had to have corrected is a fairly easy process in the legacy UA system, but much more labor intensive in CO's SHARES system.

Dan

When I was in LHR a couple of week's ago the UA transfer desk in Term 1 agents comments was "it's like going back to the stone age".

- HF

When I was in LHR a couple of week's ago the UA transfer desk in Term 1 agents comments was "it's like going back to the stone age".

- HF

Yes, but it's cheaper. That appears to be all that matters to the new COdbaUA.

Well, with all of the evidence here, why do you continue to defend SHARES? It's an older program that requires much more work for simple issues.

Maybe, but the program has a higher level of functionality than APOLLO, which allows CO to do more things with it. As of right now CO used they system as the backbone for what is the industry standard website.

Yes, CO.com is the industry standard, and you don't have to take my word for it ask ANY airline IT guy.

+1. If after all their years with the wonderful SHARES program, CO agents still take fare longer than UA agents doing similar tasks - isn't that proof enough?

Define far longer, and are you sure this has to do with the system as opposed to learning they syetem.

Show me numbers.

Where did I ever claim SHARES wasn't cheaper than Apollo or had less functionality?

The sole question I've raised in this thread is why COdbaUA is adopting a system that is less efficient. You know, more keystrokes per transaction equals longer transaction time.

If you are going to criticize my posts, please have the common decency to state my position correctly.

Thanks! :D

I am not criticizing your posts.

Your positions is a based on a false premise, you assume as people have expressed that they do not like change, that all change is inherently bad. I harken back to previous discussion where two independent studies posited the idea that the then United Airlines was the worst major airline in the US next to DL or US depending on the study.

Also, assuming you are correct that it does take some time longer to complete a task in Shares as opposed APOLLO, speed is not the only thing. If the extra time allows the CSA to better address the customers issue, as opposed to sending them somewhere else then the extra time is a good thing. I do not know this to be true, but it is an assumption on the same level as yours.

What is not in dispute is the follow SHARES has a higher level of functionality and is less expensive than APOLLO. Taking those into consideration and evaluating the effect on the bottom line and the consumer SHARES was selected even though it is slower in some respects than APOLLO.

Yes, but it's cheaper. That appears to be all that matters to the new COdbaUA.

In your previous post you conceded that Shares has more functionality than APOLLO. That must have factored into the discussion.

Define far longer, and are you sure this has to do with the system as opposed to learning they syetem.

Show me numbers.

No, it's the system. Have talked to agents doing the training, and have heard from plenty of flyers w/extensive experience on both airlines - SHARES is antiquated. I wonder how well businesses would work if they went from Windows/Linux-based systems to DOS...

Feel free to give a shred of evidence yourself that SHARES in its current form is anywhere near as quick and intuitive as FASTair is, or even any FT post referencing SHARES being "fast", "user-friendly", etc.

I have heard they will be staffed like an apple store on the date of a new iphone release.

I'm sure we'll be camping out to get rebooked. ;)

It is my understanding from talking with CO agents that SHARES works, not well by any means but it does function.

Do I feel that problems could arise from SHARES being adopted by the Legacy UA side, possibly, maybe even probably.

From my understanding SHARES can and in some cases is really less than ideal, one case is apparently re-bookings on other airlines, SHARES is clunky and requires tons of "typing" to correctly re-book somebody on another airline.

Does that mean SHARES is horrible, I have no idea, but it at least seems to function enough for CO to operate on a daily basis. Function to a level of "great" CS, like many of my UA FT brethren are accustomed to on the legacy UA? That is probably open to debate. My guess is probably not, but only time will tell.

Dan

Feel free to give a shred of evidence yourself that SHARES in its current form is anywhere near as quick and intuitive as FASTair is,
No one is suggesting that in this thread that I've seen. Compare SHARES to Apollo for a proper comparison.

One of the major advantages SHARES offers is that it is readily extensible and freely so. As such, when the company wants to change how things work or integrate additional systems into the environment they can do so with relative ease. Apollo required contract work and much more time in general.

The main reason this is going to be such a headache is because under normal circumstances an airline technology migration takes YEARS (absolute minimum of 1 year when no webservices or external systems are involved, but usually 2) to plan and execute. UACO are doing this in roughly 9-12 months, and with UA's size and number of external systems it is guaranteed to be a disaster.

Not all this is completely UA's fault. Travelport had UA by the [you know what] with the Apollo contract and UA's decision to shelve the Star Alliance common platform migration left them with few options.

No one is suggesting that in this thread that I've seen. Compare SHARES to Apollo for a proper comparison.

How is that a proper comparison? UA airport staff seldom touch native Apollo. They use FastAir. CO airport staff always are in SHARES.

From a customer experience standpoint, the functionality and usability of FastAir to SHARES is going to be the proper comparison.

I am not criticizing your posts.

Your positions is a based on a false premise, you assume as people have expressed that they do not like change, that all change is inherently bad.

No, that, wasn't my premise. My premise was why was COdbaUA adopting a system that was less efficient than the one currently used.

Also, assuming you are correct that it does take some time longer to complete a task in Shares as opposed APOLLO, speed is not the only thing.

every report I've read says it takes longer to accomplish a given task under SHARES than under APOLLO.

If the extra time allows the CSA to better address the customers issue, as opposed to sending them somewhere else then the extra time is a good thing.

So, spending more time with customer A because it takes longer to manipulate the system is a good thing? What about customers B-Z who are waiting in line behind customer A?


What is not in dispute is the follow SHARES has a higher level of functionality and is less expensive than APOLLO.

Good for you in asserting an issue I wasn't addressing or contesting.


One of the major advantages SHARES offers is that it is readily extensible and freely so. As such, when the company wants to change how things work or integrate additional systems into the environment they can do so with relative ease. Apollo required contract work and much more time in general.

In other words, COdbaUA is taking the cheaper alternative. ;)

I have no idea about the IT difference between SHARES and APOLLO. All I can comment on is from a pure customer perception... and it takes (what seems like) forever for a CO agent to do a simply re-book. A massive amount of typing and struggle... regardless of the reason.

If that is SHARES, then it is not customer focused.

I have no idea about the IT difference between SHARES and APOLLO. All I can comment on is from a pure customer perception... and it takes (what seems like) forever for a CO agent to do a simply re-book. A massive amount of typing and struggle... regardless of the reason.

If that is SHARES, then it is not customer focused.

That doesn't mean that a new UI won't fix it in the future. As for them scrapping FastSHARES, that may be just fine. Laying a UI built for one back-end onto a new back-end may not have worked well and starting from scratch could just be the better option.

Let us be totally clear the ONLY reason we are getting SHARES is because that is what CO uses and as we seen so many times in this merger of equals - almost all of the systems that survive are the CO ones. Now - I've become increasingly concerned about this migration as I've seen and experienced how bad shares is because of its complexity. Iprops or upgrades appear to fool the system and can lead to legs being left on that are then unflown - leading to the remainder of the itinerary being cancelled - UA would be better off stayingmwithnfast air till fast shares is ready

Let us be totally clear the ONLY reason we are getting SHARES is because that is what CO uses and as we seen so many times in this merger of equals - almost all of the systems that survive are the CO ones.

Not completely true. The two most visible systems (SHARES and co.com) are, but many of the other operational systems are using UA systems. I also think the .com enhancements look good as does the new mobile site.

Flyingnone - has the rationale for adopting a system that is not as efficient than the one it is replacing been explained to the PMUA employees?
===========
Yes.....I don't know if I'm at liberty to explain.

Such as?? There's a reason they call UA's website .bomb . You'll never see references to that in the PMCO side.
-------------------
But we're not talking about the UA website .... www.ual.com .... !! ---
We are talking about the Continental SHARES computer system that CSRs will be using - it's a whole different animal than the website or even the kiosks you use at the airport.
Let the chips fall where they may, I am reluctant to to give my true opinion, however, I have heard that SHARES originated with Eastern Airlines -- remember Eastern Airlines ?

I flew out of HKG in February, right after United agents took over the CO flights... It took three of them to figure out how to put a gentleman into the extra leg room seat, haha! Not sure if they even figured it out. I'm assuming they are now fine, but CO better be placing people all over the system in March!

. You know, more keystrokes per transaction equals longer transaction time.



And a longer transaction time means more labor costs, which is why I don't get how SHARES could possibly be cheaper.

If this is anything like the US Airways cutover to SHARES, expect long, long, lines at the airport on integration day.

And a longer transaction time means more labor costs, which is why I don't get how SHARES could possibly be cheaper.

It's only more labor costs if the same amount of output is expected from the worker pool.

If you eliminate some of the work through inferior customer service (i.e., the CO "No" culture), then some of the work goes away.

The question is whether that will work with the UA customer base who is used to being accommodated in accordance with Star Alliance rules.

I flew out of HKG in February, right after United agents took over the CO flights... It took three of them to figure out how to put a gentleman into the extra leg room seat, haha! Not sure if they even figured it out. I'm assuming they are now fine, but CO better be placing people all over the system in March!

About March of last year I was passing through HKG with a fellow FTer and had an issue with my reward ticket that required agent assistance and CO RES told me to see the UA agent in HKG.

At the time a very nice UA agent did her best to fix our reservation in CO's computer and it was not easy. She was on the phone with a help desk who did their best to talk her through SHARES but it was a fairly herculean challenge.

Both the fellow FTer and myself were very appreciative for the agents hard work and were impressed with her diligence.

I have zero way of knowing if Apollo/FastAir would have made the transaction any easier, but I can say that SHARES did seem to require a ton of work to fix the situation.

Dan

How is that a proper comparison? If someone is going to say that Apollo is better than SHARES then they should be talking about Apollo, not FastAir. That's how.

From a customer experience standpoint, the functionality and usability of FastAir to SHARES is going to be the proper comparison.
For the few months before FastSHARES (or whatever they decide to call it) is deployed, yes. But that's not what was being suggested in the post I was replying to.

While waiting the 30 minutes at the ticket counter last week for the GS rep (arguably some of the best trained/most competent) to fix my revenue ticket due to a likely misconnect in IAD she noted that she had just come back from training on SHARES and that she was having to "remember how to do it on this one" (meaning the UA system) as she worked to fix it. I asked about the training and just how awful SHARES was. She didn't seem too worried, other than that it is different.

For the few months before FastSHARES (or whatever they decide to call it) is deployed, yes. But that's not what was being suggested in the post I was replying to.

If it's just a few months, then why not wait it out and keep Apollo/FastAir for a few months longer.

I have a feeling this will take longer than just a few months...


she noted that she had just come back from training on SHARES and that she was having to "remember how to do it on this one" (meaning the UA system) as she worked to fix it. I asked about the training and just how awful SHARES was. She didn't seem too worried, other than that it is different.

Different is not the issue. It's the nature of the difference.

I can use DOS WordPerfect and get many of the same results as in Word. It'd just take me longer to do it due to the radically different nature of the interface.

===========
Yes.....I don't know if I'm at liberty to explain.


Thanks - I understand why you probably can't share the rationale.

If it takes more keystrokes to accomplish similar tasks, is UACO going to provide more CSR's, or are we going to have to live with longer lines at the service counters?

If it's just a few months, then why not wait it out and keep Apollo/FastAir for a few months longer.Because the contract was up and they thought they'd be done with the other work earlier and the contract was not renewed.

I have a feeling this will take longer than just a few months...We'll find out soon enough.

Different is not the issue. It's the nature of the difference.And the agent said she didn't think it was going to be an issue. Maybe she's the only one, but that's the direct feedback I received.

Thanks - I understand why you probably can't share the rationale.

If it takes more keystrokes to accomplish similar tasks, is UACO going to provide more CSR's, or are we going to have to live with longer lines at the service counters?

Furloughed PMUA employees have been called back to work.

I'm leaving SIN on Mar 3, hopefully they'll be going by Hawaiian time before they implement it, lol, whatever I'm via Tokyo, so if I misconnect to IAD they can pay to put me up in a hotel for the night.

The CSR had indeed started SHARES training, and isn't hopeful about the transition being all that smooth. Given how poorly COdbaUA rolled out the "new and improved" boarding process, I don't see how people can honestly expect this change to go any better.

As far as the "unprofessional" comments go, to each their own. I appreciated the heads up, and will not book any flights in early March. I realize a certain percentage of CO defenders will regard this agent's advice as treasonous, but I regard it as just the opposite. I appreciate the heads up, and this makes it just a bit more likely that I'll stay with UA, as I appreciate honesty more than I do "rah, rah, we're the best" cheerleading. ^^

Likewise I've had conversations with several UA agents over the past few weeks and the message from each of them was clear: "avoid flying us the first few weeks of March if you can." These are all agents I've seen weekly for the past several years and I trust their opinions to be more than just complaining about yet another change. All of these agents have already gone through the classroom time for SHARES training and are now getting 2 or 4 hours each week at the gates to learn the system before March 2012 - they've all said it's not enough practical experience time.

After hearing several of the examples cited by them, I"ll be flying AA in March 2012. I've already gone through the conversion of CO employees trying to learn the UA system at a line station where CO has taken over the ground handling (it had been outsourced) -- after seeing the debacle that was for the first month whenever there were ANY issues with delays/cancellations/etc, I don't want to think about it on a systemwide basis with UA employees transitioning to SCARES.

As to OP CSR comment, I agree it might be good advice. Today I asked a CSR rep if anything was likely to impact customers this weekend with a Single Operating Certificate, i.e. should I reschedule, not check bags, etc. I was told not to expect anything different this weekend, that the big change would likely be early March when everything went onto SHARES.

As to the actual IT systems, it sounds like contract talks with the UA vendor forced UACO into changing over early. It is also my understanding that SHARES is "More robust but slower, and somewhat more complex" (Same can be said of most command line vs GUI systems). Hopefully they prep as much as possible to mitigate in the short term. In the long term UACO may end up with a system that is both better architecturally, the same useability, and much cheaper.

If they have fully merged CSR operations by then it might make things smoother as well.

As to OP CSR comment, I agree it might be good advice. Today I asked a CSR rep if anything was likely to impact customers this weekend with a Single Operating Certificate, i.e. should I reschedule, not check bags, etc. I was told not to expect anything different this weekend, that the big change would likely be early March when everything went onto SHARES.

As to the actual IT systems, it sounds like contract talks with the UA vendor forced UACO into changing over early. It is also my understanding that SHARES is "More robust but slower, and somewhat more complex" (Same can be said of most command line vs GUI systems). Hopefully they prep as much as possible to mitigate in the short term. In the long term UACO may end up with a system that is both better architecturally, the same useability, and much cheaper.

If they have fully merged CSR operations by then it might make things smoother as well.

My understanding is that CO is locked into a contract with HP/EDS that involves continuing to use SHARES.

I just got off the phone with HNL Reservations and was fortunate enough to speak with with an agent I knew very well...she had worked at a CTO I frequented for almost 20 years. After a friendly chat and remembrances of mutual friends, and fixing a reservation nightmare due to schedule changes and a mechanical (it was not a good day to fly:rolleyes:), I asked if she had trained on SHARES...she responded that she was actually a training supervisor on the transition. She indicated that SHARES without the FastSHARES or FastAir was quite burdensome...especially with complicated Asian itineraries and MALOPS (her words, not mine) In addition, half of the HNL RES center has been changed over to the new program, but not many of the staff have...so it will not be able to take as many calls as in the past...and she indicated that management was aware that this might be a serious problem...and that more calls to reservations might end up in MNL...GROAN!!

The most worry-some thing she told me was that many senior reservation agents in HNL and at other res centers are deciding to retire rather than go through the training and transition to SHARES...she also indicated that quite a few senior CS staff are also retiring because of this. These were the very best UA had and who remembered what customer service was all about...something frequently forgotten by airlines today!

This does not bode well for a seamless transition to the new system. When asked about travel in early March...she gave the PC answer that it would be OK...followed by "It might, though, be the perfect time to vacation at home":rolleyes:

It is just not as much fun as it used to be!

My understanding is that CO is locked into a contract with HP/EDS that involves continuing to use SHARES.

That is just part of the merger. Each entity comes with existing relationships and contracts that may or may not be able to be broken.

Thanks - I understand why you probably can't share the rationale.

If it takes more keystrokes to accomplish similar tasks, is UACO going to provide more CSR's, or are we going to have to live with longer lines at the service counters?

-----------------
If it's any consolation to you (and us!), CO is soliciting their agents in the field to apply/volunteer (interview) to work in other stations for a couple of months -to aid and assist in training - hands on - their "new" United coworkers. I believe many stations are hiring more new people as well and they will not have the conflict of knowing/using Fastair versus SHARES.
Keep in mind that there are many smaller stations including employees of UAX that have to be trained. What the details are I don't know - I would imagine they are sending these employees to other stations for training rather than bring trainers into every station (impossible when you think of the scope of United's route system). It has got to be a challenge.
I will be trained in the near future at my local station classroom. About half the agents have been through training here. The message is to learn it, like it and embrace it (sigh).
My goal is to learn more than I'm taught even if I have to be "self-taught" because I'm a person who can't live with just the basic entries and not know anything else; After 30+ years it goes against my grain to perform just the minimal, basic functions and call it a day. If I do that, I will be "handicapped" and of no use to anyone; might as well be a new-hire off the street.
Like Channa said, though, if it gets too "hairy" or there is very little time to fix a problem quickly (because of entries that take 20 minutes to type), the inclination with most people would be to fob off the hard stuff, the challenges to another area --- "You can do that at the gate"......"You would need to do that with Reservations"...etc.
I'll do the best I can -- OR MAYBE I'LL RETHINK R E T I R E M E N T.

Because the contract was up and they thought they'd be done with the other work earlier and the contract was not renewed.


This is ignoring some of the complexity, but just about every company will be happy to hear something like "we wanted to cancel in March, but would want another couple of months at our usual monthly rate". The push to SHARES is very much management considering the pro of a unified reservation to be greater than whatever (hopefully not that terrible) efficiency hassles we'll all face.

-----------------
If it's any consolation to you (and us!), CO is soliciting their agents in the field to apply/volunteer (interview) to work in other stations for a couple of months -to aid and assist in training - hands on - their "new" United coworkers. I believe many stations are hiring more new people as well and they will not have the conflict of knowing/using Fastair versus SHARES.
Keep in mind that there are many smaller stations including employees of UAX that have to be trained. What the details are I don't know - I would imagine they are sending these employees to other stations for training rather than bring trainers into every station (impossible when you think of the scope of United's route system). It has got to be a challenge.
I will be trained in the near future at my local station classroom. About half the agents have been through training here. The message is to learn it, like it and embrace it (sigh).
My goal is to learn more than I'm taught even if I have to be "self-taught" because I'm a person who can't live with just the basic entries and not know anything else; After 30+ years it goes against my grain to perform just the minimal, basic functions and call it a day. If I do that, I will be "handicapped" and of no use to anyone; might as well be a new-hire off the street.
Like Channa said, though, if it gets too "hairy" or there is very little time to fix a problem quickly (because of entries that take 20 minutes to type), the inclination with most people would be to fob off the hard stuff, the challenges to another area --- "You can do that at the gate"......"You would need to do that with Reservations"...etc.
I'll do the best I can -- OR MAYBE I'LL RETHINK R E T I R E M E N T.


That's interesting, because I had heard that they're simply adding agents on an ongoing basis when they move to SHARES, simply because it's less efficient and takes more agents to run it (e.g., look at CO's GA staffing level per gate vs. UA's).

The push to SHARES is very much management considering the pro of a unified reservation to be greater than whatever (hopefully not that terrible) efficiency hassles we'll all face.
Indeed, being on a single platform is better for customers than being on a split platform.

That's interesting, because I had heard that they're simply adding agents on an ongoing basis when they move to SHARES, simply because it's less efficient and takes more agents to run it (e.g., look at CO's GA staffing level per gate vs. UA's).

The gate staffing levels are not a result of the reservation system being used but of the different scope of duties performed by the GAs.

===========
Yes.....I don't know if I'm at liberty to explain.


-------------------
But we're not talking about the UA website .... www.ual.com .... !! ---
We are talking about the Continental SHARES computer system that CSRs will be using - it's a whole different animal than the website or even the kiosks you use at the airport.
Let the chips fall where they may, I am reluctant to to give my true opinion, however, I have heard that SHARES originated with Eastern Airlines -- remember Eastern Airlines ?

No so Kimosabe. I think that you are thinking of SystemOne/SODA (SystemOne Direct Access) SHARES came from CCS - Continental Computer Systems

That's interesting, because I had heard that they're simply adding agents on an ongoing basis when they move to SHARES, simply because it's less efficient and takes more agents to run it (e.g., look at CO's GA staffing level per gate vs. UA's).

Listening to those little voices inside you head again? :p

Is there a credible source, or just "you heard"?

Methinks sxf24 (post 83) is closer to the mark.

Indeed, being on a single platform is better for customers than being on a split platform.

Astute as usual. What is interesting, it that this seems to be discounted by so many....the same ones that want their mileage credits to post immediately between the 2 systems, upgrade instruments to be managed like they were a single system, FLIFO, seat maps, and upgrades for PMUA to be realtime on the PDA/.com Website. All that info is gleaned from the host. You have more than one host, and the info has to traverse systems. More chances to be lost/translated incorrectly.

Different is not the issue. It's the nature of the difference.

I can use DOS WordPerfect and get many of the same results as in Word. It'd just take me longer to do it due to the radically different nature of the interface.

This is the acurate analogy that PMCO folks are unwilling to acknowledge

Astute as usual. What is interesting, it that this seems to be discounted by so many....the same ones that want their mileage credits to post immediately between the 2 systems, upgrade instruments to be managed like they were a single system, FLIFO, seat maps, and upgrades for PMUA to be realtime on the PDA/.com Website. All that info is gleaned from the host. You have more than one host, and the info has to traverse systems. More chances to be lost/translated incorrectly.

No one is saying there should be more than one "host" - just that the wrong "host" was clearly chosen

No one is saying there should be more than one "host" - just that the wrong "host" was clearly chosen

Nevertheless, no one has been able to articulate why the wrong system was chosen.

No one is saying there should be more than one "host" - just that the wrong "host" was clearly chosen

Actually, you can tke that to any of the threads listed here.
http://www.flyertalk.com/forum/17406736-post38.html


I believe this thread is discussing the supposed date for the implementation of the single system (which has been made more than clear that you don't care for). Or you can beat the same dead horse here, sending yet another thread back six months.

The system is chosen. Perhaps we can get back to the perceived impact that it will have on the operation of the airline.

No one is saying there should be more than one "host" - just that the wrong "host" was clearly chosen

Why is it wrong? What if it was SHARES with the FastAir GUI?

Would you still be upset?

Nevertheless, no one has been able to articulate why the wrong system was chosen.

It's been articulated quite well and quite frequently, but we'll pretend that all those posts never existed

Why is it wrong? What if it was SHARES with the FastAir GUI?

Would you still be upset?

It's somewhat analogous to E+ on CO metal - at some point down the road, it will be nice. Until then, it's an archaic system that's a step back for the world's largest airline

It's been articulated quite well and quite frequently, but we'll pretend that all those posts never existed

No, it hasn't. There are some posters who are fixated on the GUI interface, but that's just window dressing and has absolutely nothing to do with system functionality or whether the system chosen was "right" or "wrong."

It's somewhat analogous to E+ on CO metal - at some point down the road, it will be nice. Until then, it's an archaic system that's a step back for the world's largest airline

Both systems are equally archaic.

No, it hasn't. There are some posters who are fixated on the GUI interface, but that's just window dressing and has absolutely nothing to do with system functionality or whether the system chosen was "right" or "wrong."



Both systems are equally archaic.

Apollo is actually older ;) But yes, both mainframes are ancient...

No, it hasn't. There are some posters who are fixated on the GUI interface, but that's just window dressing and has absolutely nothing to do with system functionality or whether the system chosen was "right" or "wrong."

That "window dressing" is what makes UA agents more empowered and faster as like tasks relative to their CO counterparts, not sure why you're so dismissive of that. I bet it will be a blast for them typing command lines in the coming year.

Maybe the new GUI will be a godsend - or maybe they'll just train everyone on SHARES and scrap any further development, as that's a new cost that could be easily cut.

That "window dressing" is what makes UA agents more empowered and faster as like tasks relative to their CO counterparts, not sure why you're so dismissive of that. I bet it will be a blast for them typing command lines in the coming year.


I'm still waiting for someone to explain just how - and why - it is better to have an IT system that requires more keystrokes than fewer. As someone else pointed out, it's like saying going back to DOS is an improvement over Windows or Mac OS. Silly me, I've been under the apparent delusion that using a mouse and a robust GUI is more efficient than typing in commands on a keyboard.

I'm still waiting for someone to explain just how - and why - it is better to have an IT system that requires more keystrokes than fewer. As someone else pointed out, it's like saying going back to DOS is an improvement over Windows or Mac OS. Silly me, I've been under the apparent delusion that using a mouse and a robust GUI is more efficient than typing in commands on a keyboard.

I know, you'd think it's stunningly rational...

Flip the script - if they were keeping Apollo/FASTair, would anyone be talking about this as a step backwards? Might it not be easier for PMCO employees to learn a GUI than PMUA employees to learn DOS-like commands? And wouldn't it result in fewer total employees needing to be trained?

Other than "it's cheaper", I'd love to hear the counter argument.

That "window dressing" is what makes UA agents more empowered and faster as like tasks relative to their CO counterparts, not sure why you're so dismissive of that. I bet it will be a blast for them typing command lines in the coming year.

Maybe the new GUI will be a godsend - or maybe they'll just train everyone on SHARES and scrap any further development, as that's a new cost that could be easily cut.

How does software make someone more empowered? :confused:

I'm still waiting for someone to explain just how - and why - it is better to have an IT system that requires more keystrokes than fewer. As someone else pointed out, it's like saying going back to DOS is an improvement over Windows or Mac OS. Silly me, I've been under the apparent delusion that using a mouse and a robust GUI is more efficient than typing in commands on a keyboard.

Have you ever performed transaction-based tasks using both a command-line and GUI interface? I have.

While command line has a much steeper learning curve, I found users who are proficient (including myself) will prefer it over a GUI since it provides you with greater flexibility and allows you to navigate many functions more quickly. In addition, a proficient user can make quite a few keystrokes in the time it takes the hand to leave the keyboard, grasp the mouse, navigate and click it.

When airlines have allowed front line staff to choose between the native environment or overlay, many experienced agents will choose to work with command line. Yes, I'm sure there are a few tasks that might be slower and it is tough to learn and will be a difficult transition for agents who are not as bright or dedicated.

I know, you'd think it's stunningly rational...

Flip the script - if they were keeping Apollo/FASTair, would anyone be talking about this as a step backwards? Might it not be easier for PMCO employees to learn a GUI than PMUA employees to learn DOS-like commands? And wouldn't it result in fewer total employees needing to be trained?

Other than "it's cheaper", I'd love to hear the counter argument.
There is a lot more to it than just what the reservations and gate agents deal with. The system is more or less critical to the entire operation, from dispatch to flight planning to the FF program and beyond.

If the two systems offered the same underlying functionality then you'd probably go with the one that offers up a lower TCO. And since the underlying Apollo and Shares systems are pretty comparable that's what the company is doing. That said, the extensibility of Shares is actually greater than that of Apollo so there is value there to the company.
I'm still waiting for someone to explain just how - and why - it is better to have an IT system that requires more keystrokes than fewer. As someone else pointed out, it's like saying going back to DOS is an improvement over Windows or Mac OS. Silly me, I've been under the apparent delusion that using a mouse and a robust GUI is more efficient than typing in commands on a keyboard.
No one is suggesting that we should want a "worse" system. But there does seem to be quite a bit of confusion in what to compare to determine if that's the case or not. Comparing the end-user interface of FastAir v. the command line interface of Shares is not a particularly useful comparison as FastAir is not Apollo. So everyone who keeps stating that Apollo is better than Shares because of the UI is actually talking about something completely different.

That hasn't stopped those posts, and repeatedly pointing out that fact doesn't seem to be helping.

Comparing the end-user interface of FastAir v. the command line interface of Shares is not a particularly useful comparison as FastAir is not Apollo. So everyone who keeps stating that Apollo is better than Shares because of the UI is actually talking about something completely different.

Not really. Both are systems the airport agents use. Those are the sets of tools provided to the agents. CO gives their agents SHARES; UA gives their agents Apollo + FastAir. From that perspective, that is absolutely the relevant comparison.

That said, the extensibility of Shares is actually greater than that of Apollo so there is value there to the company.

I've seen a lot of reference to this, just how "robust" SHARES is, and how far it can extend, yadda yadda. What has CO actually done with it? If they haven't created a GUI after all this time, why would they now?

Based on reported encounters with IRROPS issues and the like, doesn't seem like the company has given its agents much in the way of tools.

If they haven't created a GUI after all this time, why would they now?


Most airlines tend to have no clue about what the in-house technology of other airlines looks like. Seems like CO for whatever reason was content with their way of doing things; however, seeing what UA did was a compelling reason to change.

No, it hasn't. There are some posters who are fixated on the GUI interface, but that's just window dressing and has absolutely nothing to do with system functionality or whether the system chosen was "right" or "wrong."



Both systems are equally archaic.

This is like saying windows is just dressing over dos or apple is just dressing over unix. It is pointless to argue about the underlying system it is what is on top that makes it ua be by most - SHARES is a mistake because it has no dressing

This is like saying windows is just dressing over dos or apple is just dressing over unix. It is pointless to argue about the underlying system it is what is on top that makes it ua be by most - SHARES is a mistake because it has no dressing

No, its not like Windows : Dos or Apple : Unix since there's not additional functionality, just an easier user interface. It's nothing more than a skin over the core program.

Based on reported encounters with IRROPS issues and the like, doesn't seem like the company has given its agents much in the way of tools.

Well, unless you have first hand experience it doesn't seem to be appropriate to pass of others' second hand comment as reality.

How does software make someone more empowered? :confused:



Have you ever performed transaction-based tasks using both a command-line and GUI interface? I have.

While command line has a much steeper learning curve, I found users who are proficient (including myself) will prefer it over a GUI since it provides you with greater flexibility and allows you to navigate many functions more quickly. In addition, a proficient user can make quite a few keystrokes in the time it takes the hand to leave the keyboard, grasp the mouse, navigate and click it.

When airlines have allowed front line staff to choose between the native environment or overlay, many experienced agents will choose to work with command line. Yes, I'm sure there are a few tasks that might be slower and it is tough to learn and will be a difficult transition for agents who are not as bright or dedicated.

I wholeheartedly agree. And so would many, many IT companies and back-office employees that use these systems. In the late 90s and early 00s every big IT consulting firm was pushing for GUI, GUI, GUI!! Now, a lot of these same firms are moving back to keyboard-only interfaces. Pretty interfaces that need a mouse don't mix very well with repetitive tasks! As much as I hate time-motion studies, I think task time speaks, and IT firms have regressed back to keyboard-only environments.

The best practice here is design an interface that has a graphical feel that allows newbies to click, but also keeps the same shortcuts 20 year veterans are familiar with.

Not really. Both are systems the airport agents use. Those are the sets of tools provided to the agents. CO gives their agents SHARES; UA gives their agents Apollo + FastAir. From that perspective, that is absolutely the relevant comparison.Your focus on only one group misses all the other functions that the system plays into. If it was just the system that was in use in the airports then maybe you'd have a cogent claim. But it is more than that by far.

What you really appear to be saying is that you believe the FastAir GUI is better than the native SHARES GUI. That's a very different claim. And it is certainly one that is debatable.

I've seen a lot of reference to this, just how "robust" SHARES is, and how far it can extend, yadda yadda. What has CO actually done with it?A ton. Very little of the core functionality is 100% inside Shares and they're continuing to extract more and build the necessary additional layers to allow themselves the flexibility they need to operate.
If they haven't created a GUI after all this time, why would they now? The agent GUI is but one small part in this big game. And they have noted their intention to build it so I expect that they will.

While command line has a much steeper learning curve, I found users who are proficient (including myself) will prefer it over a GUI since it provides you with greater flexibility and allows you to navigate many functions more quickly. In addition, a proficient user can make quite a few keystrokes in the time it takes the hand to leave the keyboard, grasp the mouse, navigate and click it.

This isn't the relevant argument (as is the case in many other portions of this thread). Fastair is a keyboard driven overlay (yes, there is a GUI, but not all GUI systems are used with a mouse), it just automates common tasks reducing the amount of keystrokes required by a couple orders of magnitude.

Well, unless you have first hand experience it doesn't seem to be appropriate to pass of others' second hand comment as reality.

Yes, because there is a treasure trove of glowing reviews of dealing with CO agents on IRROPS issues and other flight-related tasks, and they're of course known for their great efficiency and speed, due to their amazing proficiency with a 1980s-style command line system (with shortcuts!) that makes it so easy on them.

:rolleyes:

Feel free to live in your own reality.

This isn't the relevant argument (as is the case in many other portions of this thread). Fastair is a keyboard driven overlay (yes, there is a GUI, but not all GUI systems are used with a mouse), it just automates common tasks reducing the amount of keystrokes required by a couple orders of magnitude.

I have never used Fastair, so thank you for your first hand (and objective) feedback. A keyboard driven GUI that automates common tasks would certainly be a valuable component of an airline reservation system.

Yes, because there is a treasure trove of glowing reviews of dealing with CO agents on IRROPS issues and other flight-related tasks, and they're of course known for their great efficiency and speed, due to their amazing proficiency with a 1980s-style command line system (with shortcuts!) that makes it so easy on them.

:rolleyes:

Feel free to live in your own reality.

Do you have first hand experience in regularly dealing with CO agents during IRROPS or are you basing your opinion on others' perspectives?

How does software make someone more empowered? :confused:



I can only guess you have been living under a rock form 30 years - the primary purpose of software is to make tasks easier for elope and therefore give them more control

While there are a few people who like command lines - ONLY diehard computer geeks would argue in this day and age that command line is how you would build a system for a major industry with 1000's who must be trained.

This isn't the relevant argument (as is the case in many other portions of this thread). Fastair is a keyboard driven overlay (yes, there is a GUI, but not all GUI systems are used with a mouse), it just automates common tasks reducing the amount of keystrokes required by a couple orders of magnitude.

Yes keyboard driven, where all menus are gotten to with a combo of shift/alt/ctrl and a function key, with another function key required after for many transactions. Not near as fast as typing exactly what you want from a command line. Highlighting various hot buttons per screen using alt+another key after navigating to a menu sure saves time over just typing the command (sarcasm.)

Now there are those that never learn the commands well, and for them, a slow crutch GUI is faster than calling for help or pulling out a reference book and experimenting. For me, native apollo is/was faster than fastair for most things.

This is not a defense of shares, as I have seen to many limitations of its functionality that I am used to be able doing, but for the proficient and intelligent, fastair was more of a box limiting our skills than a tool used to speed us up

For me, native apollo is/was faster than fastair for most things.

Out of curiosity, what things do you find it saving you time with?

And yes, agreed that those keys are likely not optimal. Keystroke comparison may be a tad exaggerated, and there are more metrics than keystrokes such as speed of the total transaction (which varies on your experience/training), error-proneness, total amount of "thinking" required to accomplish the task (e.g. there's a common usability "heuristic" of 3 clicks to get to whatever -- at least IMHO that's not useful as much as how easy those clicks are). Whether or not it's fast or at least should be faster, likely depends on a ton of factors including who you are, what training you had, and what you're trying to do.

However, at least in principle, the goal of such an overlay is two-fold of better efficiency and reduced training costs. Hopefully fastshares delivers on that reasonably ok. But UACO's decision process is somewhat hard to discuss without knowing the relevant cost figures (apollo licensing, training, whatever perceived productivity/service difference, fastshares development, etc).

...Do you have first hand experience in regularly dealing with CO agents during IRROPS or are you basing your opinion on others' perspectives?

We know the answer to this. As I have posted repeatedly in this forum, in my 10 years as a CO Plat CO agents have never let me down during IRROPs and issues have been handled expeditiously. Again, just because one or two posters repeat a certain mantra ad nauseum it doesn't make said mantra factual.

We know the answer to this. As I have posted repeatedly in this forum, in my 10 years as a CO Plat CO agents have never let me down during IRROPs and issues have been handled expeditiously. Again, just because one or two posters repeat a certain mantra ad nauseum it doesn't make said mantra factual.


That's good to hear that CO has done right by one customer. There are many other customers who have had IRROPS experiences with CO that were sub-par, and many customers with dual or multiple statuses who have the baseline which with to compare CO's treatment to another carrier's with like status.

Just because you repeat that ad nauseum dosn't make it factual. ;)

That said, very good attempt at trying to distract from one of the core issues in that the SHARES system will likely be slower than Fastair for rebookings/reaccommodation. Fortunately, after seeing Fastair, even CO realizes this, and is working on a replacement for Fastair.

The idea that SHARES is inferior for re-accomodation is quite misleading. In fact, CO's added functionality to SHARES often makes it more customer-friendly in the event of schedule changes and IRROPS to complex itineraries, as CO agents can reissue tickets on the spot while UA agents have to queue complex bookings for manual reissue, a process that can take anywhere from hours to months to complete.

I can only guess you have been living under a rock form 30 years - the primary purpose of software is to make tasks easier for elope and therefore give them more control.

Yes, software makes tasks easier, but that does not mean employees are empowered.

Empowerment is correlated to corporate culture and employee attitude, not how easy it is different tools with the same capability.

That's good to hear that CO has done right by one customer. There are many other customers who have had IRROPS experiences with CO that were sub-par, and many customers with dual or multiple statuses who have the baseline which with to compare CO's treatment to another carrier's with like status.

Just because you repeat that ad nauseum dosn't make it factual. ;)

That said, very good attempt at trying to distract from one of the core issues in that the SHARES system will likely be slower than Fastair for rebookings/reaccommodation. Fortunately, after seeing Fastair, even CO realizes this, and is working on a replacement for Fastair.

To avoid the appearance that you're intention is to inflame, rather than contribute, to the discussion, could you please tell us the dates and circumstances when you had sub-par IRROPS experiences with CO and explain how UA accommodated you better under similar circumstances. In addition, it would be helpful for you to share an objective source that confirms native Shares will be slower than Fastair for agents who are equally competent in both systems.

...To avoid the appearance that you're intention is to inflame, rather than contribute, to the discussion, could you please tell us the dates and circumstances when you had sub-par IRROPS experiences with CO and explain how UA accommodated you better under similar circumstances. In addition, it would be helpful for you to share an objective source that confirms native Shares will be slower than Fastair for agents who are equally competent in both systems.

That poster has, by his own admission, barely flown CO of late and so has little or no recent (at least) firsthand knowledge of that which he comments on.

The idea that SHARES is inferior for re-accomodation is quite misleading. In fact, CO's added functionality to SHARES often makes it more customer-friendly in the event of schedule changes and IRROPS to complex itineraries, as CO agents can reissue tickets on the spot while UA agents have to queue complex bookings for manual reissue, a process that can take anywhere from hours to months to complete.

???
I reissue them on the spot as well (PMUA CSR).

As to the question posed earlier as to what takes me longer on fastair than native apollo, anything that requires me to hit a modifier key (shift/ctrl/alt) plus a function key (f1-f12) then f3 again for next menus, select a choice on the next menu, before I can input my command. Sometimes the command will requires multiple selections of radio buttons as well (wither tab tab tab space, or another combination of alt+key.) There is no question that the GUI helps in many tasks, preventing invalid commands (each incurring GDS fees) from being sent to Apollo, and some of the drop down menus, like if I forgot the city code for a particular airport, I don't need to look it up in a profile, I can just use the f2 menu to show me a list of the pre-programmed options.

I guess I consider myself an artist, and like the ability to be an artist. Making an artist use a GUI instead of native tools to directly interact with the base system is like wearing generic condems...it kinda takes the feeling and fun out of the art.

One think I will like is the multiple application windows back again with Shares. Fastair has them as well, but they are software driven, where they can be covered up by the GUI overlay (or error messages) or the responce is directed by the software to a particular window, not always the one you want it to be directed to. (examples of when this would be handy is when building pricing records, unpricable tickets, or any form where one needs to copy something from another screen without it being covered up or written over.) Oh, and "S*" profiles. The fastair GUI cannot handle tab stops, so it goes from a gui interface into the native responce, then when you scroll down enough that a tab stop isn't activly displayed on the screen, it switches back to gui mode. On a 200 line profile (or an agency reservation,) displaying only 20 or so at a time with numerous tab stops, the constant automatic switching between native display and GUI is a BIG pain in the butt.

That "window dressing" is what makes UA agents more empowered and faster as like tasks relative to their CO counterparts, not sure why you're so dismissive of that. I bet it will be a blast for them typing command lines in the coming year.

Really? I believe AA still uses command-line SABRE with no GUI overlay, and if you get an experienced agent, they can move mountains for you very quickly (especially if you're an elite). Now, of course, PMUA agents won't be experienced with SHARES in the first few months, but that was inevitable one way or the other (PMCO staff would have had the same problem if the migration had been done in the other direction, and everyone would have had a learning curve if they had decided to go with the consolidated Star Alliance Altea).

as CO agents can reissue tickets on the spot while UA agents have to queue complex bookings for manual reissue, a process that can take anywhere from hours to months to complete.
I think you have that the opposite way...

I think you have that the opposite way...

Yes ua is a simple process -CO IS COMPLEX

To avoid the appearance that you're intention is to inflame, rather than contribute, to the discussion, could you please tell us the dates and circumstances when you had sub-par IRROPS experiences with CO and explain how UA accommodated you better under similar circumstances. In addition, it would be helpful for you to share an objective source that confirms native Shares will be slower than Fastair for agents who are equally competent in both systems.


Nobody is trying to inflame. Just because what I say doesn't make CO look good, doesn't make it inflammatory. I speak from multiple years of experience of status on CO and other carriers including UA and DL.

It has almost always taken longer to rebook on CO than on UA when at the airport, even when staying inline.

In addition, in IRROPS situations, I have encountered far more resistance in swapping airports for reasonable alternates to get moving in the right direction. UA has gladly substituted SMF for SFO in an IRROP on a handful of occasions. Meanwhile, CO has pushed back on similar such requests, and I've had to escalate and/or make multiple phone calls to get the same result.

I suspect that the resistance is somewhat systems related. Since the system is so cumbersome, agents make excuses not to accommodate.

CO agents can reissue tickets on the spot while UA agents have to queue complex bookings for manual reissue, a process that can take anywhere from hours to months to complete.

Really? One of my colleagues is married to a UA CSR. I showed him the above statement and asked him to check with the spouse, and was told that your claim is absolutely false.

The idea that SHARES is inferior for re-accomodation is quite misleading. In fact, CO's added functionality to SHARES often makes it more customer-friendly in the event of schedule changes and IRROPS to complex itineraries, as CO agents can reissue tickets on the spot while UA agents have to queue complex bookings for manual reissue, a process that can take anywhere from hours to months to complete.


This is incorrect. UA agents can reissue tickets, but UA business process has the back office do them unless they're urgent. This helps free up agents to handle additional calls.

If you're travelling imminently or have a special request (e.g., I need to upgrade to snag this space), they will do it for you, but under normal circumstances (e.g., schedule change for a flight in 2 months), they'll just toss it in the hopper for the back office to do.

Nobody is trying to inflame. Just because what I say doesn't make CO look good, doesn't make it inflammatory. I speak from multiple years of experience of status on CO and other carriers including UA and DL.

It has almost always taken longer to rebook on CO than on UA when at the airport, even when staying inline.

In addition, in IRROPS situations, I have encountered far more resistance in swapping airports for reasonable alternates to get moving in the right direction. UA has gladly substituted SMF for SFO in an IRROP on a handful of occasions. Meanwhile, CO has pushed back on similar such requests, and I've had to escalate and/or make multiple phone calls to get the same result.

I suspect that the resistance is somewhat systems related. Since the system is so cumbersome, agents make excuses not to accommodate.

I really don't think vague speculation being passed off as fact is contributing to the forum. Without qualifying your opinion as such or providing facts to support your statements, your posts serve no purpose but to further the inflammatory (and oft-repeated) party line of UA good, CO bad.

I really don't think vague speculation being passed off as fact is contributing to the forum. Without qualifying your opinion as such or providing facts to support your statements, your posts serve no purpose but to further the inflammatory (and oft-repeated) party line of UA good, CO bad.


I don't think UA is good or CO is bad. I think that CO isn't as good as it's often hype to be, and UA isn't as bad as it's often vilified to be. Big difference.

CO and UA both have their strengths and weaknesses. On this topic, I think that CO's interface for the agents is weak, and I'm glad that CO sees the light now and is working on a solution.

I have a friend who works for UA and just started SHARES training - my, oh my, how the foul language pours forth when he describes the system. :p

Wirelessly posted (Mozilla/5.0 (Linux; U; Android 2.2.2; en-us; MB612 Build/KRNS-X4-1.1.10) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1)

I have a friend who works for UA and just started SHARES training - my, oh my, how the foul language pours forth when he describes the system. :p

I talked to an agent the other day who said she likes SHARES because she used to work for TWA and the interface will make her feel young again. :)

My input on this whole thing...

For the record, I'm not currently a UA(X) employee, as I'm back in college. That said, I worked PWM for 2+ years. I consider myself incredibly proficient with FastAir, and more often than not if a coworker had a question, they'd come to me. I'm younger, and have worked with computers my whole life, so it really did come easy to me.

I was nervous when I first started training in FastAir. The first 5% of the program is difficult to learn, but the next 85% is very intuitive once you have that base. That last 5% most people don't learn and don't need to, stuff that we hardly ever do.

Just to reiterate, we don't use a mouse with FastAir. The Function keys combined with the Shift, Alt, and Control buttons pull up different menus, and we select options from these menus. For instance, to print a Gate Pass (If I remember correctly, it's been 3 months), we go Alt+F3, letter K. That's it. Super quick, super simple, type the Name, Gender and DOB and you're good. I've seen CO take about 2 minutes to do the same function. That's a real simple example that it takes longer with SHARES. Checking a bag? Alt+F7, Enter. Type in the number of bags, enter, and you're done. 4 keystrokes.

Did I find myself forgetting which menu a certain option (say, splitting a PNR) was? Sure, but it doesn't take long at all to find the right option and move on from there.

As far as IRROPS handling...let's assume there was availability on flights and we're not searching for flights, because that happens with any airline. No availability makes it tough regardless of which system you're on.

I've rebooked an entire 700 by myself in about 15 minutes, including issuing new tickets. Do the math. 4+ passengers a minute on the next available flight. I really wish I could show people just how easy it is (again, assuming availability) to rebook people via FastAir, including reissuing/revalidating the E-Tickets.

In contrast, I've witnessed a former coworker who works for CO rebook an E145 to EWR. 35 pax were going JUST to EWR, and they had 50 seats on the next flight. It took her 2 hours. And she knows the system! I've seen it in action, and pure keystroke wise, it's much longer. It's also much more prone to errors, causing people to have to take even longer.

Again, I've never worked with SHARES but two former coworkers now work for CoEx, one of them formerly working with FL and NW as well. Both agreed that FastAir was the easiest to learn and master, by far.

It's a shame that the GUI overlay won't be ready in time. That way, UA could do it the way they know how, and CO could do it the way they know how...though all the other airlines are jealous of FastAir, so maybe they'd transition over.

As far as Apollo goes...I know very, very little. I know how to build PAWOBS, update Flifo, and that's it. But we can also update Flifo via FastAir. Let me tell you, FastAir is MUCH faster (And I learned the Apollo way first).

Updating Flifo in FastAir: F9, F3, 6, Out, 630P, delay code if applicable.
Updating Flifo in Apollo: F:S372911NOV:Out:1830:delay code (....I think. I honestly can't remember. I have to look at the paper we have posted every single time to make sure my syntax is correct and everything's in just the right place. Don't need to worry about that in FastAir)

I've rebooked an entire 700 by myself in about 15 minutes, including issuing new tickets. Do the math. 4+ passengers a minute on the next available flight. I really wish I could show people just how easy it is (again, assuming availability) to rebook people via FastAir, including reissuing/revalidating the E-Tickets.

That's amazing.

CO has taken 15 minutes just rebooking me (or rebooking me + companion). And that does not include the prodding and cajoling that sometimes has to be done to convince CO to rebook in the first place.

Part of it is the software, but I think part of it is also business process. For inline tickets, UA often just reuses/reassociates the existing ticket to the new reservation, even if swapping airports (connecting or final destination) or changing the number of segments. CO, OTOH, likes to reissue tickets for every little change. And as you've pointed out, things like reissues can be cumbersome in SHARES.

I shudder to think what the CS lines will be like after the SHARES roll-out, and UA cancels a full 767. Or an outstation with low staffing levels cancelling a mainline flight.

+1. Thanks for the great, informative post PWMRamper. Some say having an opinion based on past experiences doesn't add much to the conversation, especially if it's anti-CO. Looks like you've experienced first hand what many of us are saying. SHARES is a step back for the company.

Really? One of my colleagues is married to a UA CSR. I showed him the above statement and asked him to check with the spouse, and was told that your claim is absolutely false.

It is very much the case that many complex itineraries will not be instantly reissued by UA CSRs, while it's quite rare for CO agents to have to queue a booking for reissue.

+1. Thanks for the great, informative post PWMRamper. Some say having an opinion based on past experiences doesn't add much to the conversation, especially if it's anti-CO. Looks like you've experienced first hand what many of us are saying. SHARES is a step back for the company.

SHARES is not a step backward --- and using Apollo would not be a step forward, either. The systems have different strengths and weaknesses (SHARES/EUA blows Apollo/UDU out of the water in terms of the ability of the reservation to be updated in real time, even after check-in, preventing the goofy scenario of trying to convince a UA agent you've been upgraded while s/he is convinced you're still in Coach because the DCS tells him/her so), and as posts from those who have used either or both systems as a routine part of their job attest, the key to any effective RES/DCS system use is familiarity and training.

It is very much the case that many complex itineraries will not be instantly reissued by UA CSRs, while it's quite rare for CO agents to have to queue a booking for reissue.


That has nothing to do with systems, it has to do with business process.

UA's position is to not tie up the agent with reissuing tasks unless necessary. CO, OTOH, ties up the agent (and the customer) until it's done.

To that end, UA CSRs will often queue not just complex itins, but also simple itins, because they have a department that specializes in that, and it helps them handle additional customers.

Hi Everyone,

It should come as no surprise that we are in the process of migrating several of our platforms into single systems for the new United. Our reservations system is one of these. As you can imagine, this is a comprehensive project that requires careful coordination of several moving pieces. One of the most important pieces is ensuring our front line colleagues are fully trained on this new platform. As part of this training, we’ve shared with our teams a target date. But, to be frank, there is flexibility that this date could change. Once we have a firm date, we’ll share it with you here (likely after the first of the year). In the meantime, we remain on track to complete our migration sometime late in the first quarter of 2012.

Shannon

Let us be totally clear the ONLY reason we are getting SHARES is because that is what CO uses and as we seen so many times in this merger of equals - almost all of the systems that survive are the CO ones. Now - I've become increasingly concerned about this migration as I've seen and experienced how bad shares is because of its complexity. Iprops or upgrades appear to fool the system and can lead to legs being left on that are then unflown - leading to the remainder of the itinerary being cancelled - UA would be better off stayingmwithnfast air till fast shares is ready

Lets be totally clear on this. The ONLY reason SHARES is being used is that it is now OWNED by United. Why should they subscribe to an expensive, outdated PSS system when they can use a system that they do not have to pay subscription fees. This is purely a business decision and like it or not United is a publicly traded company. BTW, CO already uses a on overlay res system called EZR which is similar to FastRes. FastSHARES is already being written now which will mirror or improve FastAir. By owning their own PSS system, UA is free to update and reprogram it as needed. There are two companies merging who used two different PSS systems, either way we look at it half of the employees were going to have to learn a new system anyway. The UA employees have to learn SHARES in order to understand the new FastSHARES just as the Co staff would have had to learn APOLLO to understand and operate FastAir. Both systems have their plusses and minuses and in the end it will work out.

I have a friend who works for UA and just started SHARES training - my, oh my, how the foul language pours forth when he describes the system. :p

+1

Last time through one of the RCCs, I spoke with a couple of the agents I know and heard the same thing.. One said she was ready to pull her hair out. :eek:

It is very much the case that many complex itineraries will not be instantly reissued by UA CSRs, while it's quite rare for CO agents to have to queue a booking for reissue.

I'm confused. First you said that UA CSRs "have to queue complex bookings for manual reissue, a process that can take anywhere from hours to months to complete," but it's just "many complex itineraries will not be instantly reissued."

So which is it? UA CSRs must send all complex bookings elsewhere, or just some?

Shares is owned by United in name only - this is part of CO - also it is not necessary to fully understand the underlying architecture of Appolo to use Fast air.


Lets be totally clear on this. The ONLY reason SHARES is being used is that it is now OWNED by United. Why should they subscribe to an expensive, outdated PSS system when they can use a system that they do not have to pay subscription fees. This is purely a business decision and like it or not United is a publicly traded company. BTW, CO already uses a on overlay res system called EZR which is similar to FastRes. FastSHARES is already being written now which will mirror or improve FastAir. By owning their own PSS system, UA is free to update and reprogram it as needed. There are two companies merging who used two different PSS systems, either way we look at it half of the employees were going to have to learn a new system anyway. The UA employees have to learn SHARES in order to understand the new FastSHARES just as the Co staff would have had to learn APOLLO to understand and operate FastAir. Both systems have their plusses and minuses and in the end it will work out.

Actually, just to clarify for everyone:

SHARES is not owned by the company.

HP owns it, EDS hosts the system.

Also:

Shares is owned by United in name only - this is part of CO - also it is not necessary to fully understand the underlying architecture of Appolo to use Fast air.


It's always good to know the underlying mainframe. Sometimes the GUI will go down (yes, even FastAir has crashed). Then what?

The native SHARES training isn't for naught.

+1

Last time through one of the RCCs, I spoke with a couple of the agents I know and heard the same thing.. One said she was ready to pull her hair out. :eek:

I have seen reactions like that out of a number of UA employees when traveling through one of the hubs.. Shares sounds awful..

though it could also just be people don't like change;)

Shares is owned by United in name only - this is part of CO - also it is not necessary to fully understand the underlying architecture of Appolo to use Fast air.

As Sully correctly points out, Shares is not owned by CO or UA, but by HP and managed via HP's EDS. I have had a CO supervisor come to our break room to discuss Shares, and he stated incorrectly, as many do, that CO ownes shares. CO does not own Shares anymore than UA ownes Apollo or AA owns Sabre.

The costs are lower and the pricing for incrimental use/software development allegdly is less (I have heard that CO can impliment changes in house, but I don't know that to be true, only what I have heard.)

Shares is owned by United in name only - this is part of CO - also it is not necessary to fully understand the underlying architecture of Appolo to use Fast air.


SHARES might have been part of CO but CO and UA are soon to be one so it's a pretty moot point. Either way UA can end it's user agreement with APOLLO and use a system it will eventually own. Makes perfectly good business sense. SHARES might be a bit cumbersome, but anyone who is proficient with it needs little or no support from help desks. Changing flight and re (sync)ing an itinerary is fairly easy and requires no no ticket re issuing what so ever. There is no queing of a ticket at all. In shares once a ticket is reissued you can be checked in immediately, or within a few minutes if there is an OA downline connection to recieve the connecting BP. It may not be necessary to to fully understand the underlaying archetecture to use a system but it greatly helps when situations occur out of the norm. I've seen many more senior UA agents toggle from FASTAIR to native APOLLO when they get in a jam. FASTSHARES promises to be as easy as FASTAIR but hopefully the ability to toggle back to native SHARES will remain so an experienced rep can complete a transaction effectively.

I always keep in mind that the other serious option available to me, Delta, uses the astonishing wonder that is Deltamatic, the most shambolic system ever devised. All things are relative under the sun.

As an interesting historical note, IIRC United created Apollo and then spun it off at some point into a separate business.

I'm confused. First you said that UA CSRs "have to queue complex bookings for manual reissue, a process that can take anywhere from hours to months to complete," but it's just "many complex itineraries will not be instantly reissued."

So which is it? UA CSRs must send all complex bookings elsewhere, or just some?

There's no need for confusion on this point. Any booking whose e-ticket cannot be exchanged on the spot using the prompts in Fastair must be queued for manual reissue.

As an interesting historical note, IIRC United created Apollo and then spun it off at some point into a separate business.

Yes. And the old United Connection software, which many users loved, was about the simplest overlay of Apollo that lay people ever had the opportunity to use.

There's no need for confusion on this point. Any booking whose e-ticket cannot be exchanged on the spot using the prompts in Fastair must be queued for manual reissue.

We've already heard from one United employee who says that isn't the case. So I'm still confused. :D

We've already heard from one United employee who says that isn't the case. So I'm still confused. :D

I wonder if it depends upon the agent's familiarity with the underlying Apollo system. Most likely there are agents who grew up with the FastAir shell and have rarely, if ever, dropped to the Apollo command line. If they can't do something in FastAir, they're better off passing the request on to a colleague/supervisor or referring it to the back office, rather than wasting time fumbling around.

In my younger days, I've actually used Apollo myself. It was a bear to learn, like all such early-vintage command-line systems, but once I knew the obscure commands I needed to use, I never bothered with the menu systems again. Fortunately I'm not a travel professional, because I'd hate to be forced to learn another one of these systems with an entirely different set of codes.

just as the Co staff would have had to learn APOLLO to understand and operate FastAir. Both systems have their plusses and minuses and in the end it will work out.

You don't need to know anything about Apollo to use FastAir. I didn't TOUCH Apollo until I went to Baggage Service training.


I've never had a problem reissuing/exchanging tickets via FastAir, assuming United has control of the e-ticket. And I've rebooked pretty complex itineraries before.

Really? I believe AA still uses command-line SABRE with no GUI overlay, and if you get an experienced agent, they can move mountains for you very quickly (especially if you're an elite). Now, of course, PMUA agents won't be experienced with SHARES in the first few months, but that was inevitable one way or the other (PMCO staff would have had the same problem if the migration had been done in the other direction, and everyone would have had a learning curve if they had decided to go with the consolidated Star Alliance Altea).

It would've been quicker and cheaper to retrain the CO employees to the UA res system, since there are less CON-men in the system.

Of course, Jeff wouldn't want to alienate his people, therefore the step children (UA) get the short end of the stick. :rolleyes:

You don't need to know anything about Apollo to use FastAir. I didn't TOUCH Apollo until I went to Baggage Service training.


I've never had a problem reissuing/exchanging tickets via FastAir, assuming United has control of the e-ticket. And I've rebooked pretty complex itineraries before.

Again, PWM is correct.

"dropping down to Apollo" isn't as easy as you thing. There is a command (Alt-F3, number 6) that lets you type in native commands, but in 95% of the time, fastair has been programmed to not accept what you type, but instead directs you to the fastair menu that it thinks will be the one needed to accomplish the task.

Almost all CSR desktops don't even have the stand alone "native Apollo" loaded onto it to launch and use separatly, and if they do, it will only display/launch if you are in a job where the mgmt people that authorize what your used ID allows you to do, think you need to use it. (There are some apollo functions that in it's basic design, the GUI makes impossible, and as such, those specialty areas and agents have access to it <example, controll center, ACI (the people that "create" your flight for checkin,) and the apollo help desk (currently being eliminated.>)

For the non-apollo trained, fastair works more than sufficiently, and is faster than Apollo For the "expert user" who does manual intl rates-and I don't me reissuing a ticket as an "invol", but building/constructing a fare when it won't autoprice (a long dead skill at the airport) The raw, un-modified power of direct access to the native functions cannot be underestimated.

Fastair wasn't perfect when it came out. I was a beta tester of it back in the late 90's, and it was ok in it's original basic form, but wasn't programmed to handle many specific functions that don't happen on every transaction. Over the last decade, the programmers have added to it, tweaked it, and made it better. I became "fastair" (FT handle as well as a few other names) long before I used it regularly. For the longest time, I would launch both Apollo and fastair, use fastair for basic checkin, and toggle to Apollo for more complex functions/functions not yet supported by fastair. They tracked your useage, and you were required to use fastair for something like 90% of transactions. It didnt take long to figure out that the only transaction they tracked was "passengers checked it" so it was easy to cheat that stat, suing Apollo for 90% of the time, and fastair for 90% of the trackable transactions.

I am NOT a fan of teaching people how to use a GUI without teaching them the underlying logic that is what drives it.
Fastair was invented to:
a) keep training costs down (it takes less time to teach on the GUI as they don't teach the underlying logic that can make one a true expert)
b) reduce GDS fees (fastair's logic links multiple commands that are charged individualy by the GDS into a single transaction, and also does not allow the user to send "typos" that will get charged but return an error.)
c) prevent agents from being trained a skill on a GDS system at the company's expense, and then have the agents quit to go work for a travel agent making much more money.
d) speed up basic processes.

For those goals, fastair did a great job. Traing time was cut from a few months to 1/2 that. I can only assume GDS useage fees were reduced, or at least chargable transactions. Agents don't get hired by agencies for their proficiency in "fastair", and as we all know a basic invol reissue or rebooking and transfer of baggage to new flight is much faster using UA's fastair that CO's native shares. Successes on all fronts.

I don't see any major issues other than massive codeing to get a useable GUI over Shares, that in time will become as useable as fastair is. I personally like using command line stuff, as it makes me learn it better, but I understand that the corporate world today is about cheap labor turning out produc as fast as possible, not about artestry or expertese. We are all a commodity, and in lower unit costs, higher utilization, greater quantities of processing leads to better profitability in the assembly line.

I've never had a problem reissuing/exchanging tickets via FastAir, assuming United has control of the e-ticket. And I've rebooked pretty complex itineraries before.


Again, there's a business process issue.

IME, CO tends to reissue the whole e-ticket, while UA tends to void off the affected coupons and reissue those, leaving the remainder of the original e-ticket in tact.

After talking to several UA agents in the last week, two (one PMUA at IAH and one at DCA) somewhat-jokingly said they were calling in sick that week.

What do we think the likelihood of an actual "sick-out" is that week? Does UA have some sort of compensation / incentive plan that week to help stop things like that from happening?

What do we think the likelihood of an actual "sick-out" is that week? Does UA have some sort of compensation / incentive plan that week to help stop things like that from happening?


The Smisek video is just one part of the mind-programming exercise to endear employees, er, co-workers, to the new leadership. They have cool new hats, the shiny gold pins, and soon new uniforms. After receiving all of that schwag, combined with being told that they're the "best in the industry" with a genuine and endearing smile by their fearless leader, I don't think we'll see anything of the sort. If anything, the co-workers will likely be eager to use the new system, despite it taking 3x as long to perform the same tasks.

It would've been quicker and cheaper to retrain the CO employees to the UA res system, since there are less CON-men in the system.

Of course, Jeff wouldn't want to alienate his people, therefore the step children (UA) get the short end of the stick. :rolleyes:

If the gates and ticket counters were the only place the system was used, you might have a point. However, the reservation system is the underlying technology for the entire airline and there are much broader (and costly) considerations then how easy it is to train employees in the new reservation system.

After talking to several UA agents in the last week, two (one PMUA at IAH and one at DCA) somewhat-jokingly said they were calling in sick that week.

What do we think the likelihood of an actual "sick-out" is that week? Does UA have some sort of compensation / incentive plan that week to help stop things like that from happening?


The Smisek video is just one part of the mind-programming exercise to endear employees, er, co-workers, to the new leadership. They have cool new hats, the shiny gold pins, and soon new uniforms. After receiving all of that schwag, combined with being told that they're the "best in the industry" with a genuine and endearing smile by their fearless leader, I don't think we'll see anything of the sort. If anything, the co-workers will likely be eager to use the new system, despite it taking 3x as long to perform the same tasks.

Perfect attendance program for line employees. Vehicles (not just one but several to different work groups) given away via drawing . The company pays all fees associated with the transaction so that the employee is not hit with the tax bill.....but I guess that is "nothing of the sort" :rolleyes:

If the gates and ticket counters were the only place the system was used, you might have a point. However, the reservation system is the underlying technology for the entire airline and there are much broader (and costly) considerations then how easy it is to train employees in the new reservation system.

@:-)
Interesting that some who like to throw out "small ball" and other nonsense terms don't include the whole picture when it doesn't serve their argument.

You are absoluetly correct. All kinds of other pieces and hooks that are included, with the Website being the largest. Also - The gate reader application, SOCC feeds, FLIFO, Baggage Tracing, etc.

@:-)
Interesting that some who like to throw out "small ball" and other nonsense terms don't include the whole picture when it doesn't serve their argument.

You are absoluetly correct. All kinds of other pieces and hooks that are included, with the Website being the largest. Also - The gate reader application, SOCC feeds, FLIFO, Baggage Tracing, etc.

In addition to operating systems, reservation platforms also drive back office and financial systems.

In addition to operating systems, reservation platforms also drive back office and financial systems.

+1

Also, SHARES has one aspect that Apollo simply doesn't have. SHARES is supported by EDS, a Texas-based company, which no doubt has some board cronie-connection.

+1

Also, SHARES has one aspect that Apollo simply doesn't have. SHARES is supported by EDS, a Texas-based company, which no doubt has some board cronie-connection.

Typical :rolleyes:
You do realize that EDS is no more, right? Not even considered a wholly owned subsidiary. HP Enterprise Services -- HP - A Palo Alto, CA company?

You SHARES haters can go on denying that there was considerations other than the RES/PSS piece used to make a decision on the RES/PSS system There are LOADS of other reasons that are considerations.

You SHARES haters can go on denying that there was considerations other than the RES/PSS piece used to make a decision on the RES/PSS system There are LOADS of other reasons that are considerations.


I get it.

I just would like to see the CO lovers recognize that SHARES is a downgrade from a consumer perspective, particularly with respect to airport customer handling, for someone who comes from the UA side.

It's not about the system being different or agents being averse to change. It's about the system being orders of magnitude more primitive, and that will result in slower handling and as a result of normal human behavior, likely more pushback or resistance to requests.

There are other issues, but they're actually not SHARES-related, rather they're related to CO's architectural choices in terms of dealing with SHARES. Instead of coding functionality into SHARES, CO tends to overlay items (e.g., EUA is one example) which results in systems not being as tightly integrated into the core system, which results in the kludges that they have today.

I get it.

I just would like to see the CO lovers recognize that SHARES is a downgrade from a consumer perspective, particularly with respect to airport customer handling, for someone who comes from the UA side.

It's not about the system being different or agents being averse to change. It's about the system being orders of magnitude more primitive, and that will result in slower handling and as a result of normal human behavior, likely more pushback or resistance to requests.

There are other issues, but they're actually not SHARES-related, rather they're related to CO's architectural choices in terms of dealing with SHARES. Instead of coding functionality into SHARES, CO tends to overlay items (e.g., EUA is one example) which results in systems not being as tightly integrated into the core system, which results in the kludges that they have today.

Yes. But nothing is as bad as DELTAMATIC which, in tandem with Jeff R's ideology, delivers :-: best in class :-: service.

On CO.COM for example, I never see an award costing anything other than SaverPass (1x published), or SleazyPass (2x Saver). On DL.COM, presentation of outrageous and unpublished multiples of the three "official" SM levels is a daily event...and of course, never in a lesser direction. Remember the 635k SM demand for PHL-FCO, not all of which was in J? Just read the DL forum to see how bad it is. How can this be described as anything other than :-: best in class :-:? And the SMS agent award fandango, e.g. agents routinely denying MH or CZ are ST members/SM partners...ah, another peak pleasure of Medallion status. You guys have time/enthusiasm for all that?

And system repricings during purchase? Inability to use the published "rebook" features etc. There is no contest. The DL.COM/DELTAMATIC tandem is by miles, the worst imaginable. SHARES has a long way to go to plumb those depths.

I'm not saying CO's IT is perfect. I certainly agree that the res system transfer will entail speed bumps. It might be good to not be traveling on CO res during the couple weeks after the system merge next March. I'm taking note. But I have to laugh at the idea it can be as bad as DL except possibly for those few weeks after the merge.

But remember, system updates on CO often present opportunities - like the mass FD scenario that occurred on the night of the Star integration. Remember those 270 USD tix to FCO/TXL etc? Probe the system on the night of March 2nd and we might find some real gems.

And, rah! rah! So there!

Yes. But nothing is as bad as DELTAMATIC which, in tandem with Jeff R's ideology, delivers :-: best in class :-: service.

On CO.COM for example, I never see an award costing anything other than SaverPass (1x published), or SleazyPass (2x Saver). On DL.COM, presentation of outrageous and unpublished multiples of the three "official" SM levels is a daily event...and of course, never in a lesser direction. Remember the 635k SM demand for PHL-FCO, not all of which was in J? Just read the DL forum to see how bad it is. How can this be described as anything other than :-: best in class :-:? And the SMS agent award fandango, e.g. agents routinely denying MH or CZ are ST members/SM partners...ah, another peak pleasure of Medallion status. You guys have time/enthusiasm for all that?

And system repricings during purchase? Inability to use the published "rebook" features etc. There is no contest. The DL.COM/DELTAMATIC tandem is by miles, the worst imaginable. SHARES has a long way to go to plumb those depths.

I'm not saying CO's IT is perfect. I certainly agree that the res system transfer will entail speed bumps. It might be good to not be traveling on CO res during the couple weeks after the system merge next March. I'm taking note. But I have to laugh at the idea it can be as bad as DL except possibly for those few weeks after the merge.

But remember, system updates on CO often present opportunities - like the mass FD scenario that occurred on the night of the Star integration. Remember those 270 USD tix to FCO/TXL etc? Probe the system on the night of March 2nd and we might find some real gems.

And, rah! rah! So there!


I see your point, but I think that's a bit of an apples-to-oranges comparison.

Deltamatic has a reasonable front end for its agents. Heck, every major carrier has a front end for its agents (with the exception of CO). The order of magnitude of change required in this transition is phenomenal.

As for your award booking example, yes, DL has had its pricing anomalies on its website. They have a hard time getting the logic right, especially on multiple cabins and multiple carriers. There are ways to use that to your advantage, but we won't get into that here.

So what you end up with in a Deltamatic-like system is a phone call and a manual pricing override for your award bookings (or a non-FTer overpaying for their award). With the SHARES transition, the parallel example is the rebook/reissue line is too long and/or the agent plays dumb like they can't see the OAL space, and you're spending the night at the Ramada instead of getting home. Because instead of a few keystrokes and a minute of time, that reissue to AA became a 15-minute ordeal, and they're willing to say or do anything to get out of doing it.

And IME with DL, worst case, if they have trouble with your ticket, they have no problem printing it to paper and getting you on your way. On CO, paper tickets is a big no-no. Even if it costs them more than it's worth, good luck getting CO to print paper.

I've been watching a lot of the back and forth debate about which system (APOLLO or SHARES) is better and my conclusion is that SHARES is probably the better underlying system. However, the legacy user interface for SHARES apparently puts it at a disadvantage compared to APOLLO when coupled with the FASTAIR interface.

As a passenger, my ideal for any GDS/reservation would be smooth implementation, fast response during all operations including irrops, reliability, and a system that makes job of the GA that I'm dealing with right now as easy as possible (a happy GA more often results in a happy customer).

So what will actually happen in March?

Will there be a systemwide mess like the one that occurred when US changed systems?

Will IRROPS handling be delayed/prolonged resulting in missed connections etc.?

Will the system perform as it has? As it should?

Will the GAs be overstressed or overworked and unwilling or unable to deal with even simple requests?

These are the things that will actually matter to the customer in March.

For all of the bickering about which system is superior, I'm not seeing many FT'ers making bold predictions about how smoothly this transition will go. How many of us think that the change will blow up in UA's face and they'll end up on the national news just like US did? How many think it won't, and why?

UA INSIDER earlier alluded to the date being potentially flexible if they're not ready by March. Anyone want to put some skin in the game about when they'll really be ready?

How about when the new UI for SHARES will be ready? After all, that's the thing that should really make the merged airline's reservation system shine.

[Disclaimer: I just had today's entirely upgraded itinerary blow up due to a delayed flight and now I'm stuck in the last row E- on a transcon plus I've got a late night flight on a CRJ... So I'm not feeling optimistic!]

I get it.

I just would like to see the CO lovers recognize that SHARES is a downgrade from a consumer perspective, particularly with respect to airport customer handling, for someone who comes from the UA side.

It'd be more accurate to say that a transition from a GUI to command line interface is difficult and could result in slower response times for customers as employees become more comfortable with the system.

However, for several reasons, the violent opposition to SHARES could seen as an overreaction. First, there's risk during any system transition, even to a simplified GUI, that customer service will be impacted. In addition, any period where front-line airport staff only have access to a command line system is expected to be short lived, not to mention becoming proficient in the command line environment usually means users are more proficient in the system over the long-run. Since the reservation system impacts all aspects of the customer experience - not just at the ticket counter or gate - focusing on a limited number of touch points is myopic.

It's not about the system being different or agents being averse to change. It's about the system being orders of magnitude more primitive, and that will result in slower handling and as a result of normal human behavior, likely more pushback or resistance to requests.

Some of your concerns about customer service are valid, but they should be addressed with trainings and staffing, not choosing a system to provide a short-term fix to one portion of a large organization. Further, you continue to ignore the fact that the systems are of similar age and technology. Trying to paint one as sophisticated and the other as primitive is disingenuous.

I just would like to see the CO lovers recognize that SHARES is a downgrade from a consumer perspective, particularly with respect to airport customer handling, for someone who comes from the UA side.

When hell freezes over ;)

Funny how the most applicable insights from pax who have extensive experiences on both airlines, and have seen what happens when things go south (such as yourself) and those on the inside who have seen both in action (thank you PWMRamper) are either discredited or mostly ignored.

It'd be more accurate to say that a transition from a GUI to command line interface is difficult and could result in slower response times for customers as employees become more comfortable with the system.

I disagree. I think it will be a longer term problem, so long as there is no GUI.

Ask your average CO agent how long it takes to reissue a ticket to AA, and ask your average UA agent the same.



However, for several reasons, the violent opposition to SHARES could seen as an overreaction. First, there's risk during any system transition, even to a simplified GUI, that customer service will be impacted. In addition, any period where front-line airport staff only have access to a command line system is expected to be short lived, not to mention becoming proficient in the command line environment usually means users are more proficient in the system over the long-run. Since the reservation system impacts all aspects of the customer experience - not just at the ticket counter or gate - focusing on a limited number of touch points is myopic.

I understand your point. But we're not talking a transition -- we're talking about a fundamental shift in design of the interface.

It's not whether a command is F2 or F7 or Control-F. It's a couple of keystrokes vs. long strings of commands that are prone to errors or syntax issues.


Some of your concerns about customer service are valid, but they should be addressed with trainings and staffing, not choosing a system to provide a short-term fix to one portion of a large organization. Further, you continue to ignore the fact that the systems are of similar age and technology. Trying to paint one as sophisticated and the other as primitive is disingenuous.

I disagree that training and staffing can address my customer service concerns. There is a huge human element to many of these customer interactions, and anyone who works in or with an airline realizes that a lot of things are gray and can be done but are not always done, and can be justified or dismissed.

And these technology choices impact other metrics elsewhere in the organization. Is there a relationship between CO's industry-leading IDB rate and their cumbersome technology interface for airport agents? Perhaps if they could rebook OALs in a minute or so, they would have been more willing to look for better OAL protection to entice more VDBs to reduce the IDB rate.

As for the ages of the systems, I believe SHARES is much older than FastAir. As for comparing the airport agent interface, that's the relevant comparison.

I disagree. I think it will be a longer term problem, so long as there is no GUI.

Ask your average CO agent how long it takes to reissue a ticket to AA, and ask your average UA agent the same.

From all accounts, the lack of a GUI will be a short-term situation... :confused:

Besides, does it really make sense to invest in developing and maintaining a tool to enable an easier transfer of revenue to your competitors?

I understand your point. But we're not talking a transition -- we're talking about a fundamental shift in design of the interface.

Are you privy to information that the rest of us aren't, or are you just making ASSumptions?

I disagree that training and staffing can address my customer service concerns. There is a huge human element to many of these customer interactions, and anyone who works in or with an airline realizes that a lot of things are gray and can be done but are not always done, and can be justified or dismissed.

If training and staffing can't address your customer service concerns, why bother having employees to begin with? Why not fire all of the front line staff and invest the dollars in developing an actual state-of-the-art system?

As for the ages of the systems, I believe SHARES is much older than FastAir. As for comparing the airport agent interface, that's the relevant comparison.

Fastair is not a system and you can't compare its age to SHARES.

My biggest fear is that post March 3rd management will decide, Hey! we've got everyone trained on SHARES lets just save some money and not develop a GUI for SHARES.

...Fastair is not a system and you can't compare its age to SHARES.but available implementations (with middleware) can be compared.
And future implementations can be discussed -- but understand they are vaporware until in place.

From all accounts, the lack of a GUI will be a short-term situation... :confused:

First it was a no-term situation (the GUI will be ready). Now it's a short-term situation (planned). Once it's done, we can draw our conclusions. But the fact that they're going without it leads me to believe they don't think it's terribly important (and having run the airline for years without it, while all of its major competitors had one, reinforces that notion).


Besides, does it really make sense to invest in developing and maintaining a tool to enable an easier transfer of revenue to your competitors?

Compliance with Star Alliance rebooking rules is important. And OALing itins to other carriers is a necessary product of being a network carrier, and frankly it's one of the advantages that retains customers because they can be assured that the airline will do what it takes to get them moving in the event of a problem with no other inline flights.


Are you privy to information that the rest of us aren't, or are you just making ASSumptions?

I'm not sure what you don't understand. The native SHARES interface is fundamentally different than the FastAir interface. We're not talking about a few different keys or a different color here. This is a radical change, and not for the better for those coming from the UA side.



If training and staffing can't address your customer service concerns, why bother having employees to begin with? Why not fire all of the front line staff and invest the dollars in developing an actual state-of-the-art system?

Systems are tools. If you don't equip your staff with tools, you lose out on additional productivity. All this happy-go-lucky talk that Uncle Jeff does about making employees happy and wanting to come to work runs counter to what is doing here, from the GA perspective.


Fastair is not a system and you can't compare its age to SHARES.

Fastair is the relevant overlay that GAs use. The loss of it will result in a significant customer service hit to legacy UA customers.


My biggest fear is that post March 3rd management will decide, Hey! we've got everyone trained on SHARES lets just save some money and not develop a GUI for SHARES.

Ding! Ding! Ding!

but available implementations (with middleware) can be compared.

True. But it is disingenuous and inflammatory for users to repeatedly post that Fastair is a younger system than SHARES.

True. But it is disingenuous and inflammatory for users to repeatedly post that Fastair is a younger system than SHARES.

the age of one system compared to another is irrelevant. What is going to matter on March 3rd - or whenever the transition takes place - is how it will impact the customer. At this point, I have no confidence that the changeover will be seamless, and I won't be flying United in March.

You can be as defensive as you want, but that is the way I see things. :)

the age of one system compared to another is irrelevant. What is going to matter on March 3rd - or whenever the transition takes place - is how it will impact the customer. At this point, I have no confidence that the changeover will be seamless, and I won't be flying United in March.

You can be as defensive as you want, but that is the way I see things. :)

+1

I don't care what systems the company uses when they generate financials or do regulatory reporting.

I worry about what's going to impact me, and to me, this is huge because it impacts the agents.

First it was a no-term situation (the GUI will be ready). Now it's a short-term situation (planned). Once it's done, we can draw our conclusions. But the fact that they're going without it leads me to believe they don't think it's terribly important (and having run the airline for years without it, while all of its major competitors had one, reinforces that notion).

So, you're automatically going to jump to the worst possible conclusion. I'm glad you're approaching the situation with an unbiased and open mind.

Compliance with Star Alliance rebooking rules is important. And OALing itins to other carriers is a necessary product of being a network carrier, and frankly it's one of the advantages that retains customers because they can be assured that the airline will do what it takes to get them moving in the event of a problem with no other inline flights.

Let's be realistic here.

I think SHARES is compliant with Star Alliance, since CO was admitted... Besides, just because it's not as easy to reissue a ticket in SHARES on another carrier doesn't mean it can't be done.

I'm not sure what you don't understand. The native SHARES interface is fundamentally different than the FastAir interface. We're not talking about a few different keys or a different color here. This is a radical change, and not for the better for those coming from the UA side.

The problem is that you're acting like this is going to destroy the airline forever. Your position lacks context and perspective.

Systems are tools. If you don't equip your staff with tools, you lose out on additional productivity. All this happy-go-lucky talk that Uncle Jeff does about making employees happy and wanting to come to work runs counter to what is doing here, from the GA perspective.

Airlines, including UA, have functioned with command line reservation systems for many decades. If employees can't provide good customer service using SHARES, management has either failed to provide adequate training or the employees have a problem with attitude/motivation.

Fastair is the relevant overlay that GAs use. The loss of it will result in a significant customer service hit to legacy UA customers.

Thank you for sharing. Again.

the age of one system compared to another is irrelevant. What is going to matter on March 3rd - or whenever the transition takes place - is how it will impact the customer. At this point, I have no confidence that the changeover will be seamless, and I won't be flying United in March.

You can be as defensive as you want, but that is the way I see things. :)

I absolutely agree that the only thing that matters is how the transition takes place. These types of transitions are difficult, regardless of what software is adopted. Perhaps other posters can stop arguing that the transition will be a failure because its not to Fastair.

I don't care what systems the company uses when they generate financials or do regulatory reporting.

I worry about what's going to impact me, and to me, this is huge because it impacts the agents.

Well, without an ability to adequately support financial and regulatory reporting UA will cease to exist and that will impact you far more than customer service at the airport counter during a transitionary period. This is the type of critical perspective you lack...

Not sure if anyone has pointed out that the current plan requires retraining the entire staff that uses the system: first the PMUA employees learn native SHARES, then the PMCO staff learn FastSHARES (not to mention the PMUA staff needing to learn the inevitable differences from Fastair). By contrast, going with the UA system would have only required training the PMCO staff.

The other problem, of course, is that by reimplementing a big system (the shell) that was built up, debugged, and improved over a number of years, we're all likely going to be living through new bugs, deficiencies, and general quirks for the next several years. One can only hope that the backend benefits to the airline will justify all the pain and that the decision was not as stupid as it might appear on the surface.

By the way, it's quite clear from the CO web site that their IT team cares much more about functionality than ease of use, but I expect to be flamed for this comment by longtime CO flyers who are already so familiar with the site that they don't recognize its problems.

I think SHARES is compliant with Star Alliance, since CO was admitted...


More than that, Shares is the "system" for Star Alliance (not to be confused with the Star Alliance Common IT Platform):

http://www.starallianceemployees.com/fileadmin/reference_guide/rg_reservations_systems.1.html

Besides, just because it's not as easy to reissue a ticket in SHARES on another carrier doesn't mean it can't be done.

oh, so now you ADMIT that its not as easy? Well, sxf, what exactly do you think employees do when something isn't easy? They will push back. They'll start working against the customer instead of with them. You can see how much easier it is for UA agents to rebook customers than CO. A OAL reissue on CO usually involves a call or two to the help desk. (CO onto CO sometimes requires that too...) but if you talk to CO agents who work alongside UA (for example at the SFO club), you'll find out that the UA agents are able to help customers much better because FASTAIR/Apollo lets them do things EASILY and QUICKLY.


ell, without an ability to adequately support financial and regulatory reporting UA will cease to exist and that will impact you far more than customer service at the airport counter during a transitionary period. This is the type of critical perspective you lack...
FASTAIR/Apollo supported a United that was as big as the current merged one. Somehow UA got by with the old system just fine for 'reporting' functions.

So, you're automatically going to jump to the worst possible conclusion. I'm glad you're approaching the situation with an unbiased and open mind.

Nobody is jumping to any conclusions. We can only see the trend, and the trend is that they do not see the GUI as critical and are already willing to trash it and go live, even "temporarily."

Anyone who was worked on major projects -- whether they be integration, development, construction, etc., knows that temporary situations are quite dangerous and can turn into long-term situations.



Let's be realistic here.

I think SHARES is compliant with Star Alliance, since CO was admitted... Besides, just because it's not as easy to reissue a ticket in SHARES on another carrier doesn't mean it can't be done.

First, thank you for admitting that SHARES is indeed more difficult at least in one aspect for a contingent of agents and customers. Recognizing these sorts of things goes a long way to bridging the community and helps dissolve the divisive nature of the "CO is best" rhetoric we constantly see being tossed around here.

That said, my point is, and has been, that the difficulty of functions will translate to a poorer customer experience when you factor in the human element. The OAL reissue process is only an example. If it's so difficult to do something, people will find ways not to do it -- whether it be alternative solutions, or worse, denials or passing the buck.



The problem is that you're acting like this is going to destroy the airline forever. Your position lacks context and perspective.

My position most certainly includes context and perspective. It is very clear that my context is w.r.t. a UA GA having to use SHARES over FastAir, and the challenges and related negative customer experience that can result.



Airlines, including UA, have functioned with command line reservation systems for many decades. If employees can't provide good customer service using SHARES, management has either failed to provide adequate training or the employees have a problem with attitude/motivation.

banks have survived for decades with typewriters and no computers, and customers survived without ATMs, online banking, or PDA banking. And homes and much larger buildings were successfully constructed without power tools. Architects drew on paper with pencils, not software; and teachers taught with chalk, not smartboards.

A front-end for agents is standard across the industry, period. CO was the lone guy out without one, and now they're dragging UA down with them to their lower common denominator as a standard.


Well, without an ability to adequately support financial and regulatory reporting UA will cease to exist and that will impact you far more than customer service at the airport counter during a transitionary period. This is the type of critical perspective you lack...

Actually this demonstrates the critical perspective that you lack.

Nobody said that they should not have the ability to report financials or do regulatory reporting. But those don't impact me directly, so I'm less concerned about them. If it takes a team in a back office 3x as long to do it, I'll never feel it. From a customer perspective, the SHARES transition is much more impacting on a day-to-day basis. It will translate into longer CS lines, more frazzled GAs, longer lines at the RCC, less cooperation from agents, etc.

The fact that you're not able to isolate these aspects and recognize that this will be a hit to a contingent of customers accustomed to a higher standard is what demonstrates your inability to understand varying perspectives.

More than that, Shares is the "system" for Star Alliance
You do realize that you can't actually book directly through *A, right? CO and US are the only airlines that use it, which says a lot.

Nobody is jumping to any conclusions. We can only see the trend, and the trend is that they do not see the GUI as critical and are already willing to trash it and go live, even "temporarily."

Anyone who was worked on major projects -- whether they be integration, development, construction, etc., knows that temporary situations are quite dangerous and can turn into long-term situations.

You're jumping to the conclusion that UA can't successfully function without Fastair and that UA will fail to adequately support and improve SHARES...

First, thank you for admitting that SHARES is indeed more difficult at least in one aspect for a contingent of agents and customers. Recognizing these sorts of things goes a long way to bridging the community and helps dissolve the divisive nature of the "CO is best" rhetoric we constantly see being tossed around here.

I hate to disappoint you, but you're only going to find "CO is best" rhetoric if you're looking for it.

That said, my point is, and has been, that the difficulty of functions will translate to a poorer customer experience when you factor in the human element. The OAL reissue process is only an example. If it's so difficult to do something, people will find ways not to do it -- whether it be alternative solutions, or worse, denials or passing the buck.

Well, my point is that you don't know or see the whole picture. You don't pick a system to cater to one need if it falls short in other areas, including functions that directly impact other aspects of the customer experience. The attempt to paint yourself as more knowledgeable about selecting a reservation system than an entire team of hundreds (if not thousands) of UA employees from both legacy carriers is absurd.

A front-end for agents is standard across the industry, period. CO was the lone guy out without one, and now they're dragging UA down with them to their lower common denominator as a standard.

CO is not the lone guy without a GUI interface, either in the airline or other industries.

Nobody said that they should not have the ability to report financials or do regulatory reporting. But those don't impact me directly, so I'm less concerned about them. If it takes a team in a back office 3x as long to do it, I'll never feel it. From a customer perspective, the SHARES transition is much more impacting on a day-to-day basis. It will translate into longer CS lines, more frazzled GAs, longer lines at the RCC, less cooperation from agents, etc.

The fact that you're not able to isolate these aspects and recognize that this will be a hit to a contingent of customers accustomed to a higher standard is what demonstrates your inability to understand varying perspectives.

The argument I hear is that UA is stupid to not select Fastair because it could detract from your customer experience during IRROPS. There has been absolutely no thought to how the selection and implementation of a reservation systems impacts other operational aspects that have much more significant influence on the customer experience.

Operating and maintaining a reservation system is one of an airline's largest single non-labor expenses. Insinuation that the selection of a post-merger system has been made flippantly and without extensive consideration for how it impacts employees and customers is absurd.

Quite frankly, engaging with you further on this topic is pointless. You've clearly approached the topic with a preconceived position and an axe to grind.

You're jumping to the conclusion that UA can't successfully function without Fastair and that UA will fail to adequately support and improve SHARES...

I never said that. UA will function, it just will be hampered in terms of service delivery at the airport level.


Well, my point is that you don't know or see the whole picture. You don't pick a system to cater to one need if it falls short in other areas, including functions that directly impact other aspects of the customer experience. The attempt to paint yourself as more knowledgeable about selecting a reservation system than an entire team of hundreds (if not thousands) of UA employees from both legacy carriers is absurd.

If what you're saying is that it's going to suck for a while until they get their GUI built, then I'd agree with you. But that's not what management is saying. They're not telling customers to beware. They're not even telling employees to beware (from my conversations with UA employees, they're being told it's better, until they get to the training, and then the reality kicks in, and there's practically nothing better in the system). In fact you're saying that they can handle it, don't worry, and airlines can work just fine with a rudimentary and primitive agent interface.


CO is not the lone guy without a GUI interface, either in the airline or other industries.

For domestic majors, I believe it is. Even US has an overlay on their SHARES.



The argument I hear is that UA is stupid to not select Fastair because it could detract from your customer experience during IRROPS. There has been absolutely no thought to how the selection and implementation of a reservation systems impacts other operational aspects that have much more significant influence on the customer experience.

Again, I'm not talking about those other operational aspects. All I'm saying is that from this perspective, there is a hit to a contingent of customers and employees, and a little bit of respect and understanding from the pro-CO contingent would be appreciated.

If you had initially acknowledging UA's IRROPS handling efficiency, FastAir's efficiency, and CO's poor IRROPS track record, we'd probably agree.

Instead, like we've seen from most CO supporters, is they're trying to find a way to defend the overall decision without acknowledging that these complex decisions have pros and cons that included pluses and minuses for various contingents.

And with this decision, a big minus is legacy UA staff and legacy UA customers who will be impacted by a more difficult-to-use system and a worse customer experience.

Hopefully management is able to overcome their usual happy-go-lucky communication style and communicate this respectfully to those UA employees impacted by this, as they'll be taking the heat from front-line customers who may not be as patient when it takes multiple times as long to get something done because management took their tools away.



Spending on operating and maintaining a reservation system is one of an airline's largest single non-labor expenses. Insinuation that the selection of a post-merger system has been made flippantly and without extensive consideration for how it impacts employees and customers is absurd.

Quite frankly, engaging with you further on this topic is pointless. You've clearly approached the topic with a preconceived position and an axe to grind.

Not at all. I said that losing the GUI will be a negative to the employee and customer experience for those accustomed to the UA side with UA staff working the UA GUI.

I think UA management recognizes this. I think you recognize this. I just think nobody at the company is willing to admit it. Maybe everyone is just preoccupied with trying to figure out the catch phrase for Jeff's next video.

I hate to disappoint you, but you're only going to find "CO is best" rhetoric if you're looking for it.

ROFL! Just fly on any of their state-of-the-art video equipped flight and you'll get an earful of $misek spouting that nonsense.

ROFL! Just fly on any of their state-of-the-art video equipped flight and you'll get an earful of $misek spouting that nonsense.

Benefit of flying on the CO 735.. No video screens :D

For domestic majors, I believe it is. Even US has an overlay on their SHARES.

Unless I missed a major piece of news, AA is still on old-fashioned command-line SABRE (they're switching to the new HP/EDS "Jetstream" eventually, but I wouldn't hold my breath (http://www.tnooz.com/2011/05/24/news/hp-downsizes-contractor-workforce-on-passenger-service-system/)).

Looks like some form of a GUI will be rolled out before the merger...

I never said that. UA will function, it just will be hampered in terms of service delivery at the airport level.
....But that's not what management is saying. They're not telling customers to beware.

...And with this decision, a big minus is legacy UA staff and legacy UA customers who will be impacted by a more difficult-to-use system and a worse customer experience.

After overhearing a conversation between a legacy UA GA and a legacy CO GA today, I am afraid channa is probably more right than wrong on this one...

Legacy CO: 'here's how you do it command command slash name command platinum etc. and now I can see who is elite on the flight.'

Legacy UA: I just press this button in the UI

Legacy UA: I had to check in a family travelling to Canada and it took me 1/2 hour in the new system to do what would have taken me 5 minutes in the old UA system. (granted, he was experienced with the old UA system and just learnign shares.)

So, my agreement with channa: This changeover is going to have a significant impact to employees and to customers. Hopefully UA is planning lots of training and extra staff available for the cutover!

Looks like some form of a GUI will be rolled out before the merger...

Maybe that will be the saving grace...

Legacy CO: 'here's how you do it command command slash name command platinum etc. and now I can see who is elite on the flight.'

Legacy UA: I just press this button in the UI

That's the crux of it unfortunately. Hope they roll the GUI out ASAP.

Messages from my UAL friend who is going through the training now:

" I advise March 3 thru end of March ...DONT TRAVEL ..
Be patient. VERY VERY PATIENT...
You have NO clue what you are in for ....... you remember summer of 2000? That's our thought"

and

" 21 yrs and I have never felt so worried for customers .... us also ........ TRYING to keep positive ..... its like going to HARVARD and then being bounced back community college"

Unfortunately I'm flying on March 7 :eek:

Messages from my UAL friend who is going through the training now:

" I advise March 3 thru end of March ...DONT TRAVEL ..
Be patient. VERY VERY PATIENT...
You have NO clue what you are in for ....... you remember summer of 2000? That's our thought"

and

" 21 yrs and I have never felt so worried for customers .... us also ........ TRYING to keep positive ..... its like going to HARVARD and then being bounced back community college"

Unfortunately I'm flying on March 7 :eek:

Did she read the update about the GUI last night? ;)

Did she read the update about the GUI last night? ;)

These were from two day ago, so I don't think that figured in. But as an IT person, I hold no faith in last minute software development. ;)

After overhearing a conversation between a legacy UA GA and a legacy CO GA today, I am afraid channa is probably more right than wrong on this one...

Legacy CO: 'here's how you do it command command slash name command platinum etc. and now I can see who is elite on the flight.'

Legacy UA: I just press this button in the UI

Legacy UA: I had to check in a family travelling to Canada and it took me 1/2 hour in the new system to do what would have taken me 5 minutes in the old UA system. (granted, he was experienced with the old UA system and just learnign shares.)

So, my agreement with channa: This changeover is going to have a significant impact to employees and to customers. Hopefully UA is planning lots of training and extra staff available for the cutover!



This is why I won't be flying when the new system is deployed UA wide. Unless something miraculous happens between now and then, it's going to be a CF.

I wonder if statistics are kept on which month would have the lowest likelihood of cancelled flights and rebookings. I would guess April would be better than March and they are probably running against some kind of deadline and March is a lighter travel month. Also probably want to get thigns stablized before Easter and the summer.

I wonder how long the outage would be for the PNRs to go over? Or, they are actually connecting the two systems in advance - all the UA PNRs (even without CO segments) get copied to Apollo as they are created/edited so they don't have to freeze Apollo to move the PNRs over?

Comparing native [line-by-line] SHARES with [line-by-line] Apollo+FastAIR is not a fair comparison. Unfortunately, that is how the decision of moving to SHARES before the GUI is ready will make employees and customers experience.

How the mainframe interfaces with PCs was an interesting topic about 15-20 years ago. The PCs literally had to "scrape the screen" to "read" and parse the output from the mainframes - and the mainframes had their own communication protocols (not TCP/IP). SHARES had a way to do it via programs in the late 90s. Not sure about Apollo.

This is how the GUI on the PC is done - it would translate the user's clicks into native line-by-line commands (or program calls), issue to the mainframe and parse the output and reformats them for better display. So, a click on the PC can mean 3-4 native commands - each has its output to be processed before the next command is issued by the PC. Without the GUI layer, the user has to do all that.

My understanding is that many these systems (SABRE, DeltaMatic, UniMatic. PARS) came from 1 source - IBM and the Semi Automated Business Research Environment (SABRE). Obviously, each was improved separately by different owners over the years. CO did add the EZR GUI to SHARES but I guess that is just for the reservation side, not the airport (ACI) side? US/HP has a GUI for their SHARES.

People can trash these mainframe systems now but people in the 50s invented them! The principles were high volume, fast transactions and low storage. I heard stories that a TPF system can reboot in 25 seconds (that is very fast for a huge mainframe) and that the transactions are fast but there are a lot of housekeeping routines cleaning things up. If there were cheaper and better systems out there, the major airlines would have migrated.

I guess we will see how things go. The last big migration into SHARES was when US moved from SABRE into HP's SHARES. I think there were some problems and I guess there were plenty of lessons learned.

Somewhere in this pile I read a statement about being lazy or not adequately motivated . . I concur.

I work at a regional station which operates both DL and UA. Hence, we operate BOTH Deltamatic and FastAir. In the past we transitioned from a split Deltamatic & Pars/Worldspan environment to Deltamatic; and, currently are training on SHARES for the transition from FastAir.

Being essentially quad lingual from all the changes and training, my reaction is quite simple . . suck it up, it's not like there is a choice; and, it is NOT that hard. Once you have learned the lingo from one system, the difference comes down to a few new characters; but, the thinking remains the same.

90% of the challenge is getting past the "my way as better" mentality and moving forward.

These were from two day ago, so I don't think that figured in. But as an IT person, I hold no faith in last minute software development. ;)

Can you clarify "last minute"? The development of the GUI interface has been going on for some time.

Frankly, it would appear that some time was lost, attempting to get "Fastair" to work with SHARES. The "Fastshares" project was stopped quite some time ago, when it was apparent that it was not an easy conversion. Fastair was built for Apollo by a now defunct company out of Boulder, CO, and was built for DOS and early Windows. That same company had developed a GUI called ASAP, which CO had used at a handful of stations, with not a lot of success. When that company folded, UA had rights to the code, and has patched it along. In the long run, it is probably a good thing that Fastair is being retired, and a true Windows based GUI is being developed.

The new GUI has been in development and testing for some time. It's a matter of getting it right before releasing it.
As UA Insider notes..the date for UA migrating to SHARES has not been set in stone. Perhaps the matruity of the GUI will play into that date.

My biggest fear is that post March 3rd management will decide, Hey! we've got everyone trained on SHARES lets just save some money and not develop a GUI for SHARES.
Well....fear not.
A) The date is not necessarily March 3rd.
B) It is deep into development already.

As UA Insider notes..the date for UA migrating to SHARES has not been set in stone.

If not cast in stone it's in rapidly hardening concrete. The contract with Travelport/Apollo expires in March. Lots of cost to extend it.

EZR is used at SFO. Only a few CO stations had this program. I love it when I use it in conjunction with Shares but they are planning on turning it off shortly. :td:

Shares has got to be the simplest program to use. True, you can not check in 5 people at a time anymore but how many times does this happen?

I hope my sUA co-workers continue to practice what they are learning and they will be fine. Every sCO person wants them to succeed and is more than willing to help/teach them the system.

If a flight you were boarding cancelled - how long would it take for you to rebook everyone on it? I'm curious.

EZR is used at SFO. Only a few CO stations had this program. I love it when I use it in conjunction with Shares but they are planning on turning it off shortly. :td:

Shares has got to be the simplest program to use. True, you can not check in 5 people at a time anymore but how many times does this happen?

I hope my sUA co-workers continue to practice what they are learning and they will be fine. Every sCO person wants them to succeed and is more than willing to help/teach them the system.
==========================================

Thank you for the encouragement. I'm not yet trained but have spoken with plenty of UA coworkers who have been trained. They have been through the training but I haven't heard anybody calling SHARES simple.

Today I checked in a family of five on FASTAIR - a very common occurrence where I work (multiples - same or different last names in one PNR). I timed it....took me less than 30 seconds really 10 seconds but then I would sound like I'm bragging. The bagtags took me less than one minute to issue and tag the bags for three out of the five passengers having a bag.

SHARES, I would be typing sentences for each passenger - first to check them in, then I have to retrieve the PNR and do individual bagtags (by typing more sentences) ? Correct me if I am wrong. Add into this mix a rainy, windy day with air traffic delays. Now it's NOT just basic cut-and-dry checkin - it's rebooking these five passengers - possibly a new connection flight if they are missing their first connection. This on a computer that does not allow for the use of tab keys - one has to use arrow keys - up, down, left, right through the PNR.

I truly believe CO employees obviously can handle irregular ops and I'm trying very hard not to form a negative opinion about SHARES but what's to be done when UA Chicago flights leaving every hour on the hour (pick any large station), are dominoing into cancellations or major delays and we barely have time to get that family of five onto the last connection of the day, offload them (or "unseat" them in CO parlance), change the bagtags, etc. Seems to me all this typing for EACH individual would slow one down, especially someone who is not a fast typist. Please enlighten me (no sarcasm intended).

If a flight you were boarding cancelled - how long would it take for you to rebook everyone on it? I'm curious.

We do have an automated program that does that and I have no idea how fast it is.

The biggest problem with rebooking anyone is personal choice and end destination. Some people take seconds to rebook and others that forever.

If I had no problems with availability and customers were only going from point A to B, I could get it done within 30 minutes if not sooner. It's a simple process of placing the flight onto a "Q" and typing N1Y1 <enter>
N=need
1= number of seats
Y= Y class
1= first line on flight available schedule

==========================================

Thank you for the encouragement. I'm not yet trained but have spoken with plenty of UA coworkers who have been trained. They have been through the training but I haven't heard anybody calling SHARES simple.

Today I checked in a family of five on FASTAIR - a very common occurrence where I work (multiples - same or different last names in one PNR). I timed it....took me less than 30 seconds really 10 seconds but then I would sound like I'm bragging. The bagtags took me less than one minute to issue and tag the bags for three out of the five passengers having a bag.

SHARES, I would be typing sentences for each passenger - first to check them in, then I have to retrieve the PNR and do individual bagtags (by typing more sentences) ? Correct me if I am wrong. Add into this mix a rainy, windy day with air traffic delays. Now it's NOT just basic cut-and-dry checkin - it's rebooking these five passengers - possibly a new connection flight if they are missing their first connection. This on a computer that does not allow for the use of tab keys - one has to use arrow keys - up, down, left, right through the PNR.

I truly believe CO employees obviously can handle irregular ops and I'm trying very hard not to form a negative opinion about SHARES but what's to be done when UA Chicago flights leaving every hour on the hour (pick any large station), are dominoing into cancellations or major delays and we barely have time to get that family of five onto the last connection of the day, offload them (or "unseat" them in CO parlance), change the bagtags, etc. Seems to me all this typing for EACH individual would slow one down, especially someone who is not a fast typist. Please enlighten me (no sarcasm intended).

Relax.....Shares really is simple. Your party of 5 would need this entry:
6:123-Smith#
B5

translation
6: = check in key
123 = flt nbr and you can have your set defaulted to a certain flt
- = name key
Smith = last name
# = more than one in the party same last name (return)
B = bag
5 = number of bags checking in (enter)

less then 5 seconds to type :)

C.A.R.S is the automated rebooking system, and it takes mere moments to rebook a cancelled or late arriving flight (missed connections). Of course, how viable the reaccom is contingent upon availability.

The difference, and advantage to CARS versus EZ Rebook is that the CSR has control of the program, rather than someone offsite, and parameters can be entered to work specific markets, and priority for elite, ssr, etc.

Those coworkers concerned about tedious manual entries; theCheckIt app info should begin to be seen soon. I took the app for a test drive, and am actually impressed.

.....


Relax.....Shares really is simple. Your party of 5 would need this entry:
6:123-Smith#
B5

translation
6: = check in key
123 = flt nbr and you can have your set defaulted to a certain flt
- = name key
Smith = last name
# = more than one in the party same last name (return)
B = bag
5 = number of bags checking in (enter)

less then 5 seconds to type :)

================================
Is this what's new in the future ?....because yesterday I asked one of my coworkers (a new "trainee" on SHARES) what the entries would be to check in a family of five, with bags. His answer was full of sentences, end + retrieve PNR, displaying sentences worth of stuff and then doing the bags - per person, just all this repititious command just to attach a bag to a passenger. This didn't sound like anything you have typed above. So, I assume this is coming in the future - any time frame ?

These past few posts have been very enlightening, thanks for sharing (no pun intended).

I think the posts do support another argument of channa: A slow agent, a lazy agent, an unexperienced agent new to Shares, or a stressed out under pressure agent (irrops) could certainly try and 'blow off' an elite who is requesting benefits / service based upon their elite status.

Yes, the elite qualifies for some benefit or extra support, but because it will take too long for the agent to execute the transaction, in some cases I could see an agent telling the customer that they cannot do it.

Relax.....Shares really is simple. Your party of 5 would need this entry:
6:123-Smith#
B5

translation
6: = check in key
123 = flt nbr and you can have your set defaulted to a certain flt
- = name key
Smith = last name
# = more than one in the party same last name (return)
B = bag
5 = number of bags checking in (enter)

less then 5 seconds to type :)

Setting to a certain flt as a default is not an option at PMUA SFO where currently there are 250 flights a day (about 16 per hour).

How do you assign which bag to which passenger. ie 5 people checking in with an infant and checking 3 bags a car seat, one person is paying cash for 1 bag and another is pay with a credit card for the other 2 bags? Currently in FastAir this is a simple check the box action on three sequential screens.

I too have been told people who have been to training that you can't check-in multiple passengers from multiple PNRs at once. A very common occurrence at PMUA SFO.

How about ticket reissue and invol refunds of through tickets (e.g. tickets where there is no fare break at the connection point) during IRROPs for multiple passenger PNRs?

Much of what is done a the check-in counter is not simple check-in/issue bag tag. 80% of Customer Service Center transactions involve re-booking/re-issue where computer systems ease of use is integral to providing good service.

SFOFastair, I'm sorry but ticketing is not something that I am good at and I can not answer your questions.

No, there is no easy Shares entry for multiple check-ins on mulitiple PNRs. You will need to check in each customer by name.

sCO makes great use of our kiosks and it is the prefered manner of check in for us.

Man, I hope the GUI helps everyone out with all this

Man, I hope the GUI helps everyone out with all this

Senior UA CS agents are now being told that it may take as long as 18 months before a GUI as robust as FastAir is developed...I was told this by three different/unrelated agents/supervisors in BOS, IAD and LAX the last two days. I fear that starting in March, it is going to be a difficult few (I hope it is only few:rolleyes:) months for PMUA employees...and especially for PMUA customers!
This is not a change I will like (and I say this with a lot of experience with PMCO reservations!)

We do have an automated program that does that and I have no idea how fast it is.

The biggest problem with rebooking anyone is personal choice and end destination. Some people take seconds to rebook and others that forever.


C.A.R.S is the automated rebooking system, and it takes mere moments to rebook a cancelled or late arriving flight (missed connections). Of course, how viable the reaccom is contingent upon availability.


One weakness of relying on these auto-rebooking programs is that in a delay situation, they tend to assume a missed connection and rebook on the next flight out of the connecting city. This works well for an airline with just a few hubs, since there usually aren't too many ways to get to the final destination.

With so many hubs in the United network (ORD, IAH, DEN, IAD, EWR, CLE, LAX, SFO), there's no sense in sending someone to IAH delayed assuming some automated system will take care of them, when the next flight out of IAH with availability may be several hours away, and there may have been alternate routes through ORD, DEN, LAX, etc. or other carriers if needed.

I'm not sure if CO's rebooking program accounts for that scenario. In my delay experiences, UA GA's usually start calling people up if they may be in trouble, because many times there's another way to get there, or delays get worse than originally planned.

SFOFastair, I'm sorry but ticketing is not something that I am good at and I can not answer your questions.

No, there is no easy Shares entry for multiple check-ins on mulitiple PNRs. You will need to check in each customer by name.

sCO makes great use of our kiosks and it is the prefered manner of check in for us.

=====================================
But when passengers have all kinds of issues and questions, you can't just direct them back to the kiosk - it is not going to "talk" to them and give multiple options and certainly not if fast-moving irregular ops are in play. I'm not sure about CO passengers but UA passengers want quick answers, quick solutions - the clock is ticking and there is only so much time to fix up a passenger onto the last connection of the day or the last other airline flight that will get them where they are going.
Yes UA's ECU's will have "robotically" rebooked passengers during irregular ops but most times it is to flights for the next day - something they don't want - they want to talk to us about what we can do NOW. Rightly so.
I'm trying to just be patient and learn all about SHARES when I go into training; -- maybe I'm dead wrong about my perception of SHARES ????

C.A.R.S is the automated rebooking system, and it takes mere moments to rebook a cancelled or late arriving flight (missed connections). Of course, how viable the reaccom is contingent upon availability.

The difference, and advantage to CARS versus EZ Rebook is that the CSR has control of the program, rather than someone offsite, and parameters can be entered to work specific markets, and priority for elite, ssr, etc.

Those coworkers concerned about tedious manual entries; theCheckIt app info should begin to be seen soon. I took the app for a test drive, and am actually impressed.
============================
But you are talking about apps on your personal hand-held device, ipad or phone ? Totally different setup for passengers checking in online at home or away from the ticket counter.
No apps have been talked about as part of SHARES or on the computer I am using on my side of the counter.

Correct me if I am wrong, but the UA iphone app is actually the CO app, that worrks pretty good with both UA apollo reservations and CO shares reservations as well as both of the checkin systems of both airlines and can display the upgrade list, those who have been cleared...

One would think that an app for the users at the airport could be developed rather quickly, to run in tandem with the native shares software for things not programmed into the gui app yet, and as they flesh out the gui app, release new versions.

Fastair when it came out in the late 90's was much less functional than today, but thru dozens and dozens of updates, it has become a workable, fully developed and stable platform.

Why wait until you have the preliminary final product, why not build a basic useable framework and work on advances. I am no app developer, so there may be good answers, but if there are, I would like to hear them, as both the iphone app and ezcheckin are able to do many of the functions with 100% automation that they are assigning us to do with less automation.

EZR is used at SFO. Only a few CO stations had this program. I love it when I use it in conjunction with Shares but they are planning on turning it off shortly. :td:

Shares has got to be the simplest program to use. True, you can not check in 5 people at a time anymore but how many times does this happen?

I hope my sUA co-workers continue to practice what they are learning and they will be fine. Every sCO person wants them to succeed and is more than willing to help/teach them the system.

This is what confused me. I talked to the CO agent in the RCC back in June and I thought she said that they had EZR on the Airport side. Then all the postings here made me thought maybe I remembered it wrong.

What is the reason for them not rolling this out to other stations? Why wouldn't they want to use it instead of developing something new?

The CheckIt App is a supplemental Shares application for employee use. It will be on your work terminal; similar to the ETKT or TKT icon currently used by s-CO.In its current state, it supports automated bag check & bag fee collections, as well as simplified TIMATIC. Point & click, the way FastAir users enjoy.

It is currently in development, and in Beta testing in IAD & TUL, with plans to roll out at other Hubs prior to Shares cut over, with additional features anticipated before March.

Employees can read about it on Skynet; there was an announcement last week.

These past few posts have been very enlightening, thanks for sharing (no pun intended).

I think the posts do support another argument of channa: A slow agent, a lazy agent, an unexperienced agent new to Shares, or a stressed out under pressure agent (irrops) could certainly try and 'blow off' an elite who is requesting benefits / service based upon their elite status.

Yes, the elite qualifies for some benefit or extra support, but because it will take too long for the agent to execute the transaction, in some cases I could see an agent telling the customer that they cannot do it.

I definitely agree with this post. Yesterday I encountered a particularly poorly-trained or lazy CO gate agent at MSP. She was not busy and I wanted to switch to exit row on my connecting flight out of IAH. Even though she had my boarding pass and elite card in hand she tried to tell me its $49 for the exit row. Then when i politely called her it she was like "why didn't you do this at the counter. I usually don't deal with this." and then she was like "you should check at the gate in Houston, they give away the seats for free to elites starting at 20 min before departure".

When I informed her that that was incorrect also, she finally decided ask her supervisor about who is eligible for exit row seating. The supervisor told her to look up the profile in SHARES and gave her the code. She read the profile and then had to ask the supervisor "Whats an ELR seat?" I was standing there with a dumbfounded look on my face. Seriously?

After this the annoyed sup just took over, pulled up my record and after many keystrokes showed the agent that there were no $ signs on the exit rows seats therefore she could assign them for free. The sup then assigned me my new seat.

How can you be a a gate agent and not know this stuff? She was not a new hire or a UA agent just learning SHARES. I have to think she was just being lazy because it was too many keystrokes.

..........When I informed her that that was incorrect also, she finally decided ask her supervisor about who is eligible for exit row seating. The supervisor told her to look up the profile in SHARES and gave her the code. She read the profile and then had to ask the supervisor "Whats an ELR seat?" I was standing there with a dumbfounded look on my face. Seriously?

After this the annoyed sup just took over, pulled up my record and after many keystrokes showed the agent that there were no $ signs on the exit rows seats therefore she could assign them for free. The sup then assigned me my new seat.

How can you be a a gate agent and not know this stuff? She was not a new hire or a UA agent just learning SHARES. I have to think she was just being lazy because it was too many keystrokes..............

===================================
Not to throw a monkey wrench into this, but NO supervisor at United is going to step in and do the job of the CSR.....unlike Continental CSRs we are a union shop and this isn't going to happen. If a UA supervisor happens to be around, they might make a suggestion "how" to do something but they are not going to actually do it hands on.
As I have stated previously and since I am not a lazy person, my goal, when I learn SHARES, is to become as knowlegeable as possible and hope to pick up some speed once I know the most important entries. Hopefully, the entirely new FastShares or FastRez or whatever it is going to be called will be up and running sooner than later but we're hearing 12-18 months away (ugh, I hope not???).
In defense of the CO CSR, E+ is fairly new to them as UA is only recently redoing E+ on CO airplanes. Sounds like she should have been up on it but probably hasn't sold the upsell to anyone yet. Nevertheless, I would venture to say that more and more lobby agents will "suggest" seat changes be done at the gate.
P.S. - Not trying to turn this particular thread into a "union vs non-union" debate....please keep it on topic, thanks.

ELR ? , At UA we call it Economy Plus - I had to think for a minute -- Extra Leg Room.
So, we not only have to learn SHARES, we are discovering that CO uses a lot of different codes and acronyms for things that we now have to learn/ adapt to. Another example is if a passenger at United is checked in but then cancels or moves to another flight, we "offload" the passenger from the original flight. CO calls it "unseat".
So, initially at least, you are going to have UA employees not familiar with CO lingo and CO employees not familiar with UA lingo. The concepts are the same but the "language" is different. I'm seeing a lot of "confused" looks in the future.

So, initially at least, you are going to have UA employees not familiar with CO lingo and CO employees not familiar with UA lingo. The concepts are the same but the "language" is different. I'm seeing a lot of "confused" looks in the future.


In addition to the lingo, there may be consequences to the procedural differences if not correctly followed.

For example, when UA reroutes you, they typically offload you and book you on new flights (your old flights are still there, and it doesn't matter since UA won't delete downline segments if you no-show one you changed off of).

On CO, the minute you no-show a segment, the rest of the itin is cancelled.

So I can see if a legacy UA agent out of habit follows the legacy UA procedure, it could create a mess in the customer's PNR if they have a return or other segments in there.

btw, I did witness some cross-training going on at SFO the other day. They had one (1) UA agent with the three (3) CO agents running a CO flight. The UA agents was asking a bunch of questions and had a hand-written cheat-sheet of commands, but at least they're giving some practical, hands-on training.

[QUOTE=channa;17515488]''''''''''''''''In addition to the lingo, there may be consequences to the procedural differences if not correctly followed.

For example, when UA reroutes you, they typically offload you and book you on new flights (your old flights are still there, and it doesn't matter since UA won't delete downline segments if you no-show one you changed off of).

On CO, the minute you no-show a segment, the rest of the itin is cancelled.

So I can see if a legacy UA agent out of habit follows the legacy UA procedure, it could create a mess in the customer's PNR if they have a return or other segments in there''''''''''''''

================================================== ===
I'm already starting to see this happen with 005 issued tix.....(i.e., UA segment to Chicago and CO segment connecting from ORD; downline segment and return segments cancelled if first UA segment was not used). However, I have not necessarily seen this in every case.
Right now at UAL we can call a particular desk to reinstate downline segment(s) cancelled robotically. They're usually able to do it 99 percent of the time. Will UA keep this phone number ? I don't know what CO's procedure is - Do they try to rebook or reinstate the original downline segments or do they just book whatever is still available?....I can see I've got to write down a lot of questions before I go into training.

================================================== ===
I'm already starting to see this happen with 005 issued tix.....(i.e., UA segment to Chicago and CO segment connecting from ORD; downline segment and return segments cancelled if first UA segment was not used). However, I have not necessarily seen this in every case.
Right now at UAL we can call a particular desk to reinstate downline segment(s) cancelled robotically. They're usually able to do it 99 percent of the time. Will UA keep this phone number ? I don't know what CO's procedure is - Do they try to rebook or reinstate the original downline segments or do they just book whatever is still available?....I can see I've got to write down a lot of questions before I go into training.

If everyone is as diligent as you, we'll be in good hands...

[QUOTE=channa;17515488]''''''''''''''''In addition to the lingo, there may be consequences to the procedural differences if not correctly followed.

For example, when UA reroutes you, they typically offload you and book you on new flights (your old flights are still there, and it doesn't matter since UA won't delete downline segments if you no-show one you changed off of).

On CO, the minute you no-show a segment, the rest of the itin is cancelled.

So I can see if a legacy UA agent out of habit follows the legacy UA procedure, it could create a mess in the customer's PNR if they have a return or other segments in there''''''''''''''

================================================== ===
I'm already starting to see this happen with 005 issued tix.....(i.e., UA segment to Chicago and CO segment connecting from ORD; downline segment and return segments cancelled if first UA segment was not used). However, I have not necessarily seen this in every case.
Right now at UAL we can call a particular desk to reinstate downline segment(s) cancelled robotically. They're usually able to do it 99 percent of the time. Will UA keep this phone number ? I don't know what CO's procedure is - Do they try to rebook or reinstate the original downline segments or do they just book whatever is still available?....I can see I've got to write down a lot of questions before I go into training.

I asked a CO employee friend of mine. In SHARES you do not have to call a support desk if the segments are still available to to sell. You just re sell them in the reservation. If they're not available, then a support desk has to be called to oversell the flight. He says it's a pretty simple and I've watched him work on my reservation before. There seems to be some typing involved but he's pretty quick.

Yesterday I encountered a particularly poorly-trained or lazy CO gate agent at MSP. She was not busy and I wanted to switch to exit row on my connecting flight out of IAH.

When I informed her that that was incorrect also, she finally decided ask her supervisor about who is eligible for exit row seating. The supervisor told her to look up the profile in SHARES and gave her the code. She read the profile and then had to ask the supervisor "Whats an ELR seat?" I was standing there with a dumbfounded look on my face. Seriously?

After this the annoyed sup just took over, pulled up my record and after many keystrokes showed the agent that there were no $ signs on the exit rows seats therefore she could assign them for free. The sup then assigned me my new seat.

How can you be a a gate agent and not know this stuff? She was not a new hire or a UA agent just learning SHARES. I have to think she was just being lazy because it was too many keystrokes.


Unfortunately dls25's experience seems to happen all too often, an agent or other employee who doesn't seem to have the knowledge/interest in doing their job correctly. A CO agent should know what ELR seats are for certain, and I have also encountered this similar look of confusion in the past. (I believe the poster was speaking with a CO agent about a CO flight, as was I.) However all airlines and most companies have this type of of employee.

But that is the most important issue with the cutover to SHARES, is it not? That with the many workers who have not bothered to learn their pre-merger carrier's systems and rules, many of which have been in place for years, how suddenly is it to be expected that they be able to apply the low-level programming required by SHARES in such a short amount of time?

I think that we will be surprised. In my work experience I have seen what happens when things are communicated effectively, and in advance, and that people will surprise you in the way they rise to this type of challenge. I do not have travel plans in the first week of March, but I wouldn't shy away from something that came up.

After 2 days of SHARES training here is my take so far.

FastAir is something like Windows XP (stable, fairly integrated, many of the rough edges have been smoothed out)

Native Apollo is something like using the Command processor in Windows XP.

SHARES is like using DOS 5 (a circa 1991 OS ) in 2011. It works but boy is it ugly. Lots of stuff appears that shouldn't and lots of stuff that should be there isn't. The display screens tend to be cluttered and very user unfriendly. It appears that during application the development process once a process worked all further refinement stopped.

One big SHARES short fall is lack of history. We asked the question and so fare have been told the is no way in SHARES to view the history of changes/entries to PNRs or check-in entries. So it seems that when seats or segments change or disappear we won't be able to understand why or how it happened and explain it to you the customer.

Selling things like E+/ELR takes about 10 entries moving up and down through each of half a dozen different screens.

Where in Apollo everything (ticketing, services, check-in etc.) is integrated SHARES consists of series of modules that are loosely tied together. There a ticketing module, a fee module, a seat module, a special services module and so on. Each module requires multiple steps before it can send its output back to a PNR or check-in entry.

I can say without any reservation I and my 23 classmates are committed to making it work but at this early stage in training the feeling is come March we won't be able to provide the same level of service due the fact that the tools available won't up to the task at hand. If the the kiosk or OLCI didn't work allow at least 5 times the amount of time you are used to when an agent has to fix something (at least for the 1st couple of months).

Love the OS analogies! Yes, we all anticipate it is going to be bad - just hope they don't delay or flake on the promise to develop FastSHARES.

After 2 days of SHARES training here is my take so far.

Thank you for posting your insights. This sounds like it will be a rude awakening for many of the UA GAs accustomed to better systems.


FastAir is something like Windows XP (stable, fairly integrated, many of the rough edges have been smoothed out)

Native Apollo is something like using the Command processor in Windows XP.

SHARES is like using DOS 5 (a circa 1991 OS ) in 2011. It works but boy is it ugly.

The UA GA I talked to the other day said it was like going back to the 1800's and using a typewriter. So you're being much more generous in comparison. ;)


One big SHARES short fall is lack of history. We asked the question and so fare have been told the is no way in SHARES to view the history of changes/entries to PNRs or check-in entries. So it seems that when seats or segments change or disappear we won't be able to understand why or how it happened and explain it to you the customer.

That's a bummer. Do you know if the history is kept, it's just a matter of the GA not being able to see it? Or is the history on things like seat changes not even stored?

I have used the history a handful of times to figure out what happened in a situation. I wonder if this lack of history (or lack of available history) is a reason why CO seems to be more prone to shenanigans in things like upgrades -- because they know it would be difficult to uncover what happened.


Selling things like E+/ELR takes about 10 entries moving up and down through each of half a dozen different screens.

Interesting. You would think that they would make upselling easy on agents.


I can say without any reservation I and my 23 classmates are committed to making it work but at this early stage in training the feeling is come March we won't be able to provide the same level of service due the fact that the tools available won't up to the task at hand. If the the kiosk or OLCI didn't work allow at least 5 times the amount of time you are used to when an agent has to fix something (at least for the 1st couple of months).

I'm going to say not just the first few months, but indefinitely. The reality of the situation is that there are humans involved, and cumbersome systems and overly complex processes will lead to degraded service. Someone who many in a borderline situation (e.g., should we rebook him or not, there's a chance he'll make it), instead of just doing it, when faced with the level of effort required to do it, some co-workers (maybe not you), will find a way to get rid of the customer rather than to help.

March will represent a loss of customer service for legacy United flyers that will not be restored until CO can return equivalent system functionality to its agents.

Do you know if the history is kept, it's just a matter of the GA not being able to see it? Or is the history on things like seat changes not even stored?

The history is definitely kept. I've seen mine before. EVERYTHING is in there.

*H while in the PNR does not give you the history?

The history is definitely kept. I've seen mine before. EVERYTHING is in there.

I hope you are correct. I asked the question last night of the trainer about being able to display history and was told it was not possible. Maybe they didn't understand my question.


*H returned nothing. Could be an artifact of using a training SHARES environment.

I hope you are correct. I asked the question last night of the trainer about being able to display history and was told it was not possible. Maybe they didn't understand my question.


*H returned nothing. Could be an artifact of using a training SHARES environment.

That may be. Don't know if history is tracked in the test/training environments. In the production environment the history is indeed available.

This sounds like a nightmare...and I will need to travel that week - either the 4th or the 5th :(

All of this begs the question: If the PMUA system is so much easier to use than SHARES, why the change?

Is SHARES cheaper or something?

All of this begs the question: If the PMUA system is so much easier to use than SHARES, why the change?

Is SHARES cheaper or something?

It's legacy CO...and with everything else that is legacy CO and worse than legacy UA from a customer perspective...it's not _that much_ worse, so stop complaining about taking a step backwards. :rolleyes:

This sounds like a nightmare...and I will need to travel that week - either the 4th or the 5th :(

All of this begs the question: If the PMUA system is so much easier to use than SHARES, why the change?

Is SHARES cheaper or something?

Start at the beginning of this thread. Lots of discussion why it was chosen.
And...It's NOT a change for the CO folks ;)

After 2 days of SHARES training here is my take so far.

FastAir is something like Windows XP (stable, fairly integrated, many of the rough edges have been smoothed out)

Native Apollo is something like using the Command processor in Windows XP.

SHARES is like using DOS 5 (a circa 1991 OS ) in 2011. It works but boy is it ugly. Lots of stuff appears that shouldn't and lots of stuff that should be there isn't. The display screens tend to be cluttered and very user unfriendly. It appears that during application the development process once a process worked all further refinement stopped.

One big SHARES short fall is lack of history. We asked the question and so fare have been told the is no way in SHARES to view the history of changes/entries to PNRs or check-in entries. So it seems that when seats or segments change or disappear we won't be able to understand why or how it happened and explain it to you the customer.

Selling things like E+/ELR takes about 10 entries moving up and down through each of half a dozen different screens.

Where in Apollo everything (ticketing, services, check-in etc.) is integrated SHARES consists of series of modules that are loosely tied together. There a ticketing module, a fee module, a seat module, a special services module and so on. Each module requires multiple steps before it can send its output back to a PNR or check-in entry.

I can say without any reservation I and my 23 classmates are committed to making it work but at this early stage in training the feeling is come March we won't be able to provide the same level of service due the fact that the tools available won't up to the task at hand. If the the kiosk or OLCI didn't work allow at least 5 times the amount of time you are used to when an agent has to fix something (at least for the 1st couple of months).
================
Oh God, please don't tell me that - no history ??....

Could it really be that CO does not get the same questions that we get from UA passengers ?? How can I give informed answers to passengers if I can't research the PNR ? Basic things like when they made the original reservation and date ticketed, etc. All of this is very important if a passenger is in dispute with us about fares, rules, errors, etc. Really, from what I've heard, other UA agents....quote ...."THE KIOSK IS YOUR BEST FRIEND"....but as I've said in the past, the kiosk doesn't talk, it can't answer questions like "what happened to my seat assignment?"; "when did the equipment change from an A320 to an A319", etc, etc.
All of what you are saying about multiple screens and scrolling is exactly what we're hearing from those already through the training and on OJT at CO ticket counters. If the kiosk doesn't "answer questions", they are on the phone with their help desk or reservations to fix the problem ???. It would be an understatement to say this would be extremely cumbersome and time-consuming in a very fast-paced time frame on a rainy, windy day with multiple delays, cancellations and misconnects. I'm used to trouble-shooting and solving as quick as possible, not picking up a phone for someone else to do my job from a remote location while I stand there looking dumbfounded and at a loss for words while the line is building up by the minute ??. This would be a major handicap to say the least. Even having 1 or 2 other agents on the ticket counter or at a gate getting involved with one problem would be "messy", a circus-like environment. Right now, I refuse to stress and let the chips fall where they may and, like you, committed to finding a way to make it work for me.

...........
The UA GA I talked to the other day said it was like going back to the 1800's and using a typewriter. So you're being much more generous in comparison. ;).......

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
One agent said it was like handing in the keys to her Mercedes and given the keys to a Ford Pinto.!

If the kiosk doesn't "answer questions", they are on the phone with their help desk or reservations to fix the problem ???.

Funny you say that, the other day when the kiosk did not add me to the upgrade list for my CO flights (award ticket and PPMC cardholder, so entitled to upgrades), after verifying with the PDA site (because CO does not use DM cards), I went to the CO agent who quickly tossed back my BP saying that award tix don't get upgrades (btw, you'll learn that too -- always try to get rid of the customer quickly).

Then, when I explained I'm a PPMC cardholder, she wanted to see the card, started typing, then picked up the phone (it was almost like instinct). I told her I had the profile if she wanted it, and she said no, then she found what she wanted (I think) and put down the phone. After about five (5) minutes of intense typing, I got my BPs back and verified on the PDA that I was added to the upgrade lists.


It would be an understatement to say this would be extremely cumbersome and time-consuming in a very fast-paced time frame on a rainy, windy day with multiple delays, cancellations and misconnects. I'm used to trouble-shooting and solving as quick as possible, not picking up a phone for someone else to do my job from a remote location while I stand there looking dumbfounded and at a loss for words while the line is building up by the minute ??. This would be a major handicap to say the least.

It's only a major handicap if you do it. If you can successfully blow off the customer without having to pick up the phone, it may be just as fast as FastAir. Have a backed up line and a customer who wants to get rebooked on AA? You know that'll take 15 minutes, so just tell them AA is full, and the best you can do is what the computer reprotected them on (tomorrow).

What if he asks for hotel? Say it was weather and we don't pay for hotels in weather delays.

btw, both of these are right out of CO's playbook. ;) I've experienced OAL denials when OAL carriers have space, and denied hotels due to weather when the delay may not have been weather, and I'm at a status level that gets hotels irrespective of cause.

I can post some of my CO IRROPS debacles, but the pushback received was simply unbelievable from a UA perspective (e.g., being quoted a change fee after a diversion and having to hold my own Full Y reservation because the Elite desk wouldn't rebook something after 7 phone calls despite a diversion).

A few of those types of IRROPS debacles and seeing how they treat the customer as a hot potato was one of the main reasons I left CO in the first place. Flying UA was a lot less stressful because although I had more IRROPS on UA than on CO, I knew that UA would do whatever they could to get me where I'm going. I'm afraid that level of UA service is something that simply cannot be delivered on such shoddy systems -- at least until they get a reasonable FastAir replacement.



One agent said it was like handing in the keys to her Mercedes and given the keys to a Ford Pinto.!

LOL

It's funny, but I never quite realized how good PMUA had gotten until this thread reminded me of the old days. For many years it was just the normal routine that if you needed any significant change to a ticket or reservation, you'd just stand there politely for 10 or 15 minutes while the agent furiously pecked away at the keyboard.

I rarely minded the delay for my own transaction because it seemed like the more typing, the better the outcome. I just hated waiting in line for someone else's transaction to be completed. This, of course, led to my strong interest in using every possible alternative tool, from cell phone calls to online access to kiosks, just to avoid the agent.

I've barely noticed that on rare occasions that I have needed an agent in recent years, the transaction's been pretty fast. Even though we're likely returning to the old days for maybe the next couple of years, my guess is that with all the other options and my own experience with proactive itinerary management, a 1K member like me will rarely have a serious problem. On the other hand, I expect to see a lot more long lines of befuddled and unhappy casual flyers, including many who haven't even mastered the kiosks.

I feel sorry for the agents, especially the ones who most care about helping the customers.

I was in ORD last week and had booked the CO flight to SFO. Lots of rain delays so plenty of people trying to get onto the flight. I had a simple request and nothing better to do, so I stood in the very long line. It didn't move for ten minutes, with two agents working the counter (and on the phone almost the entire time). I think in the half hour i waited in line maybe three or four people were taken care of (in a line of 15-20). I gave up when they started boarding. But this thread makes a lot more sense to me now about why the line was soooooo slow. Not looking good post-March 3.

What I don't understand is why the CO folks don't want fastair? Why do the CO folks want this inferior level of service (and how the heck did this level of service ever get a reputation as good?). I spoke with a senior person in the RCC in SFO and she confirms much of what is written her about what they are being told. "Just call" appears to be the mantra of the shares training. At one point there was a statement that there was already a faster front end that existed (not fastshares) but something that reservation uses - that would be brought down the line - however the line knows NOTHING about this. Where does this stand?

What I don't understand is why the CO folks don't want fastair? Why do the CO folks want this inferior level of service (and how the heck did this level of service ever get a reputation as good?). I spoke with a senior person in the RCC in SFO and she confirms much of what is written her about what they are being told. "Just call" appears to be the mantra of the shares training. At one point there was a statement that there was already a faster front end that existed (not fastshares) but something that reservation uses - that would be brought down the line - however the line knows NOTHING about this. Where does this stand?

No one (CO employees or otherwise) has said they don't want Fastair. After UA conducted what was almost certainly an extensive process to determine what reservation system they should use going forward, SHARES was selected. Some folks have accepted the change (reluctantly or whole heartedly), while others are trying to fight it.

What I don't understand is why the CO folks don't want fastair? Why do the CO folks want this inferior level of service (and how the heck did this level of service ever get a reputation as good?). I spoke with a senior person in the RCC in SFO and she confirms much of what is written her about what they are being told. "Just call" appears to be the mantra of the shares training. At one point there was a statement that there was already a faster front end that existed (not fastshares) but something that reservation uses - that would be brought down the line - however the line knows NOTHING about this. Where does this stand?
===========================
Your guess is as good as ours (UA CSRs) although I don't know of any UAL CSR who didn't ask the obvious question - "why don't CO employees just learn Fastair". (They would actually like it). For the most part CO agents don't see SHARES as "inferior" - Why would they ?...they have nothing to compare it to. All I know is that the trainers keep talking about a "new", "faster" system down the line but this seems to be in the time-frame of 12-18 months away. Why would they be teaching us SHARES now if this new thing is close. This tells me it's probably not close. Well, whatever, we'll have to learn it and try to like it, I guess.

What I don't understand is why the CO folks don't want fastair?

I think CO does want FastAir -- they even spent significant effort trying to port it to work on SHARES before dropping that project.

What the UA merger did was essentially force the issue. CO never bothered to build a robust front end for their airport staff, and when CO saw what UA was doing with FastAir, they realized they want it or something like it.

While the current plan is to build a front end, my fear of course is that once they get everyone trained on SHARES, CO will revert back to their old ways and not pursue building a robust front end.


Why do the CO folks want this inferior level of service (and how the heck did this level of service ever get a reputation as good?).


CO throws a lot of people at airport level functions (e.g., ticket counters and CS centers seem to be better staffed on CO than on UA), and I think that resonates well with leisure travellers who like having easy access to people.

An extra touch that CO does is that they meet the flight with a redcoat with a list of connections who can point you in the right direction or explain the airport layout. That must resonate well with leisure travellers who are unfamiliar with IAH or first-time flyers who don't know the drill. For many of us, it doesn't do much -- we know our gate when we pull up (off the PDA), we've been to IAH dozens of times, and we know our way around.

I think it's this sort of window dressing that gets CO the awards and reputation for good CS. Though what many of us as frequent flyers are interested in is how they handle IRROPS, how quickly and well they respond to post-flight concerns, whether our loyalty and status means anything, etc. -- areas that CO has historically struggled with.


At one point there was a statement that there was already a faster front end that existed (not fastshares) but something that reservation uses - that would be brought down the line - however the line knows NOTHING about this. Where does this stand?

There is a front-end that reservations uses (they can reissue tickets pretty quickly). While airport agents rebook and reissue as well, that's only a small fraction of what they do. So I think they'd have to build something totally different for them.

Some folks have accepted the change (reluctantly or whole heartedly), while others are trying to fight it.

Who is trying to fight it? It's the decision that has been made, like it or not.

What we should do is recognize that this decision has resulted in eroded functionality and/or a more difficult interface for a large contingent of users (every legacy UA airport agent around the globe), and as a result there is likely to be a degradation in customer service for legacy UA customers accustomed to a higher level of service due to an easier-to-use agent interface.

In addition, we should recognize that there will likely be a morale hit for those who airport staff who had to transition from FastAir to SHARES, as the interface is weaker. If work took away my nice, fast computer and replaced it with something older, I wouldn't be happy. I'd still get my job done, but I wouldn't be as happy about it, it's just human nature.

And given that, are there any strategies as customers to deal with these obstacles? What do we do if we need to get rebooked? Should we call instead of talking to the club reps? Should we make our own reservations and ask the airport to print our tickets to paper? This is the kind of stuff that I would like to know.


For the most part CO agents don't see SHARES as "inferior" - Why would they ?...they have nothing to compare it to.

Not only that, but there is often a predisposition amongst legacy CO staff that CO does things better.

The real people to ask are the CO staff who were put in the RCCs. I've talked to a few, and they didn't just like FastAir, they were drooling over the system and couldn't believe how much easier it was.


All I know is that the trainers keep talking about a "new", "faster" system down the line but this seems to be in the time-frame of 12-18 months away. Why would they be teaching us SHARES now if this new thing is close. This tells me it's probably not close. Well, whatever, we'll have to learn it and try to like it, I guess.


Well you know how development works -- things push, things get scrapped, who knows. They say 12-18 months now, maybe it'll be less, maybe it'll be more, maybe they'll run into some roadblocks or overruns and scrap the project.

At least you're ahead of the game, as at least you worked for an airline that knows how to provide tools for its front-line agents, so you have a better understanding of what's possible should the company choose to provide it.

[QUOTE=channa;17550858]I............While the current plan is to build a front end, my fear of course is that once they get everyone trained on SHARES, CO will revert back to their old ways and not pursue building a robust front end.....An extra touch that CO does is that they meet the flight with a redcoat with a list of connections who can point you in the right direction or explain the airport layout. That must resonate well with leisure travellers .......

I think it's this sort of window dressing that gets CO the awards and reputation for good CS. Though what many of us as frequent flyers are interested in is how they handle IRROPS, how quickly and well they respond to post-flight concerns, whether our loyalty and status means anything, etc. -- areas that CO has historically struggled with....

=================================
You're right on all points, in my opinion. I'm not so sure they'll dump pursuit of a new front-end system versus the current SHARES. I (we) should all hope that they will pay attention to passengers responses and even more so, their employees as this turnover moves along and the plug is ultimately pulled on Fastair in March 2012.

CO throws a lot of people at airport level functions (e.g., ticket counters and CS centers seem to be better staffed on CO than on UA)

Possibly because SHARES is SO user unfriendly it takes more people to coax information out of SHARES in order to assist customers


An extra touch that CO does is that they meet the flight with a redcoat with a list of connections who can point you in the right direction or explain the airport layout. That must resonate well with leisure travellers who are unfamiliar with IAH or first-time flyers who don't know the drill.

Just a quick comment.

It is PMUA SOP for the GA meeting a flight to remain at the gate until everyone has left the plane. So a GA is available to answer connection/gate location/direction type questions.

To all PMUA centric FTs memorise this number 800.523.FARE (CO res #). You'll need it when the kiosk doesn't work and all you've got is a SHARES newbe agent.

It is PMUA SOP for the GA meeting a flight to remain at the gate until everyone has left the plane. So a GA is available to answer connection/gate location/direction type questions.

Indeed. Though UA's agent is usually at the podium, so you have to find them (or they're working the next flight). CO's agent is standing in the hallway, wearing a red blazer, holding a printout and saying, "Connections?" And IIRC, the red coat is usually in addition to the agent meeting the flight/driving the jet bridge. It's really just throwing people at a non-critical fucntion.

Indeed. Though UA's agent is usually at the podium, so you have to find them (or they're working the next flight). CO's agent is standing in the hallway, wearing a red blazer, holding a printout and saying, "Connections?" And IIRC, the red coat is usually in addition to the agent meeting the flight/driving the jet bridge. It's really just throwing people at a non-critical fucntion.

Don't really know if it's the GA or another agent, but on arrival I've often seen PMUA agents standing with a connection list at hubs on large equipment and/or delayed flight arrival. Maybe it's the conspicuous red blazer that makes people think there's something special at CO?

"Can you protect me on that back-up flight?"

As a 1k, I have learned that these should be just about the first words out of my mouth when things begin to go crosswise. I have found that the answer is almost always "yes", and the option this creates has saved me many times.

Under the new SHARES regime, is it going to be a lot harder for agents to create protection without canceling the original reservation?

"Can you protect me on that back-up flight?"

As a 1k, I have learned that these should be just about the first words out of my mouth when things begin to go crosswise. I have found that the answer is almost always "yes", and the option this creates has saved me many times.

Under the new SHARES regime, is it going to be a lot harder for agents to create protection without canceling the original reservation?

I've been backed up in the EWR UC many times, never had an issue.

Indeed. Though UA's agent is usually at the podium, so you have to find them (or they're working the next flight). CO's agent is standing in the hallway, wearing a red blazer, holding a printout and saying, "Connections?" And IIRC, the red coat is usually in addition to the agent meeting the flight/driving the jet bridge. It's really just throwing people at a non-critical fucntion.

I've never seen this person in all my passes through IAH

I've never seen this person in all my passes through IAH

I saw him when I got off my flight from DCA a few weeks ago. He gave me incorrect gate information, and had I not checked a board, I would have missed my connecting flight.

One big SHARES short fall is lack of history. We asked the question and so fare have been told the is no way in SHARES to view the history of changes/entries to PNRs or check-in entries. So it seems that when seats or segments change or disappear we won't be able to understand why or how it happened and explain it to you the customer.


You were told wrong. I looked at a history today. While there is no way to sort it (like request only "air history",) it looks similar to ours (not sure if it is in inverse chronological order or chronological order.)
Check your handy dandy shares flip book, it is in there, as well as etkt history, which I also utilized today (well watched as a supe was looking at it, as I have not had my indoctrination yet.)

I saw him when I got off my flight from DCA a few weeks ago. He gave me incorrect gate information, and had I not checked a board, I would have missed my connecting flight.

Which is way they announce on board to "Check the flight monitors, as your gate assignment may have changed. ;)

(The red coat is likey using a sheet that may be a few hours old) IAH used to have monitors over the arrivals path near the concourse for each gate. They would set them to the in house page that would show the city code vs. spelling out the city and it could display many more fights. The red coats could look at that, which was live data. I would suspect somewhere down that line that some carriers will start equipping the "roving supervisors" or red coat type agents with iPads, and have acess to the live FIDS data (as well as host access) All it takes is time and money.

I talked to ten CSRs, including 3 Service Directors, today. Out of all 10, none of them had anything good to say about their SHARES training.

We talked about March 3, and the "Summer of Hell" was referenced several times. :eek:

Which is way they announce on board to "Check the flight monitors, as your gate assignment may have changed. ;)

(The red coat is likey using a sheet that may be a few hours old)

When the FA on board gives you gate information, I can understand why it might be old information. For a red coat to have information that is "a few hours old" is simply laziness. If the red coat isn't going to take the time to get an updated list before meeting an incoming flight, why even bother?