ermintrude

F19 showing available (from 20) remained until ~ T-30. Flight was fairly recently - EWR to PHX. Something similar occurred on another UA domestic flight that I was on not that long ago but I forget where.
All fare buckets were 9 from at least 7 days out until at least T-2.
For those that don't know, if R is above around 4 the CPU system should be processing upgrades at least within 24 hr intervals and T-24 more frequently.
Not sure if this intentional (in an effort to sell F close in)? .......to see it once I'd blow it off as a glitch but twice IME is strange.

Interested to hear if others have seen an uptick in this anomaly recently.

mahasamatman

That is a conjecture I've seen before, but with zero actual evidence. Maybe this will put that theory to bed once and for all.

boat9781

Without starting a feud, one of the good things that SHARES does vs. other PSS systems.. as a big company what would you do? The dynamic waitlist PMUA had, akin to DELTAMATIC, it worked great. I think it's a lessons learned to companies. If you're sharp and smart enough to leverage the platform, that becomes an asset, you win. What's most sad, is, mismanagement runs deep in the United management. Smisek had a great platform, but he blew it.

Anyway, what happened here is either the CPU system didn't run -- by design -- or there was an out of sync reservation that stopped the processor. This flight was R9 PN9, everything 9. Either a system failure or a conscious decision to cut off the CPUs

Asking the experts, look at EWR PHX, R9 PN9, zero upgrades.

Halo117

It was intentional and happening more frequently, but i think selectively based on route, day of week etc. But what irks me is how draconian it is....TOD are back with a vengeance. Recent example IAH-SJD. I was #1 on list 0 upgrades at t-24 with J9 R9 I9 showing and app saying 0 booked. Some buyups occurred as around t-4 showed 6 booked then agent cleared the list at the gate. 17 of 20 seats taken at departure with a few nonrevs as well.

Kacee

I agree that it is happening with frequency and also believe it to be intentional.

exerda

The worst part is that there are *always* out of sync reservations which break processing CPUs. Heck, mine showed out of sync this morning--no idea why--so I'm sure anyone waiting on a CPU on my flight weren't thrilled. Of course, I, waiting with a GPU, was also not thrilled.

boat9781

Is it still the case that out of sync reservations break the CPU system?

I know that SHARES runs these processes as a separate bolt on outside of the PSS, but I'd hope UA has fixed some of the issues that plagued their bolt on systems in the past. Perhaps I'm too kind, but I can't imagine shutting off the CPU system is the right call from a business perspective. This just may be more mismanagement and ineptitude. I'd love to be proven wrong.

boat9781

It is not conjecture. I know from people on the sCO side that if R is >2 the EUA "Elite Upgrade Automation" system is designed to run and clear pending upgrade requests. That was awhile ago and maybe the threshold changed. But that is how the system was designed.

exerda

I believe it is still the case. Last time I cleared a CPU, actually, my res was out of sync, and I got the GA to clean it up. Bingo! I then cleared CPU, as did my wife and 2 other people. GA even said something about it at the time (stuff getting "stuck" due to out-of-sync tickets).

I have had similar experiences when calling in to get a ticket resynced... the next time the CPU process ran, I cleared, but hadn't at the prior windows/times run. That's a lot more anecdotal than the experience clearing the upgrade at the gate when the GA fixed the ticket, though.

RobOnLI

With all the anecdotal evidence of CPU stopping with an out-of-sync reservation, people should actually be happy about that. The system is designed to not skip over the out-of-sync reservation and upgrade the next-in-line. It stops and waits. Until that out-of-sync reservation is fixed CPU won't run. This preserves the integrity of the upgrade process. It also means a lot of upgrades don't happen until the gate because the reservation doesn't get fixed until someone realizes they can't check-in or until they go to the airport to check-in and the agent fixes the reservation. That 'unsticks' the CPU process and people are processed normally again.

-RM

boat9781

I tend to agree. But when there is evidence this is happening repeatedly, we have to ask, is it a business decision versus an anomaly? I know for a fact that this case is an instance that occurred two or three times before. Same route, 753 then now a 739. Same circumstances.

higher_flyer

What is an out-of-sync reservation, and how does it happen?

boat9781

An out of sync reservation means the ticket (your form of payment) doesn’t match the reservation. SHARES handled out of sync reservations differently than Apollo and other systems. Some PSS systems defer reconciliation of the ticket and reservation until check in. Shares needs constant alignment with reservation (PNR) and the ticket. In some ways that’s good because it ensures everything is aligned. But it adds issues when the outside systems can’t act accordingly.

The United CPU system hits a hiccup when the ticket and reservation are out of sync. That’s the problem presently, and we are just asking if it is indeed a hiccup or a business decision to cancel the upgrade processor on select flights.

fumje

Could this be related to the delayed CPU emails? Those do not say 'Elite Upgrade Notification' any longer ('Elite' became 'Premier'). So perhaps the CPU system is being overhauled?

Gabdawg

This happened to me on a recent CUN to DEN flight. T-24 it was booked 3 of 20. When I checked in on the app it offered $89 for upgrade. I decided to wait it out for a CPU. As the T-24 started running down it was booked 12 of 20. I didn't clear at check in. I did clear at time of boarding by gate agent. The gal sitting next to me and many of her friends got the same email and all bought up for $89. 5 of them I believe. She said most of them had no status with UA.