Wondering if anyone has come up with an answer to an ongoing issue of ours. With schedule changes, often the ticket does not need to be reissued - meaning no interface to the backoffice of the schedule change. When we go to do arrival and departure lists for large groups, the backoffice does not have the most up to date flight information - which results in a ton of manual updates. Any tips out there that you have found????
In a traditional TMC arrangement the TMC makes money when they issue a transaction which is usually triggered by a ticket issuance or reissue. In the case of something like this you're correct that any reporting could be "off" unless the PNR is queued back to Concur. Concur only knows things when the PNR is queued back to them. We used Concur's API to build our own "live" database to run our own arrival/departure reports and our requirement is that the agency must queue the pnr back to Concur any time they touch the pnr (no matter what they do). I don't care whether that means a PNR is queued a 1,000 times but it ensures the most accurate state is known to Concur. TMC's can set up auto queuing on "end transaction" for SABRE so it's automated (setup and forget). Not sure how well Amadeus or Galileo work with that. If the TMC is unwilling to set that up (don't know why) then maybe suggest that they queue all your pnr's back to Concur 2 weeks prior and 1 week and 48 hrs prior to Concur. There's automation out there that can do this easily. It's a pity we can't have a configuration setting in Concur to automatically pull the current pnr back into Concur 48 hours out or something regardless of what the TMC does. That way, you know it's accurate when the traveler most cares about it too (and useful for TripIt).
We're a CTD so we don't care about an "invoice" trigger but this is a conversation you need to have with your TMC.
Hope that helps...
OK cool. We use Compleat as our mid office automation and that could queue pnr's over at a set date/time.
Likewise SABRE has the end transaction queue which automatically queues it wherever when an agent ends the transaction. This requires the agent to acknowledge the schedule change from queue if nothing else whereas Compleat can be told "go and queue this pnr 24, 48, 72 hours prior to travel" for example.
The more I think about the more I believe Concur should do that. That way the Concur mobile/Trip it etc... is more likely to be accurate.