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 word 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 it’s 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.
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.