Go Back  FlyerTalk Forums > Miles&Points > Airlines and Mileage Programs > United Airlines | MileagePlus
Reload this Page >

Is United quoting wrong reasons for delay? How is the reason determined?

Is United quoting wrong reasons for delay? How is the reason determined?

Old Sep 21, 2014, 11:14 am
  #91  
FlyerTalk Evangelist
 
Join Date: Apr 2008
Location: LGA/JFK/EWR
Programs: UA 1K1.75MM, Hyatt Globalist, abandoned Marriott LTT (RIP SPG), Hertz PC
Posts: 21,180
Surprised they didn't just change it to the more common "due to severe weather conditions in our network"

Looks like they switched the AC on you though...interesting.
UA-NYC is offline  
Old Sep 21, 2014, 11:25 am
  #92  
 
Join Date: Nov 2013
Location: NYC / TYO / Up in the Air
Programs: UA GS 1.7MM, AA 2.1MM, EK, BA, SQ, CX, Marriot LT, Accor P
Posts: 6,720
Originally Posted by UA-NYC
Surprised they didn't just change it to the more common "due to severe weather conditions in our network"

Looks like they switched the AC on you though...interesting.
Yes they did - as the original one had a defective engine lol! The flight crew walked off the plane and apologized to us in person - the captain actually got on the PA and explained what happened - that they were looking for a new plane for them to use and were hopeful it would be soon - then because it wasn't "soon" the orignial crew timed out and had to find a new crew to fly us to ROC - my point for posting is that the final reason "posted" for the delay can't be relied upon to be accurate - and in fact in this case it's a bold faced lie. It's sad when you can't rely on anything but yourself these days with travel on UA...
bmwe92fan is online now  
Old Sep 21, 2014, 11:33 am
  #93  
 
Join Date: May 2001
Location: Portland, OR, USA
Programs: UA 1K 3 Million/ex-many year GS, AA PLT/2 Mil, AS MVPG, HH Dia, Starwood Life Plat, Hertz PC
Posts: 1,401
What is interesting and this demonstrates is that there are 2 separate needs from the "reason" that UA doesn't separate. As you are waiting the screenshots you show are actually the more useful reasons since they provide information within the current context for the further delay. I.e., once the MX happened and they decided to find a plane it was of more value to someone awaiting the departure to give that as the reason. Likewise, once the plane was there someone waiting at that point would be better informed that now the crew was the problem. So contextually these reasons are helpful. However, for purposes of things like compensation and IRROPS handling the actual initial cause is what is relevant and important and should not be lost. E.g., you are awaiting departure and have a MX. As you wait for an hour for that to be fixed a storm moves in and closes down the airport. Ultimately to get to a connection point. As you was waiting to depart, once the plane is fixed it is useful to tell the passengers that the reason you are waiting longer is weather. However, when you are stranded at the connection point later the real reason you are stuck isn't the weather, it is the MX and that is what should show and govern IRROPs handling.
pdx1M is offline  
Old Sep 21, 2014, 11:53 am
  #94  
 
Join Date: Nov 2013
Location: NYC / TYO / Up in the Air
Programs: UA GS 1.7MM, AA 2.1MM, EK, BA, SQ, CX, Marriot LT, Accor P
Posts: 6,720
Originally Posted by pdx1M
What is interesting and this demonstrates is that there are 2 separate needs from the "reason" that UA doesn't separate. As you are waiting the screenshots you show are actually the more useful reasons since they provide information within the current context for the further delay. I.e., once the MX happened and they decided to find a plane it was of more value to someone awaiting the departure to give that as the reason. Likewise, once the plane was there someone waiting at that point would be better informed that now the crew was the problem. So contextually these reasons are helpful. However, for purposes of things like compensation and IRROPS handling the actual initial cause is what is relevant and important and should not be lost. E.g., you are awaiting departure and have a MX. As you wait for an hour for that to be fixed a storm moves in and closes down the airport. Ultimately to get to a connection point. As you was waiting to depart, once the plane is fixed it is useful to tell the passengers that the reason you are waiting longer is weather. However, when you are stranded at the connection point later the real reason you are stuck isn't the weather, it is the MX and that is what should show and govern IRROPs handling.
Exactly - and this is the reason why I have "turned" on UA - for the general flying public they will be abused by this type of reporting while UA claims it's "some other reason" that isn't the real one. I would hope that examples such as this would be "exceptions" - but the truth is I have too much experience to know this isn't true... I have great respect for UA Insider, but the continued absence of proper handling of events such as this really sours me on UA in general - and I am supposed to be the best of the best to UA....
bmwe92fan is online now  
Old Sep 21, 2014, 12:48 pm
  #95  
