![]() |
Originally Posted by ancman
(Post 4005970)
You appear to not understand how the process works.
When scheduling runs WS/OOBWS/GS coverage, it begins with a 12-minute ARCOS offer window. During that time, everyone with auto-accept on automatically accepts the trip, and those without auto-accept on can manually accept. This initial 12-minute window has never been an issue. This is what you’re proposing to eliminate. The true issue (for the company) is that after that step, each pilot who has accepted the trip now receives an individual 12-minute award window. If 50 pilots have auto-accept on, then the second step takes 10 hours. If 100 pilots have auto-accept on, it takes 20 hours. In a category with 100 auto-accepts, the step you’re proposing to eliminate currently occupies 1% of the time required for coverage (12 minutes out of 1,212 minutes). The other 99% of coverage time (1,200 minutes) is spent on the second step, the award window phase. Under your proposal, that step would actually take more time, as now every pilot has auto-accept on rather than only some. There is no shortage of possible solutions. The real magic is determining the price Delta pays for implementing it. I'd like it heavily weighted toward soft pay. Vacation, paid APD, etc... |
So, do away with offer window, have a single 12 minute award window and award window batches as to disturb the least amount of pilots?
https://jeremydmiller.com/wp-content...4/09/image.png |
Originally Posted by Ar Pilot
(Post 4005976)
So, do away with offer window, have a single 12 minute award window and award window batches as to disturb the least amount of pilots?
https://jeremydmiller.com/wp-content...4/09/image.png |
Just to add some data to the debate, I took upon myself the laborious task of auditing some 23M7 logs in iCrew. It would be SOOO much simpler if these logs were in a traditional (i.e. Excel) format, but here we are. Manual data entry.
ATL320B was my choice as it's the largest category and is spread across all bases (except BOS of course.) The intent, and result of my audit was to determine just how much 23M7 (aka trip coverage being stopped/skipped) resulted in out-of-base pilots getting paid. Indirectly, but probably directly, this indicates how often OOBWS is guilty of "jamming" up coverage, other factors notwithstanding (CS being staffed properly, doing their job, etc.) I audited all 41 pages of ATL320B 23M7 logs in iCrew for January 2026. Results: 446 23M7 entries 294 were for ATL320B (WS) 152 were for 320B in other bases (OOBWS) So, 66% for WS, 34% for OOBWS Or, simpler terms, 2/3 were for WS, 1/3 were for OOBWS. Honestly this was a higher % of OOBWS than I was expecting. That being said, I'm still not convinced that OOBWS are "the problem." |
Originally Posted by Verdell
(Post 4005995)
Just to add some data to the debate, I took upon myself the laborious task of auditing some 23M7 logs in iCrew. It would be SOOO much simpler if these logs were in a traditional (i.e. Excel) format, but here we are. Manual data entry.
ATL320B was my choice as it's the largest category and is spread across all bases (except BOS of course.) The intent, and result of my audit was to determine just how much 23M7 (aka trip coverage being stopped/skipped) resulted in out-of-base pilots getting paid. Indirectly, but probably directly, this indicates how often OOBWS is guilty of "jamming" up coverage, other factors notwithstanding (CS being staffed properly, doing their job, etc.) I audited all 41 pages of ATL320B in iCrew for January 2026. Results: 446 23M7 entries 294 were for ATL320B (WS) 152 were for 320B in other bases (OOBWS) So, 66% for WS, 34% for OOBWS Or, simpler terms, 2/3 were for WS, 1/3 were for OOBWS. Honestly this was a higher % of OOBWS than I was expecting. That being said, I'm still not convinced that OOBWS are "the problem." |
How about we bring batch sizes back? If they use a reasonably sized batch size (call it 5), they have no penalty. Also, AA works for proper batch sizes. If they're desperate, they can bypass AA, and go Auto-Ack only, but every batch that exceeds that by some threshold (5 pilots) will pay X-hours per pilot in the batch. 10-pilot batch, 1-hour per pilot. 15-pilot batch, 2-hours per pilot. 20-pilot batch, 3-hours per pilot.
Thus, if you get woken up by a 2 am call with a 30-pilot batch, you'll at least be paid 5 hours. Increasing batch sizes scales the penalty. People will get woken up, but at least you'll be paid if you're not likely to get the trip. Would that work? |
Originally Posted by ohaiyo
(Post 4006015)
How about we bring batch sizes back? If they use a reasonably sized batch size (call it 5), they have no penalty. Also, AA works for proper batch sizes. If they're desperate, they can bypass AA, and go Auto-Ack only, but every batch that exceeds that by some threshold (5 pilots) will pay X-hours per pilot in the batch. 10-pilot batch, 1-hour per pilot. 15-pilot batch, 2-hours per pilot. 20-pilot batch, 3-hours per pilot.
Thus, if you get woken up by a 2 am call with a 30-pilot batch, you'll at least be paid 5 hours. Increasing batch sizes scales the penalty. People will get woken up, but at least you'll be paid if you're not likely to get the trip. Would that work? example: company declares an irop and ps commuting, id be open to selling aa and batch size up to 10 for a 24-hour window in exchange for adg during that same time. Stack that onto a gs and I might volunteer to fly during the irop |
Originally Posted by ohaiyo
(Post 4006015)
How about we bring batch sizes back? If they use a reasonably sized batch size (call it 5), they have no penalty. Also, AA works for proper batch sizes. If they're desperate, they can bypass AA, and go Auto-Ack only, but every batch that exceeds that by some threshold (5 pilots) will pay X-hours per pilot in the batch. 10-pilot batch, 1-hour per pilot. 15-pilot batch, 2-hours per pilot. 20-pilot batch, 3-hours per pilot.
Thus, if you get woken up by a 2 am call with a 30-pilot batch, you'll at least be paid 5 hours. Increasing batch sizes scales the penalty. People will get woken up, but at least you'll be paid if you're not likely to get the trip. Would that work? This is the exact same reason the company abused batch sizes before, which led them to abusing M7 the first time. It’s the same reason they are stuck now. They're trying to cover way too much flying compared to the way they used to. |
Originally Posted by Valar Morghulis
(Post 4006031)
Batch sizes aren’t the problem. Any batch size we’d consider reasonable the company will violate when they need to. That will generate penalty pay, which will generate pilots piling in to collect the penalty, slowing down the system.
This is the exact same reason the company abused batch sizes before, which led them to abusing M7 the first time. It’s the same reason they are stuck now. They're trying to cover way too much flying compared to the way they used to. |
Originally Posted by Valar Morghulis
(Post 4006031)
Batch sizes aren’t the problem. Any batch size we’d consider reasonable the company will violate when they need to. That will generate penalty pay, which will generate pilots piling in to collect the penalty, slowing down the system.
This is the exact same reason the company abused batch sizes before, which led them to abusing M7 the first time. It’s the same reason they are stuck now. They're trying to cover way too much flying compared to the way they used to. Time to run coverage? Itll go out the normal way. You’ll only be woken up if it’s yours. No time to run coverage? It’ll go out as a QS, and the company pays 3x in exchange for the inconvenience to pilots of only having a single batch. Any changes to this will need to be requested by the company in section 6 in exchange for substantial return elsewhere, end of story. |
| All times are GMT -8. The time now is 10:46 PM. |
Website Copyright © 2026 MH Sub I, LLC dba Internet Brands