The TravelScrum Travel Data Exchange

Time to start the streamlining data exchange process – we can help make it a reality

Up until 2019, the travel and hospitality industry experienced unprecedented growth. Airlines carried over 4.5B passengers (IATA), as well as the U.S. hotel industry registered record breaking performance and record profit margin. Digital transformation was in full swing. Moreover, travel and hospitality companies were transforming customer engagement, improving personalization and retailing, creating connected experiences in airports, on planes, and in hotels, optimizing core operations, reducing IT costs, and working hard on sustainability. All of this was fueled by data.

Then COVID hit, and everything stopped.

In the past 18 months, as the SKIFT 2021 Digital Transformation Report highlights, one thing was clear: digital transformation remains the top priority for travel and hospitality companies. Data still stands as a major strategic asset for travel and hospitality. Furthermore, data challenges and opportunities are still ready to be tackled and unlocked.

AWS, as the world’s most comprehensive and broadly adopted cloud platform, has had the duty to support our customers and help them navigate this crisis. In May 2020, I met with industry thought leaders to discuss how to help the recovery efforts. It was clear that the focus should be on industry aspects that were vital before, during, and after the COVID pandemic. Furthermore, as industry thought leaders, we aimed to identify how we could review current practices and create a new way of thinking that would restart, accelerate, and then accomplish what COVID stopped.

To generate more ideas, we teamed up to form the TravelScrum Pilot One (TS/P1) think tank in order to identify critical projects where we could make positive impacts. The goal was to provide insights into avoiding past mistakes, spark new thinking, and disseminate know-how that, invariably, would be lost during the industry’s layoffs, furloughing, and shrinking.

TravelScrum, a non-profit organization, was the ideal partner to drive this. Its mission is to galvanize and mobilize the do-ers and dreamers of the travel industry to band together to create a better tomorrow. A virtual community of like-minded professionals and enthusiasts, all yearning to forge ahead and rekindle the unmistakable spirit of the industry.

Three projects were identified: the TravelScrum University, to spread industry knowledge and embers practices; the Customer Profile, to empower travelers and guests to own and share their profile data (now morphed into the Hospitality and Travel Special Interest Group (H&T SIG) of the Decentralized Identity Forum (DIF) initiative); and the Travel Data Exchange, to facilitate data interchange in the industry ecosystem.

Data is the fuel of the industry and the core of digital transformation that can be enabled by cloud technology. More specifically AWS can help accelerate its use. Therefore, I decided to dive deep into the Travel Data Exchange.

The Travel Data Exchange

One of the industry’s key problems is that it is data-rich and insight-poor. This means data is locked away in physical and logical silos. Extracting insights and making data accessible at scale and low cost across the organization goes against legacy and disconnected systems with security, privacy, and governance challenges. This then causes long project timelines, unplanned delays, and ramping costs. These problems were even more apparent when data initiatives spanned separate companies and organizations, as no single decision-maker existed, let alone a single IT system.

We wanted to tackle how we can enable entities both inside and outside of a company to share information about travelers/guests or operations in order to improve system efficiency and, ultimately, customer experience. Operating within an entity/company would be a “small” and circumscribed task, but TS/P1 decided to investigate what it would take for multiple interconnected entities or companies to exchange data in order to improve the customer experience.

Leaders from Accenture, American Express, 3Victors, HotelAds, and Smart Hotel Rate, as well as former leaders from HTNG and global airlines joined together to think about how to eliminate barriers and thereby improve customer experience in an interconnected travel and hospitality ecosystem.

First, we decided to define the customer: in this case, it is the traveler/guest. Our focus and all recommendations from this exercise should improve customer experience. In other words, how the customer is engaging and engaged by the travel and hospitality ecosystem in order to better purchase and experience its products and services.

Second, we defined the problem that this mechanism, the Travel Data Exchange (TDX), would solve: how to place the traveler/guest in control of their data and allow them to exchange information seamlessly with designated entities (companies) in a safe, secure, and controlled way in order to ease and simplify travel ecosystem engagement. TDX would provide an enhancement (evolution) rather than a transformation (revolution) of current practices. We would start from the digital experience and expand to the physical experience in the future.

Lastly, we defined the guiding tenets/principles that this initiative would follow: (a) work backward from the outcome, not the mechanism; (b) make it transparent for the user; (c) be easily implemented with minimal cost; (d) be optional (non-mandatory) for organizations to adopt; and (e) be incremental in adoption in order to accelerate rollout.