A FlyerTalk Posting Legend
 
Join Date: Apr 2013
Location: PHX
Programs: AS 75K; UA 1MM; Hyatt Globalist; Marriott LTP; Hilton Diamond (Aspire)
Posts: 57,177
Originally Posted by bmwe92fan
I have great respect for UA Insider, but the continued absence of proper handling of events such as this really sours me on UA in general - and I am supposed to be the best of the best to UA....
People aren't stupid, esp not GS. This experience is being repeated across the country on a daily basis as people follow the rolling delays on the App (or, as in my case, via the delay notification emails UA sent). It's going to hurt UA.
Kacee is online now  
Old Sep 21, 2014, 1:36 pm
  #96  
 
Join Date: Nov 1999
Location: Tucson, AZ USA
Programs: AA Exec Plat / DL-Silver / Hyatt - Glob / Hilton-Gold
Posts: 1,577
Originally Posted by bmwe92fan
Just so everyone knows - the orignal reason for the delay was a bad engine on the original plane - what get's recorded officially is crew availability....
No
Speaking from my past life in AA OPS at DFW (and I can't imagine it's much different at other airlines), what you're seeing is not the "coding" of the delay. It's the reason for the latest ETD update.

Each time the station updates the ETD, they have to report the reason the departure time is being extended. More than anything, it's to keep the flight's Dispatcher advised on how things are progressing. So yes, a flight that has had its ETD bumped a few times for repairs but is now being delayed an additional 20 minutes for reason "x" will not have the ETD bumped again for "mechanical". The Dispatcher most likely knew the repair had been accomplished (or whatever) so would be very concerned if the station bumped another 20 minutes for "mechanical".

The latest "reason" is what will show on FLIFO and any process reading from FLIFO. Internally, there are historical FLIFO entries, but I don't think the "public" displays generally go into that much detail.

As for coding the delay, it has nothing to do with the reason for the final ETD bump. In Sabre FOS (so not UA), the delay coding is a separate entry from the "status update" entry. The delay isn't coded until after the flight leaves, sometimes quite awhile after as we research the precise reason(s). The entire delay can be split into multiple codes, the code with the highest number of delay minutes determines the department that's "charged" with the delay. Again, I think the delay coding is internal and not generally displayed to the public.
steve64 is offline  
Old Sep 21, 2014, 1:57 pm
  #97  
 
Join Date: May 2005
Programs: Million Miler, 1K - Basically spend a lot of time on planes
Posts: 2,202
Originally Posted by steve64
No
Speaking from my past life in AA OPS at DFW (and I can't imagine it's much different at other airlines), what you're seeing is not the "coding" of the delay. It's the reason for the latest ETD update.

Each time the station updates the ETD, they have to report the reason the departure time is being extended. More than anything, it's to keep the flight's Dispatcher advised on how things are progressing. So yes, a flight that has had its ETD bumped a few times for repairs but is now being delayed an additional 20 minutes for reason "x" will not have the ETD bumped again for "mechanical". The Dispatcher most likely knew the repair had been accomplished (or whatever) so would be very concerned if the station bumped another 20 minutes for "mechanical".

The latest "reason" is what will show on FLIFO and any process reading from FLIFO. Internally, there are historical FLIFO entries, but I don't think the "public" displays generally go into that much detail.

