Apollo would only zero the value of the e-ticket if the coupon was in an "open" status after midnight of the day you were supposed to fly. It left the itinerary intact. Fixing a zero’d ticket was a simple matter. Re-building an itinerary is more difficult and sometime impossible. If you stood by on another flight or were rerouted on UA or another carrier the coupon status would be used and Apollo wouldn’t touch the ticket.
In Apollo the 3 functions of ticketing, reservations (itinerary booking) and airport operations were optimized for each functions needs. SHARES is fundamentally a reservation system that seems to be programmed to maximize inventory availability (hence the immediate cancellation segments).
As for adding the ARUNK; airport agents were not trained to do this during initial training nor during OJT. It is something that has been passed around among agents in past few weeks as a way to thwart SHARES' proclivity to cancel itinerary segments. I suspect agents at hubs are more attune to this problem/work around that line station agents as we suffer the consequences more often and to a greater degree.
This is a SHARES weakness. Automated systems should be designed to reduce operator input not increase it.
Originally Posted by
azstar
This is not unique to SHARES, by any means. Once your original flight is "closed" by the gate agent when you're not on it, all subsequent flights get cancelled. The error, made by too many airline agents, is that they don't reinstate your "downline" reservations when you do show up and they put you on another flight.
This was not the case with UA's implementation of Apollo.