The Customer Experience

The travel customer experience needs an upgrade. Let’s say you want to book a trip to fly from Boston to Hawaii, reserve a 5-star hotel, and a ride to/from the airport with your favorite ride-hailing company. Today, the process is inefficient and convoluted. You go to the airline website, input your travel dates, preferences, select the flight option, input your name, credit card information, address, and make the booking. Then you go to the hotel website, again search for the exact same dates, similar preferences, your name (again), your credit card information, your address (again), contact information, etc. Finally, the car hire, all of the same information (again) gets input for the trip to the airport and from the airport…4 times!

This is not only tedious and lengthy, but also prone to error. You’re tasked with tracking the trip details to make sure the information is correct, consistent, and up to date (e.g., you are booking the correct dates, arrival times, etc.). And it gets even more tedious if you must add the same COVID information for each of these.

Moreover, to complicate things even further, if your flight changes, voluntarily or involuntarily, like any other bit of your plan, all related information must change as well. And this via four or more different and disconnected websites, mobile apps, or call centers.

Wouldn’t it be better to input all of this information just once, and then inform the airline, hotel, or ride-hailing company where to get them? And perhaps everybody gets notified when the information is updated, so that each has the latest one?

While the scenario is simple, its challenges are substantial. Let alone the fact that, a think tank, we also have limitations. As such, this is the framework we worked with:

1. Standardization: we are not a standardization body, so we can’t enforce standards and make companies adopt them.
2. Centralization: data centralization has always been a problem as the customer and the related companies would have to entrust a single entity to hold the information. This makes it not only an issue of trust, but also a honeypot challenge in protecting the data.
3. Adoption: we can’t expect a solution to be adopted right away. Therefore, it must be envisioned not as a “transformative” approach, but as complementary to the current one. This would allow companies to adopt the “new” and/or still use the “old” mechanism to collect this information.
4. Control: the user must have a mechanism to enable and disable information sharing among entities.

In the words of Johnny Thorsen, VP Strategy and Innovation at American Express,

“As a traveler I am tired of the endless number of request for me to provide the same basic pieces of information during my trip despite the fact that all my personal data probably already exist in every single supplier system – and furthermore I know that there is a booking record somewhere which includes the information about my trip which I am happy to share with all relevant service providers during the time my trip actually takes place. However, I do NOT want the various suppliers to be able to share information about me once my trip is completed, unless I get a good reason for giving the permission – which can be a commercial benefit of some form or an incremental loyalty bonus. If my flight is delayed then tell my hotel, but once I check-out I don’t want to get emails for 2 years about a hotel I only have stayed in one time. If my luggage is delayed or even worse sent to an incorrect destination then use my booking data without asking me to spend hours queuing and providing information – just deliver my suitcase to my room and send me a message when the job is done. This is dreamworld the Travel Data Exchange enables – a single entry of data (in my booking) which can be shared intelligently for a limited time (during my actual trip) and then disappear (not stored anywhere) without me having to do anything- please bring it on!”

The Mechanism

The mechanism we envisioned is a decentralized, peer-to-peer, controlled, incremental, and schema-less data exchange. But more specifically:

Decentralization: The data is stored in the same systems that it currently is. For example, this could be in the airline passenger service system (PSS), hotel property management system (PMS), or the company relationship management system (CRM). However, there is an interface where, upon request, in a trusted and controlled way, a user can ask an entity (e.g., the airline) to send their reservation data to a second trusted entity (e.g., a hotel). The mechanism must know where the data is stored and the relevant portion to be sent between organizations. This is a network of trusted partners with tight monitoring and controlled access.

Peer-to-Peer: Given the distributed nature of the data, the TDX mechanism tracks what data is stored and where. That is, monitoring of the metadata via a “broker.” The mechanism used is via routing keys that a traveler/guest can utilize to unequivocally identify who is storing their data. The broker would route requests for data to the related repository, enable them to connect, and activate the exchange. However, the broker would not have access to the data itself.

Controlled: The traveler/guest can control who-is-accessing-what by associating a key to their data, and then informing each entity that they can send the data related to that key over to whoever is requesting it via the key (the authorization). When the user revokes that key from the data repository (or it expires), then the entity would no longer be able to share/request the data.

