Travel as a Service
Audience
Are you into software? Not just software… platforms. Software platforms that fundamentally alter how industries function and are perceived… then I think you’ll get a kick out of this article… doesn’t hurt if you like to travel either.
Dictionary
- TaaS: Travel as a Service
- PaaS: Platform as a Service
- SaaS: Software as a Service
- PMS: Property Management System
- RMS: Revenue Management System
- HRMS: Human Resource Management System
Overview
A couple of months back, I wrote about how technology powers the travel industry. This article will cover how TaaS will impact the travel industry.
Definition
I like Jonathan’s language and technology agnostic definition of a platform and will just paraphrase his most succinct parts as we will be talking about platforms a great deal.
Platforms are structures that allow multiple products to be built within the same technical framework. It provides a business framework that allows multiple business models to be built and supported. E.g. Amazon started by selling books. Over time they have expanded to selling all sorts of other things.
The business framework leverages the knowledge about its customers to build new business models. Amazon built a retail platform that gathered huge amounts of data on how people buy things online. They used this knowledge to extend the platform to sell more and different things.¹
Platforms, platforms… platforms
The title of this article is “Travel as a Service”. I’m fondly mimicking the SaaS and PaaS acronyms we’ve all come to love as buzzwords for our next startup. Before we continue, I invite you to take a moment to think about the title and what it means to you.
[…..10 seconds later]
Based on your feeling of the meaning of the word, does Travel as a Service already exist? Is anyone offering this as a platform, a product, a suite of products or something else entirely? If “Yes”, please post a comment after reading the [entire] article and share!
I would argue “No”. But first, let’s cover what already exists today. We shall arrive at our destination through negation; what it is not.
Today’s platforms
The travel industry has many large software platforms. The more well-known ones are the large booking sites we all use to get to where we want to go. They’ve integrated many different products, from different suppliers, such as flight, hotel and car rentals. On the backend, they’ve had to integrate with 100s of external supplier systems to help automate the access to inventory. They’ve also enabled other parties, such as affiliates, to integrate with their platform and help sell their inventory.
Less sexy platforms, but equally important, are the B2B ones that offer a suite of services to the suppliers themselves. Payment gateways, PMSs, channel managers, booking engines, RMSs, HRMSs etc. Think of all the systems an airline or hotel need to be operational.
A few large companies offer an impressive amount of services to its supplier partners but no one company offers it all and understandably so. There are too many edge cases, niche markets and regional restrictions and regulations to make that possible.
Unfortunately, this is where fragmentation occurs and the problems begin. With a plethora of travel tech companies offering up B2B travel products of different shapes and sizes, it becomes difficult for suppliers to choose which products to buy. The product they might desire the most could lack integration or support for their existing system(s) or vice versa. It’s down to each supplier to select the combination of products that enable them to operate. Choosing can become costly as they find out, only later, that the product they thought could support a certain feature could not because there was a version mismatch or similar. Fragmentation is expensive; both for travel tech companies and their customers.
For travel tech startups, entry into the market is expensive because you have to spend 65% of your time integrating with legacy systems your customers have been using for decades instead of focusing on adding value. Those legacy systems are slow to integrate, costly [for you and your customers] and inefficient (on-premises, outdated technologies, technical debt => slow to move etc). The suppliers just want to maintain the status quo of their cash cow for as long as they can. [They also worked hard to get there, back in the day.] Therefore, there is no impetus to integrate with [yet another] vendor, like yourself.
Proving to the industry that you are worthy is costly and results in most travel tech startups scaling down out of practical necessity. They join the ranks of 100s of other companies trying to be laser focused and still add value and end up as “just another widget company”; having no integrations with companies that own inventory (aka the power brokers) but offering a “pop-up” that promises their customer greater profits and freedom from the oppressors… when all it is actually doing is causing more fragmentation with questionable added value.
Travelers experience fragmentation and inter-operability issues through delays, cancelled tickets 24 hours after the booking was made because the seller didn’t actually have any inventory allocated and bad customer service because the supplier doesn’t know you.
The state of travel tech today is a cluster fuck.
Coming back to the meaning of Travel as a Service for a second. Based on what you know already and what you’ve read so far, do you think any of the existing types of platforms I mentioned above sound like they might be worthy of the acronym: TaaS?
Tomorrow’s TaaS
My personal passion is building [and selling] large, scalable, enterprise-ready software with an equally passionate team of likeminded people. Sometimes you need 200 people and sometimes you only need a handful to get the job done.
The first lesson I learned in software was from my boss. He said to me “You can build something good, fast and cheap… now pick two.” That lesson has held true for the last 20 years of my career.
I mention this because if you’re going to build an amazing product, based on an equally amazing story, you really only have two options when building something: “good” and “fast”… and for that you need exceptional people.
Let‘s get on with the story!
A non-technical look at what a TaaS should solve
- Always a direct connection between customer and supplier.
- A wealth of travel inventory available for sale.
- Bespoke travel solutions and recommendations.
- Configurable inventory.
- Transparent and competitive pricing.
- Larger experience — Just a room is not enough.
- Seamless payment options between customers and suppliers and amongst suppliers themselves.
- Reduce cancellations, payment risks and payouts.
- Real loyalty.
- No more customer silos. Offering lasting value to customers and suppliers.
- Democratization of inventory. Make it available everywhere with ease.
A quick technical look at what a TaaS should look like
- Federated authentication³. A single authentication provider spanning suppliers and customers.
- Inventory channel types are managed by the platform and the actual channels are maintained by the inventory owners respectively. This lets owners control, where, how much and commission levels on a per channel basis.
- Microservice architecture serving up APIs within a specific travel context. E.g. rooms. APIs do not need to be standardized but they need to be simple, performant and available across different protocols and data types for consumption.
- Emphasizing that we do NOT need to start a TaaS by working with existing standards. The OTA specification is large, heavy and complex and uses similar heavy SOAP messages for data exchange. As a result, vendors interpret and implement the spec slightly differently; making the spec a non-spec. Not worth the headache!
- With 100s of smaller services supporting both travelers and suppliers, being able to communicate state and data changes effectively and reactively across travel contexts; while still being able to scale effortlessly. The overall software architecture should be leveraging event sourcing and be largely message-driven. We should be emphasizing the use of newer, more lightweight, streaming protocols and optimized data types. I’m purposefully leaving specific vendor names and implementations out of this document because technologies change daily.
- For data storage, each micro service should maintain and persist their own data. Data from all micro service applications should flow into business intelligence and analytics tools.
This is the end of part one. Part two covers daily use cases this platform solves. Hope you’ve enjoyed the read so far.
Disclaimer: These are all my personal ramblings and does in no way reflect the views of my parents or my companies. It’s really just therapy… that’s all it is.
Resources
- What is the difference between a platform and a product by Jonathan Clark
- The Twelve Factor app by Adam Wiggins
- Authentication vs. Federation vs. SSO by Robert Broeckelmann
