Nucleus Open Time Prototype Survey
#51
Line Holder
Joined: Mar 2012
Posts: 1,212
Likes: 22
From: Two Wheeler FrontSeat
I think the SWW we agreed to in that POS contract some of you supported is worst than letting guy fly FAR limit. It’s seems like there are less guys available on RSV. First minute of open being released, trip trade denied due to Max Open Time Exceeded.
It’s funny some of you are concerned about how much guys will fly with no limit on trip pickup, however you are the same ones who supports that VB Plan which will encourage people to fly until they drop like flies, to maximize their retirement payout.
It’s funny some of you are concerned about how much guys will fly with no limit on trip pickup, however you are the same ones who supports that VB Plan which will encourage people to fly until they drop like flies, to maximize their retirement payout.
Last edited by StarClipper; 10-07-2018 at 05:49 PM.
#52
Gets Weekends Off
Joined: Nov 2013
Posts: 2,756
Likes: 0
Trip proffer is a definite positive, however, better would be no bogus airport/hotel standbys that don't get filled, and more flexibility to drop. You would think the company would learn by now that sick calls go way up when they disallow drops and trades.
#53
Does that make my comment that Real Time Trip trading eliminates OTP?
See, the nice thing now is that you can go out and mow your lawn, go to church, eat dinner, all without having to be constantly scanning Open Time for that primo cherry trip to regain the hours you've elected to drop versus remaining in Substitution.
I tend to wind up with OTP occasionally. Think twice this year. But just because it's rare for me, doesn't mean I think the ability to use it should be severely impacted by a change in typical processing times.
See, the nice thing now is that you can go out and mow your lawn, go to church, eat dinner, all without having to be constantly scanning Open Time for that primo cherry trip to regain the hours you've elected to drop versus remaining in Substitution.
I tend to wind up with OTP occasionally. Think twice this year. But just because it's rare for me, doesn't mean I think the ability to use it should be severely impacted by a change in typical processing times.
If someone has OTP and is looking to replace a declined SUB trip, they put in priority make-up requests for the days they would like to work along with various criteria/limits for the trips they will accept. Now a trip shows up in OT and it's a good one. Everyone wants it.
Assuming our OTP hero's criteria matches this cherry trip, his PMU trumps any general M/U requests for the same day as well as the all the frantic trip specific M/U requests that went in as soon as the folks hawking OT saw this trip. So, how would processing all those requests in real time, awarding the trip to the guy with OTP and telling everyone else "no trip for you" a few seconds after they hit the enter button hurt pilots with OTP?
There's currently no required waiting time for a basic trip specific M/U request. Something good shows up, I put in a M/U request, the scheduler is on the ball, sees it and processes it 90 seconds after my request was submitted (or I call skeds and ask them to process my request, which they do). I get the trip because the guy with OTP didn't put in a general request with criteria for that day and wasn't checking OT often enough to see the trip before I did. This scenario can and frequently does happen right now. How is that any different from real time trip trading?
#54
Gets Weekends Off
Joined: Jul 2017
Posts: 121
Likes: 0
Can you explain why what we currently do is not compatible with real time trip trading with some minor adjustments?
If someone has OTP and is looking to replace a declined SUB trip, they put in priority make-up requests for the days they would like to work along with various criteria/limits for the trips they will accept. Now a trip shows up in OT and it's a good one. Everyone wants it.
Assuming our OTP hero's criteria matches this cherry trip, his PMU trumps any general M/U requests for the same day as well as the all the frantic trip specific M/U requests that went in as soon as the folks hawking OT saw this trip. So, how would processing all those requests in real time, awarding the trip to the guy with OTP and telling everyone else "no trip for you" a few seconds after they hit the enter button hurt pilots with OTP?
There's currently no required waiting time for a basic trip specific M/U request. Something good shows up, I put in a M/U request, the scheduler is on the ball, sees it and processes it 90 seconds after my request was submitted (or I call skeds and ask them to process my request, which they do). I get the trip because the guy with OTP didn't put in a general request with criteria for that day and wasn't checking OT often enough to see the trip before I did. This scenario can and frequently does happen right now. How is that any different from real time trip trading?
If someone has OTP and is looking to replace a declined SUB trip, they put in priority make-up requests for the days they would like to work along with various criteria/limits for the trips they will accept. Now a trip shows up in OT and it's a good one. Everyone wants it.
Assuming our OTP hero's criteria matches this cherry trip, his PMU trumps any general M/U requests for the same day as well as the all the frantic trip specific M/U requests that went in as soon as the folks hawking OT saw this trip. So, how would processing all those requests in real time, awarding the trip to the guy with OTP and telling everyone else "no trip for you" a few seconds after they hit the enter button hurt pilots with OTP?
There's currently no required waiting time for a basic trip specific M/U request. Something good shows up, I put in a M/U request, the scheduler is on the ball, sees it and processes it 90 seconds after my request was submitted (or I call skeds and ask them to process my request, which they do). I get the trip because the guy with OTP didn't put in a general request with criteria for that day and wasn't checking OT often enough to see the trip before I did. This scenario can and frequently does happen right now. How is that any different from real time trip trading?
I don’t get it, why do they have to push a button for a process that seems automated?
Why not have a standard amount of time after a request is input and then it is processed?
#55
You mean they will continue to do what they are already doing?
#56
Line Holder
Joined: Jan 2008
Posts: 68
Likes: 0
#57
Line Holder
Joined: Feb 2018
Posts: 277
Likes: 0
From: MD-11/C-17
*our A-fund that loses purchasing power every year.
#60
Can you explain why what we currently do is not compatible with real time trip trading with some minor adjustments?
If someone has OTP and is looking to replace a declined SUB trip, they put in priority make-up requests for the days they would like to work along with various criteria/limits for the trips they will accept. Now a trip shows up in OT and it's a good one. Everyone wants it.
Assuming our OTP hero's criteria matches this cherry trip, his PMU trumps any general M/U requests for the same day as well as the all the frantic trip specific M/U requests that went in as soon as the folks hawking OT saw this trip. So, how would processing all those requests in real time, awarding the trip to the guy with OTP and telling everyone else "no trip for you" a few seconds after they hit the enter button hurt pilots with OTP?
There's currently no required waiting time for a basic trip specific M/U request. Something good shows up, I put in a M/U request, the scheduler is on the ball, sees it and processes it 90 seconds after my request was submitted (or I call skeds and ask them to process my request, which they do). I get the trip because the guy with OTP didn't put in a general request with criteria for that day and wasn't checking OT often enough to see the trip before I did. This scenario can and frequently does happen right now. How is that any different from real time trip trading?
If someone has OTP and is looking to replace a declined SUB trip, they put in priority make-up requests for the days they would like to work along with various criteria/limits for the trips they will accept. Now a trip shows up in OT and it's a good one. Everyone wants it.
Assuming our OTP hero's criteria matches this cherry trip, his PMU trumps any general M/U requests for the same day as well as the all the frantic trip specific M/U requests that went in as soon as the folks hawking OT saw this trip. So, how would processing all those requests in real time, awarding the trip to the guy with OTP and telling everyone else "no trip for you" a few seconds after they hit the enter button hurt pilots with OTP?
There's currently no required waiting time for a basic trip specific M/U request. Something good shows up, I put in a M/U request, the scheduler is on the ball, sees it and processes it 90 seconds after my request was submitted (or I call skeds and ask them to process my request, which they do). I get the trip because the guy with OTP didn't put in a general request with criteria for that day and wasn't checking OT often enough to see the trip before I did. This scenario can and frequently does happen right now. How is that any different from real time trip trading?
Based on the inputs available for generic Makeup\VLT...not thinking our Beloved IT department would put a lot of effort into it.
Nor would I "trust" them.
In general, seems like the 90 second trades happen during the Sick Time Open time frenzy. Post 10 Memphis, or even worse-Sunday afternoon\evening...trades can take a looooonnnnggg time to process.
At some point in time, the person with OTP is going to be checking open time and as is the case currently, a trip's likely been sitting there for quite awhile. So long that those unused to dial up internet (or a Telephone Makeup request) are probably banging their heads and coming over to APC to post comments while simultaneously texting their friends how ridiculous it is that they have to WAIT, for anything.
But, it's been sitting there with maybe 2-5-17 submitted requests. All of which are for naught once the Trump Card of OTP is input.
And, as much as I like the idea of a generic OTP submission, my last OTP trip was an X pairing to a city combination not in my bidpack so there's No Way I could've expected that.
More than Real Time trading, I'd love to see SUB simply go away as a Paid event. But considering that FedEx cancels trips weeks in advance, just can't seem them agreeing to it.
And, to be honest, would be worried at what FedEx would do. Any CBA restrictions against revising a trip to a Memphis HSBY, for example?
Thread
Thread Starter
Forum
Replies
Last Post