Incremental: Given that this won’t replace the current input mechanism, but would augment it, only those entities enabling/participating in the TDX can exchange data. The data will be utilized to pre-populate the web/mobile forms in place of the user, which will then confirm and activate the normal process. If the entity doesn’t participate, then the traditional manual input will occur. Either way, customer data will then be stored in the company’s existing PSS/CRM/CRS system, but only TDX participating entities will receive updates when these change.

Schema–less: Finally, given that there are different types of exchangeable data, only the entity “storing” the data will know what the data/data types are. There will also be a need for entities to exchange metadata “synchronization” between one another (and related mapping). For example, the hotel can ask the airline for the guest’s surname, for which the airline will return the last name of the passenger.

But how would this work? In the previous example, assume that you input all of the information about your trip onto the airline website. The airline will provide you with a key (or give your own) identifying the reservation. When you go to the hotel website to book the accommodation, instead of inputting the same information again, you provide the key just received from the airline. The hotel would recognize it and inquire with the airline, through the broker, for the information needed for the accommodation booking, thereby pre-populating (copying) the required guest fields. Upon completing the hotel reservation, a newly generated key linking to the previous one is generated. When going to the ride-hailing company, simply provide this last key, and the relevant information regarding the flight and the hotel would be accessible.

The beauty here is that the mechanism is not holding/seeing/touching any of this data: only the broker tracks who hosts what data.

The guest/traveler can also inform an entity in order to “keep” this information up-to-date and propagate any change to other data subscriber entities. So that every time the data changes, the entity holding the data will automatically share the updated version with the connected entity.

When users don’t want to share that data anymore, they can simply communicate to the holding entity through the broker to invalidate the key (thereby, the data is no longer accessible or linked).

What is in it for Travel and Technology Suppliers?

In the words of Filippo Fasolo, CEO at AdsHotel, an AWS customer,

“Travel Industry is fragmented with many airlines and car rentals, but when it comes to hospitality, the problem is even more evident and travelers are struggling to manage their reservations among too many different systems. Enhancing the user experience in the booking process will be a key factor to move toward a more informed, sustainable, and ethical tourism, thereby increasing the direct relation with the local communities. This is better for the travelers and better for the hotels, and that’s why the TDX project is so important: it will create the perfect environment to give travelers the power to sync their travel plans with ease while streamlining the guest management process for the whole hospitality industry.”

TDX would improve the user experience by removing friction points, unnecessary data input, and seamless data synchronization.

However, as Rick Seaney, CEO of 3 Victors, an AWS T&H Competency partner highlights,

“Customers rightly expect a secure, seamless digital experience that intuitively morphs with their daily activities. They see this vision slowly coming true within mega-platforms like Google and Apple, and so they expect the same externally, especially across the disparate services and activities of one of their common pastimes, travel. Getting the plumbing in place to prescriptively handle complex travel activities in real-time is half the battle – the other half is inter-organizational cooperation, which ultimately users will drive with their feet.”

AWS can provide the plumbing – but how? Services like Amazon API Gateway, a fully managed service that makes it easy for developers to create, publish, maintain, monitor, and secure APIs at any scale, could be the TDX backbone. The data could be stored in Amazon DynamoDB, a key-value and document database delivering single-digit millisecond performance at any scale. This could handle more than 10 trillion requests per day and support peaks of more than 20 million requests per second, giving TDX the required scale. This would also enable the deployment of encryption at rest and in transit, thereby providing the highest standards of security that travelers and guests demand.

There will be a network of brokers, one for each TDX participating entity, with each running in a logically isolated virtual network. The broker would be “listening” to inquiries for data, scaling up and down, and costing each entity only for what is used accordingly with TDX adoption.

Furthermore, third party companies could provide plug-ins to connect TDX with established PSS/PMS/CRMs and other key travel and hospitality back-office systems to facilitate and accelerate integration. That, or data field mapping intelligence that would ease interchange between entities where data-field standardization is lacking.

But what are the benefits for the travel suppliers? Clearly, customer satisfaction (CSAT) improvement would be the main driver. However, friction reduction during purchasing would generate improved conversion, reduce sales funnel customer drop off, and streamline the overall booking process, thereby expanding sales. This would be similar to what Amazon does with the successful one-click purchase mechanism.

