Keeping up-to-speed with how United’s reservation system processes Complimentary Premier Upgrades (CPUs) can be a daunting task. The vast majority of my flying on United Airlines this year came before the system conversion to SHARES on March 3. And all of my United flights since that date have been upgraded through other means – Regional Premier Upgrades (RPUs), Global Premier Upgrades (GPUs) and Y/B/M-auto upgrades based on my fare.

As such, I haven’t spent much time reading the forums about many of the upgrade issues being widely reported, particularly CPUs. Matthew and his readers clearly spell out one of the issues, and as a result, I’ve been schooled in what once was a smooth process pre-merger on United being boggled down by both the system and agents.

The short version of Matthew’s experience is that one of his upgrades failed to clear at the designated window, though upgrade space (R-inventory) was still showing plenty of space. Turns out that one of the problems was due to his ticket having married segments – something so ultimately common in fare construction for the past 20 years (if not more) that I couldn’t believe hearing SHARES couldn’t handle it.

That, combined with his ticket being out-of-sync, caused the whole CPU process to fail out, impacting him and everyone else further down in the queue. One of his readers commented that he’s experienced this issue first-hand a couple of times. Once the ticket was fixed (often not until check-in), the process ran and upgrades were processed. If not fixed expeditiously, the likelihood of other passengers scoring “tens of dollars” upgrades for low-ball amounts may have trumped many elites getting their CPUs.

The other nugget of information I gleaned from Matthew’s posts and reader comments is that many agents are unwilling to manually process upgrades if R>0, in part because they don’t know which reservation is holding up the process. If Matthew’s reservation, for example, was in sync and he called to get the upgrade manually processed, it might have trumped someone’s higher priority upgrade.

And it was also revealed in the comments that the sweeps SHARES takes to process upgrades aren’t nearly as dynamic as the former Apollo. They appear to only happen at designated intervals (T-96 hours, T-72 hours, etc.), not in real-time. Also, just because R>0 at some point within the CPU window, it doesn’t mean all the space will be used for CPUs.

This may be common experience for many, but this was the first I was reading about it. Matthew’s reader, Dan, has some other fascinating insights that sound completely legit and are worth a read if you, too, are hearing about this for the first time.

I guess I’ll get my first-hand experience with CPUs this fall as my RPUs and GPUs have now all been used. But if I see R>0 within my upgrade window, I’ll definitely be calling to try to grab that space. I already obsessively call multiple times to ensure my tickets are in sync as it is.