halls120

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?

Dr_Adventure

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.

Sulley

Actually, just to clarify for everyone:

SHARES is not owned by the company.

HP owns it, EDS hosts the system.

Also:

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.

TWAB747nomore

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

fastair

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.)

Cbmaz

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.

GSP flyer

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.

joel67

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

HeathrowGuy

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.

Eastbay1K

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.

halls120

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

joel67

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.

MSPGabe

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.

UAL awesome

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.

fastair

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.