Thanks for coming this far. If you’re excited about travel, startups or just building stuff in general, I owe you a good story, just a little tad bit long read but I hope you’ll definitely take away 5 cents of learning at the end.
We’ll be covering FIVE pain-points in a series of three blog posts — this is the first one.
Almost all non-travel friends and colleagues I talk to, within the startup ecosystem about the overall travel-tech space, gets shocked on how/why the tech landscape is structured the way it is in this industry. Everyone thought FinTech was difficult due to regulation, gatekeeping, and big learning curves, but TravelTech was always competing five steps ahead to make it more difficult — just that very less folks were paying attention to it, until the last 4–6 years where we’re witnessing some great products being built.
This is the story on WHY we’re so excited about building Zenmer.
Let’s get started
In the early 2000 when I was around 9 years old, I still remember one day when my father was preparing a physical air ticket in his office for a group of 60 students traveling for an educational trip to Singapore. This was a time when paper tickets were still a norm.
My dad’s offline travel company ‘Tolu Tours’ helped families plan their international trips and small businesses plan their business trips globally. I know you must be wondering what does ‘Tolu’ mean and no it doesn’t really mean anything and it’s definitely not my pet name :P (this is what most folks guessed at first). They wanted something different and erratic and just randomly came up with it.
Like a cool young boy trying to impress his dad in his own garage I asked, ‘Dad, do you really need to spend so much time preparing each ticket and what if it goes worn out or missing?’, to which he replied — ‘Yes son, but maybe in near future we might not, when young smart children like you build some great technology’. I didn’t really understand what exactly he meant by ‘building a great technology’, but it definitely intrigued me towards the travel industry.
As I grew up and graduated in Industrial engineering, I’d almost forgotten about that experience and surely some smart folks ended up building the eTickets followed by hugely popular success of OTAs like Expedia, MMT, Cleartrip showed that the consumers had enough great options to book travel. But while I was exploring ideas for my second startup in late 2015, I again noticed several tasks being done in his office manually by teams spending tons of man-hours on things which were completely unproductive.
These were simple things like
Preparing quotations for a client trip
- Every time their client (a company employee) wanted to plan a business trip, they would email our office for flight and hotel quotations.
- The team would then open the Desktop GDS (Group Distribution System, commonly used by travel companies globally) software and a few individual airline websites to search for fares. In the GDS, they would search by typing some alien cryptic commands which reminded me of programmers using shell/terminals or old Sci-Fi space movies (but in no way this was outer space to look even half-decent cool for a movie buff like me).
- They would then spend 10–15 mins more to manually figure out the five cheapest options, and copy paste data from different websites into an email. Now since each website/software has their own formatting, font, and design — the email content looked extremely ugly.
- Then the company employee would somehow make sense of the ugliness and request to book the preferred option.
Maintaining client bookings and profiles
- The team would then ask for more details like passport, visa and other relevant information over email, and then store the client documents locally in their windows folders arranged nicely by company names, employee names, etc; connected to Dropbox (I was proud at least this bit of cloud-based file sharing tech was in place).
- To book the flights, they would again type some 20–50 lines of random cryptic commands into the GDS and this time not just one person, but at least 2–3 people touched the same booking in their computer to type their lines of cryptic code to finally complete the booking.
- The team member after booking the flight, would share the booking details with the accounting team over email.
- The accounting would either manually create an invoice spending 10–20 mins or would again use the GDS to export the booking into another software that would create the invoice.
Now just imagine the above cryptic processes for hundreds of bookings happening every day. It would be a day-time nightmare right?
Immediately, I was thinking why wasn’t there
- A centralized cloud-based software that had a unique login for each user (including all the team members of the travel company and all the employees of the end client).
- The employee itself would search for flights and book the preferred option like we do on Expedia, MMT etc.
- The software would email the eTickets and automatically create the invoice and send it to the finance team
- The company’s team could have amazing data insights into how much they’re spending on travel, a breakup per department/employee/airline etc. and show recommendations on how they can save costs.
- The travel company’s team could have amazing data insights into how much revenue they’re generating, which clients are booking the most, which airlines/hotels are being booked the most to do better and faster negotiation with suppliers, reduce thousands of man-hours, human-errors and costs to manually search, book and invoice flights, hotels, trains, buses and cars.
- And more than anything else, remove the need to learn the cryptic commands for simple mundane work, because it’s the 21st century for heaven’s sake.
I realized that knowing these problems and coming up with the above solution wasn’t enough because I couldn’t be the only one aware of these problems, and someone might’ve already figured out the solution by now, and it’s probably that my dad’s team wasn’t really aware of great tech products in this space. Hence I termed the identified issues as ‘Problem ONE’ and started digging more to identify such products and more burning problems, spending months on researching the business travel space.
Firstly — I really wanted to know more about the GDSs’ moat, to figure out why they were being used by almost every travel company globally in spite of such high learning curve, bad user experience and overall it being on still running on legacy mainframe technology.
What the GDS research revealed
The travel industry has been mainly reliant on the Group Distribution Systems (GDS) since the time commercial airlines became mainstream.
To better understand — Imagine there are hundreds of airlines flying on thousands of routes around the world, and if a travel consultant wanted to quickly find the best flight options from London to New York, it would be a nightmare of the worst kind to search across those hundreds of airline websites right? Here comes the GDS, which aggregates fares from all major carriers globally to give travel companies one single place to search across all flights. There are three major GDS’s globally (Amadeus, Travelport and Sabre) which have enjoyed enormous wealth and monopoly in their own regions for more than the past 20–30 years.
The GDS tech stack was built 2–3 decades back on mainframe and analog technology, and travel companies logged into it via a native desktop software that took hours for installation, several weeks (if not months) to learn and quite intimidating for a world post 2015 world where the narratives of cloud-driven, mobile-first, and SaaS-based had already become mainstream.
When I first looked at those full blue colored GDS softwares, I thought to myself — would I be able and wanting to use this being a 25 year old millennial? Would this still be the go-to way for the next 2–3 decades for travel companies to search inventory? I’m sure you already know the answer is NO.
Each flight booking created an Airline PNR, and the GDS replicated its own version of PNR to fetch/identify any booking in the GDS. One important thing to note is that the airline industry is usually divided in two categories — 1) Full Service Carriers (FSCs) and Low Cost Carriers (LCCs).
As the name suggested, FSCs (like Air India, Vistara, Emirates, Lufthansa, American Airlines, etc) were airlines that usually gave a full-service experience which included the meals and seat in the total flight cost. LCCs (like Indigo, Air Asia, RyanAir, Southwest, etc) on the other hand tried to offer the cheapest flight cost with all extra additions available for an extra cost if required.
The GDS mostly included inventory of FSC carriers and only 10% of LCC carriers were available on the GDS. Because FSCs were a majority globally until 2010, GDS had become an extremely core part of the booking management lifecycle for travel companies. As more and more LCCs started appearing globally, the GDS dependency created a new burning problem that would haunt and take the travel-technology 10 steps back backwards instead of moving forward.
Here’s welcoming Passive segments — a way for travel companies to create dummy bookings into the GDS that didn’t originate from the GDS.
Let’s take an example:
- Consider any LCC flight, hotel, car, or train was booked outside the GDS by the travel company.
- They would need an ability to always fetch these non-GDS bookings and invoice them easily instead of trying to go to each supplier’s website to find them. If they wanted to quickly find a hotel or LCC booking that was booked for a specific employee, instead of remembering where it was booked and then trying to access that website, they thought what if we could connect these bookings as part of the GDS PNR itself as they’re already used to it and it could even invoice the booking as it would for the flight. Not an unfair ask right? I wouldn’t say as yet.
- The resulting solution that the industry started to adapt was to use the existing GDS PNR (connected to the flight booking) and add other non-GDS booking data into it in the form of free-text remarks— terming them as passive segments. It would be difficult to point out why and which stakeholder recommended this approach, but this is where the problem started and the industry took 10 steps backwards, giving rise to my ‘Problem TWO’.
- The world was talking about data standardization to better store, access, secure and analyze data; and here we were starting a practice that allowed booking data worth hundreds of billions of dollars being entered into a legacy database in a free-text format.
To give you some context if you’re a techie reading this, one LCC booking would somehow be stored like this
<freetext>Aircraft Owner Indigo</freetext>
<freetext>Passenger name John Doe</freetext>
<freetext>Passport number S84848484</freetext>
<freetext>Passenger DOB 21/08/1976</freetext>
For any non-tech person, just imagine that you’re driving in a not so familiar city and Google maps telling you ‘Bla Bla Bla, Bla Bla, Blaaaaaaaa, Bla Blaa Blaaaaa’.
The only thing you can understand is the language being spoken, which is English, but your mind cannot store (because it’s not useful), analyze (because it’s not relevant) or take any action because it’s not communicating to you in a manner that you understand. Similarly like a human brain, the software code cannot analyze or take any action with this free-text data. Let’s term this as Problem TWO.
Your mind is probably going around in circles, while trying to absorb either the complexity or trying to believe and accept these crazy problems.
We’ll take some break here, and continue with Part 2 in the next blog post where we’ll cover a couple of even crazier (I bet :P) problems. But if you've got the energy the carry on, continue reading the second blog post here.
If you've read this far, we're extremely grateful to you. If you’re excited about our WHY and the future of TPaaS, we’re looking for more warriors to join our small ship — DM me on LinkedIn or Twitter.
To learn more about Zenmer, visit our website.
— Nikunj Agrawal, Founder & CEO, Zenmer