Personalization could even be taken to another level, as sharing preferences across the ecosystem would be easier and under user control. Services like Amazon Personalize, an off-the-shelf service that enables developers to build applications with the same machine learning (ML) technology used by Amazon.com for real-time personalized recommendations with no ML expertise required, could be readily deployed and scaled as more detailed and accurate data is readily available.

Scott Davidson, Managing Director at Accenture, an AWS Travel and Hospitality competency partner, says

“The pace of change in the travel industry is accelerating. All travel companies are talking about transforming the customer experience, but they can be distracted by putting the challenges associated with sourcing and analyzing data first, rather than starting with defining customer outcomes and associated business value. While we reference a booking and reservation change example above, there is significant opportunity across the whole business. Imagine an operational example and the implications for any travel company if they knew that a traveler would be late, delayed, or canceled before that customer communicated that to them. There is huge potential to improve both customer experience and business efficiency. If companies start with what they want to deliver, and the value it will create for them and their customers, solutions will come together for the technical infrastructure/business partnerships required to enable that vision. The TDX framework illustrates that a technical solution for sharing data should not be a hurdle to transforming traveler customer experience and unlocking business value.”

Indeed, knowing, for example, that the traveler will be late, or will arrive at a certain time, would allow hotels to propose ancillary services, such as early check-in or late check-out before the guest even arrives (or leaves home!). Alternatively, hotels could provide activities/services to the guest to enjoy until the room is ready. Another, example is if a bag is late, then the hotel could facilitate pick up, or propose services for the traveler to reduce stress, and even provide him/her what is needed like a bathing suit to enjoy vacation and/or a business suit for the planned business meeting.

Things could get even more sophisticated when, for example, corporations could provide all of their employees with a single consistent profile and preferences. This would contain the payment, contacts information, and policy details to share with travel suppliers when the employee purchases the trip, thereby ensuring accounting and travel tracking is properly in place. Or travel suppliers could set up offers that could be linked to a corporate account for all of the employees that could constantly be updated with relevant promotions.

The opportunities are endless. TDX could unleash and accelerate innovation with existing players, as well as with new startups. As Henrick Conradsen, CTO & co-founder of Smart Hotel Rate, points out, ​​

“In the last 20+ years, it has always been a struggle and expensive investment for any Travel Tech Startup to get access to their clients’ data. With this new initiative, and with implementations gaining momentum by request from corporate clients, this could accelerate true innovation in the Travel sector as startups wouldn’t have to spend time and funding to get access to a multitude of “old” players API’s to get client data.”

Conclusion

At TravelScrum, we thoroughly discussed this mechanism. We identified the pros and the cons, the technology, the hosting, the encryption/security mechanism, and the commercial models required for implementation.

As a byproduct of this mechanism, while a centralized entity is not needed to hold your data, this is also not excluded. For example, one or more trusted repositories of your information could carry multiple profiles (e.g., business, leisure, family, etc.) to which only you have the keys. At the beginning of the booking process, for example when you book your flight, you could just pass your key from any repositories, thereby enabling access to basic profile data (e.g., first, last name, home address, passport info, etc.)

In the end, clear benefits exist for both the participating entities and the travelers/guests for adopting this mechanism. But a practical working proof of value is still needed. We welcome companies to explore potential implementation and would provide support where required. The journey for TDX has just started, and it will be the topic of upcoming hackathons, industry debates, and further TS/P2 think tank deep dives where TravelScrum and AWS will be available to help.

As Christoph Mueller, a seasoned senior airline executive points out,

“The end consumers will come out of the COVID crisis digitally savvier across all customer segments. All touchpoints (Customer Engagements) across the added value chain (flight, hotel, car hire, etc.) will be judged on ease of use, protection of personal data, and integration. As credit card companies have agreed on a 16-digit code, telecommunication companies are connected by well-defined protocols, etc., travel needs to evolve toward that standardization. Players in the digital travel arena must achieve exactly that: a decentralization, peer-to-peer, controlled, incremental, and schema-less data interchange system. Customers will be merciless to non-adopters: this is an entry ticket to what’s next in travel, not an option.”

The industry is still recovering from COVID, and enormous challenges remain ahead of us. Still, technology is an enabler and a way to innovate and reinvent how businesses run. If you want to be part of the conversation, then reach out to us and we will be happy to provide all the support you need.

Travel and hospitality companies are building what’s next, and AWS is how. Check aws.com/travel.