It happens but it's unusual. Normally my tickets issue and send confirm emails within 5 minutes of purchase.

it usually takes me 15-20 mins.

don't know why, it seems ridiculous. DL and UA do it instantly.

Any delay in ticketing is because of credit card verification.

what?

they can verify the credit card instantly.
CO authorizes credit cards when you go through the whole annoying process of adding it to your profile (UA you can just enter it in as you purchase).
then they authorize your card when you buy it and again (for the full amount) when they ticket it.

I'm only repeating what I was told.

Understood. But I don't think what you were told is correct. Electronic verification should never take minutes, just seconds. Some other "housekeeping" must be going on. Still, I don't see why waiting minutes is such an issue.

RNE, asking out of curiosity, "Has anyone ever waited minutes and not had the transaction approved? Me thinks not."

It's certainly better to wait than have the UA site bomb out while attempting to purchase a ticket. Which I've had happen before .

Incorrect. It's probably capacity on CO's side more than anything. Charge authorizations take fractions of seconds with the right infrastrucutre.


Well of course CO has to have an external reason to blame for its inefficiency. After all, if the culture does not allow for the COmpany to be inferior even in the slightest regard, they have to explain it off somehow.

Not sure why they can't just say it's something they're looking into, but they don't have it yet. It's not like people would stop flying them over it.

UA, DL, and AS all do instant ticketing. It just makes for a cleaner transaction. I particularly like it when doing phone bookings or changes. The agents get it setup and it's done before the call ends. Any hiccup (e.g., credit card issue), and they hang on the line and work through it.

To be sure, CO has similar capabilities for ticketing as other legacies. CO agents can and do "instant ticket" most bookings -- the only time delays come into play are: 1) for some interline bookings where agents have to manually build the pricing record (less of a problem now as CO has worked to incorporate most if not all Star member carriers into its automated pricing and ticketing IT infrastructure); 2) for some interline bookings where CO does not have an instant availability arrangement with the other airline, requiring a 24-hour delay in ticketing (it's cleaner to wait and ticket rather than ticket immediately and risk cancelled segments) and 3) payment verification issues.

The bigger I've had is not in ticketing, but in SHARES communication with other airline reservations systems. As I mentioned a few months back, I had a huge cluster.... with a OnePass award booking on SQ because SHARES simply stopped communication with Kriscom - thus, I had a ticket, but no reservation on SQ. An SQ agent at SIN had to force-book me in Y onto SIN-IAH, but the needful got done after much hassle and an expensive call back to Houston.

CO.com doesn't even instant ticket most itineraries.

If you were to go to co.com and buy a flight, and in a separate window go to united.com and buy the same flight (UAL coded), chances are you'll have the UA ticket much faster than the CO ticket, simply because UA will instantly ticket it within the purchase transaction, while CO will queue it.


That's a separate, and bigger issue, and it may not be even SHARES related. US, for example, uses SHARES and does not seem to have as many of these issues, so I'm thinking there's something in the way CO has it setup.

I remember going to a presentation years ago on SHARES and "what happens when an Eticket is issued" (this was in the early days of eTickets for CO). They were saying that SHARES did not do pricing and it used Amadeus. I remember them saying that there were quite a few transactions back and forth between the two systems. I think they said Amadeus was in Germany - not that it would have slowed things down that much. Not sure if this is still the case though.

The ticketing delay is highly unlikely to be a "can't do it" as in "why isn't it fixed?". Rather it's likely to be a "we don't see the need to spend to do it". Probably going into some messaging queue or file/database table used as a semi-persistent, recoverable message store. Then the queue gets processed by the ticketing software engine, which is likely a mostly homegrown (or outsourced but designed for CO's SHARES instance) system. Can you say "CICS MAXTASK" or "QUIESCE"?

With more CPU, storage, and IO channel capacity, I'm sure CO could issue tickets nearly instantly. However I'm guessing that Gordon, Larry, and now Jeff never saw it as worth the spend. Obviously UA back in the day did.

We may be seeing the opposite of the DL/NW IT integration. DL wanted to keep NW's much better (other than aesthetics) website, but needed to keep their legacy DL backend (Deltamatic) due to the lower cost, deep integration into all the airline's operations, and capacity that was already scaled for a much bigger airline than NW's PARS. It then became too spendy and time-consuming to design/code all new connections from the NW website to Deltamatic, so the NW website was dumped. The NW FF system was kept, because it had more capability and functionality, but the operational systems stayed mostly all-Delta. They at least made an attempt at "best of both" in terms of IT integration, with cost and time-to-market being the prime criterion for what they decided. And it was the ex-NW DL CIO who made the call to go with the DL IT.

Here it sounds like UCH IT and executive management decided to keep the CO website (which BTW is NOT most of what IT people mean when they talk about the "Airline's computer system") because it's better than united.bomb, and keep the CO back-end also. Probably because CO folks know it, and Jeff & Co like it. Basically like what they did with the logo.

Unfortunately, other than the messed up UA website (or shall I say websites, with all the different domains involved with resultant different timeouts & cross-domain single-signon issues), the UA computer SYSTEM is widely considered much better for running an airline.

This is probably partially CO "pride/ignorance", partially cold cost evaluations, and possibly as other have mentioned, just an interim step before the Star unified IT platform is delivered.

I am not sure about the CO web site, but many sites do a CC verification transaction as part of the process to make sure the card is good and that the charge will not exceed your limit. That is an interactive transaction with the CC company that takes place in a second or 2.

The ending of the transaction executes the ticketing process and has several components including CC charge, ticket issuance (which could be with an e-ticket database that exists somewhere else), as well as confirmation of all segments with the operating carrier. So if the itinerary has codeshare segments, this part of the transaction could take a little time as well, since the codeshare partner creates a PNR in their system and sends a record locator back to CO.

Not sure where o heard this, but at one time, I heard Apollo uses (4) processors, while shares uses (1). Now maybe that one processes faster, or more per cycle, but 4 is better than 1 in most cases

I would bet that the system resides on a big enterprise server cluster on some sort, so I doubt this is the main issue.