As for coding the delay, it has nothing to do with the reason for the final ETD bump. In Sabre FOS (so not UA), the delay coding is a separate entry from the "status update" entry. The delay isn't coded until after the flight leaves, sometimes quite awhile after as we research the precise reason(s). The entire delay can be split into multiple codes, the code with the highest number of delay minutes determines the department that's "charged" with the delay. Again, I think the delay coding is internal and not generally displayed to the public.
I wish that to be true, but I have sat there (and seen many others) arguing for protection on flights (whether it be hotels, refunds, vouchers etc) and have the agent refuse (with an attitude no less) that because of the delay reason, United Airlines are not responsible. Now you can fight it for weeks, and may get somewhere, but it doesn't help you on the day, and rarely ends up getting you a fair deal.
CO_Nonrev_elite is offline  
Old Sep 21, 2014, 3:32 pm
  #98  
 
Join Date: Nov 1999
Location: Tucson, AZ USA
Programs: AA Exec Plat / DL-Silver / Hyatt - Glob / Hilton-Gold
Posts: 1,577
Originally Posted by CO_Nonrev_elite
I wish that to be true, but I have sat there (and seen many others) arguing for protection on flights (whether it be hotels, refunds, vouchers etc) and have the agent refuse (with an attitude no less) that because of the delay reason, United Airlines are not responsible. Now you can fight it for weeks, and may get somewhere, but it doesn't help you on the day, and rarely ends up getting you a fair deal.
I agree with what you're saying, but how Agents handle things is another topic.
I suspect Agents are making the same assumption as most folks here ... that the reason for the last ETD update was the reason for the delay. That assumption is not true.

I did a stint as a Gate Agent before going to OPS. At that time I didn't even know there was a delay coding system.
If I were handling you as a "mis-connect" and needed to know the reason for your delay, I'd do a FLIFO on your inbound flight and would only see the last ETD bump saying "WX" (weather).
The FLIFO entry isn't too hard: 2<flt#>. So if you came in on flt 989, the entry is 2989 (that's Sabre, but I've seen other airline's keyboards and they usually have the "2" key labelled as FLIFO).
The instant you challenged me or suggested the delay wasn't WX, I'd have to do the historical FLIFO entry and this is MUCH harder: 2H989.
The display isn't the easiest on the eyes, but a quick scan and I'll see an ETD with a reason of MECH or something similar. That's all I need to know, you're right and my 1st check was wrong.

Oh course I worked in the industry many years ago. The Agents industry wide were more trusted to "do the right thing" on a case-by-case basis. The environment today is much different and IMHO, UA is by far the worst at not trusting their Agents. Many things that Agents used to be able to do are now blocked by the computer (again, IMHO, not a known fact).

My first reply wasn't about Agent handling is IRROPS. It was about Flyer Talkers saying UA is lying about the "coding" of the delay when what they're really reading is the reason for the last ETD change ... 2 completely different things.
steve64 is offline  
Old Sep 21, 2014, 3:41 pm
  #99  
 
Join Date: Feb 2009
Location: SFO
Programs: UA GS
Posts: 288
Originally Posted by steve64

My first reply wasn't about Agent handling is IRROPS. It was about Flyer Talkers saying UA is lying about the "coding" of the delay when what they're really reading is the reason for the last ETD change ... 2 completely different things.
How about my case on the TPE-SFO flight where there was nothing weather related and we were delayed because of cargo mis-loading (post on the pevious page of this thread)? How can UA claim the delay was caused by severe weather?
ryder1650 is offline  
Old Sep 21, 2014, 4:00 pm
  #100  
 
Join Date: Jun 2004
Location: What I write is my opinion alone..don't read into it anything not written.
Posts: 9,689
Originally Posted by ryder1650
How about my case on the TPE-SFO flight where there was nothing weather related and we were delayed because of cargo mis-loading (post on the pevious page of this thread)? How can UA claim the delay was caused by severe weather?
A last minute increase in fuel load/useage for new routing on a flight that had already had the load planned is one possible explanation.
fastair is offline  
Old Sep 21, 2014, 4:46 pm
  #101  
 
