Why it’s critical to establish a direct line of communication between travel managers and developers
No OBT is fail-proof, 100% of the time
The goal of any head developer is to architect an application that can weather even the worst of storms. But in a world of interconnected systems, with different competing priorities, that’s not always possible.
Just as Columbus had no way to know unexpected rough currents would run the Santa Maria aground, my development team can’t always predict how our online booking tool will react to the next big change in business processes by a supplier or how a non-versioned overhaul of web services by one of our direct connect partners might create unexpected errors.
Cheesy nautical metaphors aside, it really is impossible to prevent outages in other systems from affecting the user experience in Innfinity. With so many moving parts, creating an online booking tool that allows you to book 100% of the content 100% of the time just isn’t possible. You can get very close to perfection, but you can't control hardware and software changes outside of your domain.
(We have, however, maintained a 99.96% uptime on our system since its go-live three years ago. And I’m proud to report in that time that our longest ticket resolution we’ve reported was 21 days. And the vast majority of other issues that could not be worked around were resolved within a day.)
Developers must pay close attention and listen
While all OBT’s will have content issues at some point in time, I think at Innfinity we’ve really excelled at listening closely to users and responding promptly to their needs when issues with the online booking tool have arisen.
The way we’ve done so is by maintaining real, direct communication with our TMC partners and travel managers. We have avoided opening support tickets that get handed off from one support technician to the next, only getting escalated once upper management catches wind and yells at one of us to take care of the issue.
To ensure this doesn’t happen, we check in with travel managers (and their TMC’s) on a weekly or bi-weekly basis to make sure their needs and concerns are addressed regularly.
We do this because placing developers and our clients in a conversation allows us to better create technological solutions that are able to address their needs. And unlike other legacy online booking tools (OBT) that preference their development roadmaps over fixes for their clients, we firmly believe our users’ needs must come first.
A precedent of neglect set by legacy OBT’s
At an initial meeting with one of our first travel management company (TMC) partners, we started to discuss the development process at Innfinity. Account managers and their IT department alike expressed their frustration with being unable to explain their problems to the development teams at other OBT’s. They emphasized that all too often they’re on the phone talking to an account rep, trying to get something fixed for a client in peril, knowing full well the person they’re dealing with has no real sway with the development team and often a basic lack of understanding of the root of the issue.
And this TMC isn't the only one to complain about the lack of responsiveness from legacy OBT’s. At a GBTA conference, I met a user of a well-known OBT that told me about the lengths she had to go to even be taken seriously by her OBT. She runs a travel program that books over 3,000 flights a month and accounts for an annual travel spend that is well over seven digits. She confided in me that she had to threaten her OBT with contract termination before they gave her issue with regional flights a second look.
The fact is that these stories are not isolated incidents. We’ve heard time and again from TMC’s and travel managers that getting anything fixed or changed is a drawn-out nightmare with most legacy OBT’s.
To get issues fixed in the legacy code bases of some of the older players in the corporate travel space, you either need to know someone with influence or you can expect to wait weeks, if not months. This leaves travel managers stuck trying to make due with an OBT that can’t make good on its promises, managing a travel program that’s running up their budget and frustrating everyone in the process.
Neglect from the OBT is costly to travel buyers
For travel buyers managing a travel program, the neglect of an OBT to see to their needs is both aggravating and costly. A few examples of neglect I’ve heard that ended up costing companies in the long run:
· The OBT doesn’t display a specific price or flight that should be appear in the results
· The OBT isn’t pulling up bulk fares properly
· The OBT isn’t pulling up unusual routings because it deems them undesirable
· The OBT delivers different functionality on the desktop and in mobile
· The travel managers can’t get traction for issues with small markets
Time to open up the lines of communication
This is why I, as well as everyone else on my team, believe that giving clients access to developers is tantamount to providing an online booking tool that keeps with the times and addresses the current needs of each client.
Of course this doesn’t mean I’m giving my phone number out to every travel manager across the Western hemisphere.
But a weekly meeting, where I can really check in with our users to assess their needs and requests, is essential. Users are, after all, our guiding light as developers. They will spend more time with the software and know the market better than any developer.
So here’s to championing more communication between development and travel managers as part of our continued effort to build and grow an online booking tool that works for travel managers and TMC’s, not against them.
Anyway… just a few thoughts from the guy that stares at the code most of the day. Thanks for reading!
About the author:
Jon Carmody is a Senior Develop at Innfinity and the Team Lead on the Innfinite online booking tool.