If you work in any job other than with an airline website then stop reading now, as today’s post promises to bore you to tears. It is all about when is the optimal time to perform the TTP/ET ticketing entry. I’m not kidding, if you are still reading, then you’ve only for yourself to blame for falling asleep at the keyboard.
I was in Nice, France all last week. It is the largest Amadeus office and the primary development center. Part of the reason for me being there was for meetings with two different airlines; it was in one of these meetings that the topic arose regarding online ticketing. As usual, I was definitely not backwards in coming forward with an opinion! The question came down to whether to perform the ticketing command on the booking confirmation page of the website, or to do it immediately after EOT on the PNR. I am firmly a believer in the second option; but be warned, this is just my personal opinion and not some officially endorsed position. Now in the past I may have had a vested interest in recommending one option over the other, as originally I was involved with airline websites, then I moved to direct channel back office applications, but these days I represent a much broader range of products covering whole of airline IT, so I’d like to think my opinion is not influenced by what I may have been selling in the past.
In the meeting last week I don’t think I was that successful in convincing the airline in question to do the ticketing offline, but then again, in the scheme of things it is far from the most important decision for an airline website manager to take – whatever method is chosen should not have a huge impact. That said, it is still something that needs to be understood if you are operating in an environment where tickets are issued – obviously ticketless LCC’s will find this discussion totally irrelevant. The core theme for me, and the biggest factor influencing my preference, is that realtime critical applications (ie. the website) should be built with less points of failure. More importantly, the smallest complexity/functionality added to the online booking flow should only be done so if it has the potential to improve the chance of increasing airline revenue (or in some cases, but more often post booking flow, reducing the cost to serve).
I can think of one medium sized airline that took the opposite approach to their website and wanted everything conceivable to be done within the UI layer, but last I heard they are now finding that approach more expensive and difficult to maintain than they originally expected and are currently looking at other options. My view on this is very clear – the website is for taking flight bookings, then upselling and cross selling, and then post booking flow, servicing those bookings as well as more upselling and cross selling. Any added complexity, no matter how small, that does not (even indirectly) benefit one of these objectives must really be questioned. In my mind, ticketing clearly falls into this category. There are many other reasons all well, but I’ll go into these in my next post. That one promises to be just as interesting!