Join Date: Nov 1999
Location: Tucson, AZ USA
Programs: AA Exec Plat / DL-Silver / Hyatt - Glob / Hilton-Gold
Posts: 1,577
Originally Posted by ryder1650
How about my case on the TPE-SFO flight where there was nothing weather related and we were delayed because of cargo mis-loading (post on the pevious page of this thread)? How can UA claim the delay was caused by severe weather?
Again, I'm not talking about UA handles passengers in delays.
My original reply was to post #90 and folks responding who all thought that description of the last update meant the airline was trying to hide the nature of the delay. The display's we're using don't tell the whole story, they're not supposed to.

I've no idea what could've happened on your flight. I do know that "weather" includes "winds aloft". Weather could be anywhere along your flight path, or your path could've been seriously altered around weather. Start adding "contingency" fuel for holding/re-routes/diversions/etc and the original "load plan" on the flight goes out the window.

Something else has me thinking about these public displays where folks are seeing irrelevant looking delay reasons. This theory goes back to coding the delay, not adjusting the ETD/ETA.
On Sabre, we didn't have to worry about any "upline delay" as the system would code these automatically. Ever acft type has a "ground objective time", the number of minutes a station has to get the flight in and out. If a plane comes into our station late, we only have to code for the number of minutes where we went beyond the ground objective. So if the plane came in 3 hours late due to mechanical, we had 35 minutes to turn the flight out but took 41, then we have to code 6 minutes of the delay. It would be something simple like the code for "boarding passengers". Internally, the majority of the delay would be for mechanical, but I could imagine these public displays simply pulling the station specific portion of the delay and not trying to analyze the big picture.

I do laugh at all the delays for "airport conditions preventing departure of the aircraft".
At AA, the hubs used to have a 5 minute grace. Say a 4 minute delay, we'd still have to code it, but as a station we wouldn't be charged for it. So we had a generic delay code 98 which was "official hub close out". My guess is "airport conditions preventing departure of the aircraft" is nothing more than UA's version of the 98 code. Or maybe just a standard default msg on the web app when there's too many codes to display .. or a new code added in the mainframe that the App doesn't recognize yet.

While I've no doubt that UA cheats some, you have too look at it from another perspective. The ETD/ETA updates and delay coding were in place in the airline's computers LONG before any of that info was available to the public. The internet and now mobile devices have changed all that. People carry a computer with them all the time now so they want info. So the web app now queries the mainframe and extracts limited data. The data wasn't designed for your smartphone, it was designed for the Ops system. You're only getting a small piece.

