Offer and order management are crucial components in various industries, especially in sectors like airlines, retail, and e-commerce. What is lacking is any industry standard that defines how this should work across all travel sectors. There are siloed definitions such as for airlines, but even there, not an open standard (licensing fees and restrictions) . It would help conceptually to think of an offer as a container or shopping basket. Whether online or in a store you do not have multiple baskets based on the products you wish to buy. The shopping basket is agnostic to what the product is, the price and the terms and conditions (rules) of purchase. The product in the basket, say a toy, conveys its description, price and rules such as “not suitable for children under 4”. A retailer may bundle products into a single offer, again with descriptions, prices, and rules of the bundle.
Shortcut: If you want to skip the reading and join the workgroup, click here.
The next concept is offer management. Offer management in travel retail involves creating and managing personalized offers for customers. This can include flight tickets, hotel bookings, car rentals, and other travel-related services. The goal is to tailor these offers to meet the specific needs and preferences of individual travelers. For example, airlines can use offer management systems to provide customized airfares, seat upgrades, and additional services like extra baggage or in-flight meals. All should be delivered in the same shopping basket. Another way to think of this is an offer of offers. Like the retail bundle, an overall description, price and rules of the bundle for this basket of individual offers.
Order management in travel retail encompasses the entire process of tracking and fulfilling customer orders. This includes everything from booking confirmations to managing changes and cancellations. Effective order management systems ensure that all stakeholders, including customers, travel agents, and service providers, have real-time visibility into the order status. This helps in reducing errors, improving customer satisfaction, and streamlining operations.
It is vitally important that the data structures and behaviors is universally consistent for any travel industry order management solution to work with the above examples of bundles of products in the offer. For OpenTravel, the definition of offer and order are largely the same. An offer becomes an order upon payment. This is the norm across other industries. Making travel retail more “normal” would have large ramifications to costs and capabilities of order management solutions if they can reuse what is already out there by major vendors with few modifications.
Some informational links from Salesforce, Sabre and IBM. Two are about order management for everyone else, one for the airline approach. The airline proposal unfortunately attempts to be backward compatible with legacy PNRs which makes it unsuitable for non-air use. An explanation for a future post.
Continuing with the analogy an offer is a container, shopping cart, it needs some basic data definitions. How one describes the product, the price and the rules. A fair amount of this is already defined in the OpenTravel 2.0 model. Some additions for rules encoding still needs to be done. This structure is agnostic to all three factors. Makes no difference if we are talking about a seat (air or rail), a room, a berth, a car, a meal, flowers, insurance, etc.. Each of these areas is a domain (name space) with some additional elements as needed but let’s not get into the weeds. What remains to be done is to define the minimal behaviors to be called an OpenTravel offer. Most are obvious, an offer container (object) must be able to tell you, when asked (API), what is the product description and attributes, the price and the rules. Other API features like you what are next possible actions to take, how a call back (like to get rule detail) works, instrumentation (billing and error determination) and other behaviors that get into the weeds. Certainly would need to define how security works, how distributed identity works so all keep clear of GDPR issues.
All this would be defined through work groups linked to OpenTravel which would depend on participation of the community including vendors, various travel standards bodies and trade associations. The results published with an unrestricted open use license, as OpenTravel messages and models are released today.
The messages, models, and documentation described about would be handled as open source, but most think of the term open source relating to software. The effort would include open source software as well. The OpenTravel 2.0 models are already used for code gen. We would expand on that and publish reference implementations of all commonly used travel retail APIs including those for offer and order. It’s one thing to document how an API callback is supposed to be done, it’s much better to just provide a working example. How far we go with this is up to the community but a goal would be 80 to 90% of travel retail functions would have an open use reference implementation to copy from.
The business case for using an opensource approach in cooperation with product and service providers has been proven over and over again. Currently hundreds of companies providing travel products (suppliers) and travel retail distributors (GDS, channels, aggregators, TMCs, etc.) are individually creating, delivering and maintaining similar but bespoke APIs. Some may be hosted by service providers that handle API delivery but that may be constraining their API options. Accept the retail options of others or fund bespoke additional capabilities. API consumers face a labor consuming nightmare if they want to bring a variety of travel content to market. APIs that do the same thing are still fundamentally different requiring custom code. Opensource has dealt with these same issues in other industries and technologies.
Custom code for API consumers would be reduced or eliminated as data, API structure, and behaviors would be consistent and documented in machine readable format. This would enable increasingly (AI) automated tooling to handle the job of API consumption. Code for API providers (suppliers) would greatly reduce as our target would be 80% or more of API models and code would be opensource. Private extensions would happen in the OTA 2.0 model which would create the code and documentation needed. Hence a large cost avoidance business case.
Net new revenue is possible as more and better travel content (products and services) can come to market as cost barriers come down. A large opportunity for all travel retail channels. Businesses doing message normalization today would move to offer normalization and potentially offer management. This approach also facilitates omni channel personalization. This would allow suppliers to move away from legacy loyalty programs to high levels of automated (AI) personalized offers wherever they market their products.
Just like in other opensource efforts, the main impact is a lot less funding wasted on highly redundant IT expenses freeing up capital to provide better products and services with better margins. Let’s not forget the traveler who now can be provided highly customized travel experiences where all the coordination between products and services can be automated due to the consistency and interoperability of the underlying APIs.
OpenTravel is organizing a workgroup to define the scope of an open definition of offer/order that works across the travel industry that facilitates all the goals mentioned above. This is a first step to document what are the attributes needed for a common use, open, offer and order. The discussion will tackle issues such as priorities and how to show some benefit to the community quickly. Other workgroups may be spawned quickly for known issues like rule encoding (several known solutions, pick one), or to hammer out security and identity management (work by other groups on this in progress).
If you our your organization wants to be involved, please fill out this form. We particularly could use participation from vendors of current order management solutions. As stated we would like this to be compatible with currently offered order management solutions. Let’s not reinvent the wheel if we can avoid it.