Time for some mostly baseless speculation, just for fun.

There is a question here that I don't know the answer to but you or others might: does AC's revenue management system adjust availability in real time?

I know from conversations with a couple of airline execs (non-ac) from some years ago that their systems used to run on a timed update basis. There would be a once daily (I think one was twice daily) update where their algorithm would run and push availability updates to all distribution systems - any regular priority manual flags would also be queued and processed during the same update (there were also override flags that would ignore rev management and do certain things in real time). At the time, the only normal occurrence that would push in real time was sales (ie reducing seats in a bucket when someone bought one). Computers have come a way since then so it is possible that more modern systems do run in full real-time.

Speculating: when an upgrade clears at R0, one of three things is occuring:

1. There is a hidden bucket that has availability and clears the upgrade OR
2. The R capacity portion of the revenue algorithm runs and decides there should be more R space and adds it which causes a waitlist upgrade to clear OR
3. A seperate part of the revenue algorithm runs and decides that this particular ticket should be upgraded and does so

My supposition would be that there is a combination of things going on. Having a single, simple hidden bucket seems unlikely from some of the behaviour we have observed where dollar value or revenue vs award variables seem to matter differently. That isn't to say that there isn't a hidden bucket that can sell an upgrade in very specific circumstances when a combination of variables declare a certain ticket as high value.

The distinction between 2 and 3 is more interesting to me. I would lean against thinking that 2 is happening very often because if the main hidden mechanism to clear R0 upgrades is simply to increment R space, I would expect that the cross section of tickets that get upgraded in this scenario would be more random. If R is simply being added, I don't see how they would direct that R space to clear a specific ticket when multiple eligible tickets may be waitlisted (or at least it would force the hidden criteria to be the same as what we know of the waitlist order).

My bet would be on the majority of these upgrades clearing via mechanism 3. This would allow the system to take into account a pretty diverse set of variables that makes a decision on a per ticket basis. I would also guess that this would not be running truly in real time because it would be pretty expensive to constantly check every waitlisted upgrade against all live data updates at short intervals to see if it should clear. It would be much more efficient in my mind to run this procedure for a certain set of triggers (ie segment placed on eup waitlist, clearance window opens, nightly (or whenever) full availability update etc).

Continuing to make things up, this might even explain a couple of things we have seen in the wild. The difference between instant clear when waitlisting or after a few minutes could simply be dependent on system load where sometimes it's a short queue and will run right away and sometimes there's a compute constraint. The issues with the website being inconsistent with displaying space could be explained if they don't want to run this procedure all the time because of its complexity and a much simpler (ie cheaper) procedure runs to guestimate whether eup space is available.

Really, I'm just making things up but it's probably as plausible as anything else I've seen. Sometimes random musings are fun. If anyone knows better with more accuracy, feel free to correct me.