I now work as a computer programmer in the credit card industry. I work on the "credit approval" computer where we log every time you swipe your card. That's been on the mainframe for years. Now the web/app folks want to display this info to the customer. Ok, here's how you query the database and heres the data layout. Now we get problem tickets saying the customer sees a charge at the gas station for $75 when they only pumped $10. The $75 is correct because that's the approval. If you want the app to show the final transaction amount then you need to query the billing platform as they're the ones who get the (electronic) "charge slip" from the vendor. So the App folks make that change and now we have problem tickets because the customer no longer sees the purchase they made 30 seconds ago
From the customer's view, we're all a bunch of idiots. The approval amount is real-time, the final amount is batch. That's how it's been for years and we're not changing the whole system just for the smartphones.
I do honestly believe (even tho I myself don't trust UA) that many of the "lies" we see on the UA App is the same concept of scraping limited amount of data off the mainframe and the customer thinking what they see on their phone is the full/final info.
steve64 is offline  
Old Sep 21, 2014, 5:01 pm
  #102  
A FlyerTalk Posting Legend
 
Join Date: Apr 2013
Location: PHX
Programs: AS 75K; UA 1MM; Hyatt Globalist; Marriott LTP; Hilton Diamond (Aspire)
Posts: 57,177
Originally Posted by steve64
My first reply wasn't about Agent handling is IRROPS. It was about Flyer Talkers saying UA is lying about the "coding" of the delay when what they're really reading is the reason for the last ETD change ... 2 completely different things.
That's simply wrong.

In the delay I recently reported (Here - and see in particular quoted e-mails from UA), while there may have been a brief initial delay due to late inbound the last reason was mx; when the mx was resolved, we pulled away from the gate. Yet the final excuse ("delayed inbound") was only offered by UA at the very end, and it was not the reason for the final delay.
Kacee is online now  
Old Sep 21, 2014, 5:17 pm
  #103  
FlyerTalk Evangelist
 
Join Date: Jul 2003
Location: BOS, PVG
Programs: United Global Services and 1MM, Marriott Ambassador
Posts: 10,002
Originally Posted by Kacee
That's simply wrong.

In the delay I recently reported (Here - and see in particular quoted e-mails from UA), while there may have been a brief initial delay due to late inbound the last reason was mx; when the mx was resolved, we pulled away from the gate. Yet the final excuse ("delayed inbound") was only offered by UA at the very end, and it was not the reason for the final delay.
My question:

Should UA deny hotel voucher and compensation to stranded passengers using the excuse such as "late inbound aircraft" or "weather" when the initial cause was MX?
kb1992 is offline  
Old Sep 21, 2014, 6:38 pm
  #104  
 
Join Date: Nov 1999
Location: Tucson, AZ USA
Programs: AA Exec Plat / DL-Silver / Hyatt - Glob / Hilton-Gold
Posts: 1,577
Originally Posted by Kacee
Yet the final excuse ("delayed inbound") was only offered by UA at the very end, and it was not the reason for the final delay.
And that is exactly what I'm trying to say.
The "reason" listed on the last ETD update does NOT define the reason for the delay.
I assume the smartphone data, like the basic FLIFO entry, simply lists the most recent update. It doesn't try to analyze and determine the definitive reason.

I agree that the reason for the 2nd ETD update doesn't make sense.
But (without knowing the sked departure time) I'm assuming an Agent in SFO handling mis-connects off your flight could see that more time was due to mechanical than the 20 minutes for the questionable "late inbound plane". That would make the "delay reason" the mechanical problem. The smartphone or basic FLIFO only showing the last "reason" is irrelevant as it's not the whole picture.

Are we alleging that the only info an Agent has is similar to that shown on a smartphone ... that only the last ETD update reason is shown ?
That would really surprise me, but I don't know.
fastair ?? Any UA Agents out there that can tell us how you decide how to handle mis-connects ??
steve64 is offline  
Old Sep 21, 2014, 11:00 pm
  #105  
 
Join Date: Nov 2013
Location: NYC / TYO / Up in the Air
Programs: UA GS 1.7MM, AA 2.1MM, EK, BA, SQ, CX, Marriot LT, Accor P
Posts: 6,720
Originally Posted by Kacee
People aren't stupid, esp not GS. This experience is being repeated across the country on a daily basis as people follow the rolling delays on the App (or, as in my case, via the delay notification emails UA sent). It's going to hurt UA.
I agree - and for the other comments in this thread - I have personally witnessed and personally been a victim of this "final reason" for delay - I can't explain it but for some reason the agents at the airport don't seem to be able to see the real reason for delay - and use the last reason.

I watched his happen at ORD last month when a plane went mx and flight was delayed several hours and then weather rolled in and flight ultimately cancels. Weather was listed as the reason and no one was given hotel or food vouchers - bc weather was the reason.... This isn't right - IMO - but it does happen and i think regularly! A few weeks ago I posted my experience at EWR where the flight crew left the plane for a break to go eat dinner - and we departed about 25 minutes late. The flight was marked delayed due to "airport conditions impacting out operations" or something and after push back - 25 minutes late - the flight status was changed to departed on time heading to runway!

What a joke - and this why I take screen shots for each change in delay reason - only way I can protect myself!

Last edited by bmwe92fan; Sep 21, 2014 at 11:07 pm
bmwe92fan is online now  

Thread Tools
Search this Thread

Contact Us - Manage Preferences Archive - Advertising - Cookie Policy - Privacy Statement - Terms of Service -

This site is owned, operated, and maintained by MH Sub I, LLC dba Internet Brands. Copyright © 2024 MH Sub I, LLC dba Internet Brands. All rights reserved. Designated trademarks are the property of their respective owners.