Accelerating TMC Adoption

#1 - Missing data from airlines for downline processes (e.g. tax breakdown, reference to original order in servicing scenarios)

The issue

The following data is inconsistently provided by airlines:

• Reference to the original order when changes result in an exchanged ticket
• Tax breakdown by passenger type in refund scenarios

Accelerator because:

Downstream processes are not served e.g. impact on BSP reconciliation; tax breakdown on invoice

The solution depends on

Implementation

Airlines providing the data consistently in the OrderViewRS back to the TMC.

TMCs processing OrderViewRS information to feed downline processes.
Click here to view an example OrderViewRS XML illustrating the data expected by TMCs.

Standard documentation

A use case that demonstrates the value of providing these data elements.

The 2020 action

• Airline action - return the data required in this accelerator
• TMC action - work with MBO and OBT partners to integrate new data elements

#2 - TMCs are receiving offer conditions and offer descriptions in different ways or not at all
Last updated on: 03 February 2023

The issue

The following are issues with the way airlines are returning description of their offers:

• Airlines not providing information on corporate discounts and other valuable information such as loyalty benefits, payment benefits etc. that could unlock new volumes and help the TMC demonstrate savings to the corporate.
• Inconsistent way of communicating the fare rules - and it is often in free text.
• Not all airlines believe the advance purchase, min/max stay and combinability rules are necessary in the NDC context and therefore it is not being returned in shopping flows.

Accelerator because:

There is significant impact to volume generation for TMCs that need stronger justification in support of implementing NDC.

The solution depends on

Implementation

Airlines to return offers that demonstrate value to the TMC and corporate.

Airlines to return offer conditions in machine readable format (available as of v19.2) for streamlining processes at the TMC, including airline offers that are constructed dynamically.

     - Capability: https://guides.developer.iata.org/v213/docs/capshp02-offer-conditions-and-restrictions

     - Concept: https://guides.developer.iata.org/v213/docs/offer-and-order-restrictions

Airlines to return offers that reflect combinability conditions and conditions for ancillaries, not just the flight. For Offer conditions relating to ancillaries, the group recommends using one OfferItem per ancillary. (There are on-going discussions on the topic of product-led shopping which could address these points which could be reprioritized for inclusion to the 21.1 release).

Click here to view an example OrderViewRS XML illustrating how Offer conditions could be structured.

Standard documentation

Clear guidelines on when airlines should provide the offer conditions. For the moment, implementations should take into account the flexibility in when offer rules and other details are returned and systems should be designed to expect this information to be provided at any step of the shopping flow in any of the following messages: AirShoppingRS, ServiceListRS, SeatAvailabilityRS or OfferPriceRS.

Changes are being discussed in the working groups to add, in a machine-readable format, which messages contain extra information about offers, including offer rules. This means that the seller system could be instructed in the AirShoppingRS, where offer rules may not have been returned, which message contains extra information so that the system can, via subsequent API calls, complement any missing information on their system.

Mindset shift opportunities

For airlines, to be mindful of the TMC context and provide the full details to help them serve their clients.

For TMCs to set new expectations and appreciate that, for example, the min/max, advance purchase logic does not apply in many NDC airline flows.

The 2020 action

• Airline action – return the data required in this accelerator
• TMC action – help travel consultants to set new expectations
• Assessment undergoing with Offers Group for conditions relating to advertisement in Canada.

Additional Material

Related Guidance on ARM Index:

• Shop: Offer Restrictions [SHPOR2]

#3 - Varied implementation of Price Guarantee time limits by airlines impacts approval processes
Last updated on: 03 February 2023

The issue

Not all airlines implement the price guarantee time limit (PGTL). And for those who do, the meaning of the PGTL is not consistent or the next steps to manage the order is not consistently implemented.

• Example, some airlines guarantee the fare only, some guarantee the fare + taxes
• If PGTL is not populated, in practice, TMCs are forced to use instant ticketing. For long hauls (higher prices) instant ticketing poses a challenge because of TMC approval processes.

Accelerator because:

There is significant impact to volume generation for TMCs that need stronger justification in support of implementing NDC.

The solution depends on

Implementation

Airlines who implement PGTL, to know that TMCs would like the guarantee on the total amount, not just the base fare.

Price Guarantee is optional and an airline may choose to implement the offer time limit and payment time limits and not the PGTL. TMCs to build implementations to cover this difference.

Airlines to make clear what element of the price they are guaranteeing up-front (e.g. base fare, tax or both).

API consumers to implement logic to handle different implementations of time limits (as per above, base fare, tax or both).

Standard documentation

Implementation Guide around Time Limits will be followed, however SWAT has recommended changes to make it clearer on how to interpret the absence of PaymentTimeLimit in a message (this has been sent to Offers Group to discuss).

Current implementation guidance is here. To see how repricing of an Order can be used in conjunction with this time limit, see section 3.5.4.12 "Order Repricing when Price Guarantee Time Limit has been exceeded, after Order has been created" in the 17.2 Implementation Guide.

#4 - Inability to service an order when a TMC is supported by multiple NDC API users
Last updated on: 28 August 2020

The issue

TMCs would like airlines to accept their request to service an order in the following use cases which match the setup of the TMC operations:

• TMC uses one IATA# to make the initial booking (order) and another IATA# to service the same order [e.g. robotics, offline …]
• The TMC be able to service the order using multiple seller platforms or tools [e.g. OBT, aggregator, robotics…]

Requirements

To allow the same Seller (with unique IATA Agent ID) to access/manage their orders via different integration channels.

TMCs employ multiple OBTs to shop, create and manage Orders. Limitations in many Airlines’ API and OMS platforms today restrict TMCs’ ability to access their Orders via different integration channels.

TMCs would like airlines to accept their request to service an order using multiple seller platforms or tools [e.g. OBT, aggregator, robotics…].

Accelerator because:

Downstream processes aren’t served

The solution depends on

Standard

Clarity on what the standard supports to identify API consumers so TMCs and airlines can streamline their implementations to match these requirements.

Implementation

There are different security models being implemented by airlines.

Implementations to align to the conclusions coming out of the broader issues of API delegation in NDC.

For a more detailed description of the problem area and solution, see Managing API and Order Permissions below.

The 2020 action

• Identify use cases in scope and propose solution with SWAT participants and other interested parties.
• Ongoing discussions with SWAT group to assess priorities related to federation of permissions - focusing on how Sellers or other parties (with different identifiers) can access and service the same NDC Orders in a controlled manner.

---

Managing API and Order Permissions

The aim of this section is to provide advice as to how permissions could be managed at the API and OMS level. The content below will focus on one of the main issues raised by TMCs

Assumptions

• Order creation can take place on any OBT
• Orders can be serviced on any OBT (depending on capability)
• Agents may create and service orders directly via a travel portal or via the airline website but still need to access all bookings via their tool and have a single place to view and find them
• Large TMCs can support many OBTs each of whom will make their own aggregator decisions

Solution

• Airline NDC APIs to expand their channels of API consumers - move towards open on-boarding mindset
• Airline is in control of managing permissions on two levels - authentication (API) and authorization (OMS)
• API - two IDs to verify: API keys issued to API consumers (part of on-boarding / technical set-up) and Agent ID (e-signed RQ payload and/or chain-of-trust if through aggregator)
• OMS - each API integration could cater to multiple Agent IDs. Authorization should be done at Agent ID level and managed by the OMS, regardless of which integration channel the request came through
• NDC Party Structure (currently under revision)
• If sender (Seller) already knows which aggregator they are relaying the message through, they should include this in the Participants portion of the Party structure
• Aggregators (and any integration parties involved in relaying and routing of messages) append their identifiers, if missing from the Participants section. These may not all be known for the sender or the recipient

---

Additional Material

Related Guidance on ARM Index:

• Setup: Order-Level Permissions Management [STPOPM]

#5 - Existing queue capabilities and processes depending on passives need to be rebuilt
Last updated on: 26 November 2020

The issue

This is both a commercial and operational accelerator.

It is largely around TMCs needing to put alternative solutions in place for airlines that don't support passives.

Processes triggered from queues that work from passives make this an adoption blocker if no alternative in place.

It is noted that a queuing process for events such as schedule change, cancellation are still relevant in NDC.

Accelerator because:

Downstream processes are not served when an alternative to passives is not in place. These include quality checks, integration with duty of care systems etc. that are built around passives.

The solution depends on

Implementation

TMCs need to build out alternate solutions to address the functionality that passives support in lieu of airlines and GDSs not supporting passives.

#6 - Lack of automated involuntary servicing processes implemented by airlines
Last update on 03 February 2023

The issue

The implementation of Order Change Notification differs from airline to airline.

Voluntary changes after an involuntary change (disruption):

• Not all airlines automatically take into account the context of a voluntary changes after an involuntary change (disruption).
• Some airlines implement waiver codes which prevents automation using the API. This requires manual input from TMCs, OBTs don’t always support input of these codes and it prevents online self-service by the customer
• Disrupted services are not always communicated to TMCs in involuntary scenarios (e.g. if a paid meal or seat is no longer available)

Most airline sandboxes don't support disruption scenarios. This means TMCs cannot test their involuntary end to end flows with their NDC airline partner.

Accelerator because:

Downstream processes are not served and impact to volume

The solution depends on

Implementation

Implementing OrderChangeNotification and dealing with voluntary changes after an involuntary change:

• The OCN is the mechanism to communicate the disruption to sellers. Airlines send the OCN to the endpoint of the TMCs who are expected to setup endpoints to receive the OrderChangeNotification in NDC. (note: as of 19.2, the standard streamlines this capability).
• Since airline products differ, the impact of disrupted services and the resulting follow up actions may differ. Airlines to clearly communicate the impact of the disrupted services to the TMC, including any cascading effects of services depending on other services.
• After a disruption, airlines take into account the context of the disruption when responding to a Reshop request and return offers in accordance to the eligibility of the airline’s disruption policy (e.g. not charging penalty fee or fare difference). Airlines acknowledge that waiver codes do not support automation and take this into account in their implementation.
• Due to the frequent occurrence of timing changes in flights, TMCs urge airlines to support these scenarios in their API with priority.

Involuntary servicing in Airline sandboxes

• Airline sandboxes to include the disruption scenarios supported in their NDC API, including during agent onboarding.

Additional Note and next steps

• As of 19.2, the standard has functionality to optimize the information that the TMCs need when receiving the notification from the airline (follow up action, standardized reason codes etc.)
• Airlines and TMCs to become familiar with the features introduced into 19.2 to enhance servicing processes.
• SWAT input to the working group for the implementation guide to describe how the associated disrupted services are to be represented in the order of a new itinerary (e.g. a service transferred to a new itinerary).
• Relevant resources
  • "Reshop following a Planned Schedule Change", page 269 of the 19.2 Implementation Guide
  • "Structure of the Order change notification", page 113 of the 19.2 Implementation Guide
  • NDC InFocus on Servicing in NDC and the associated webinar.

Additional Material

Related Guidance on ARM Index:

• Order: Notification with Advanced Features [ORDOC2]
• Setup: Notif Message Setup [STPNTF]

#7 - OrderHistory not implemented by airlines
Last update on 03 February 2023

The issue

Airlines have not implemented Order History. OrderHistory is the NDC message that agent systems use to get visibility of all changes made to the order. The impact of this is that

• TMCs may not have visibility of passenger changes made directly with the airline.
• If, for technical reasons, a notification was not communicated to the TMC, the Order History is the mechanism to ‘catchup’ on changes missed.

Accelerator because:

Downstream processes are not served if this data is missing in the TMC systems.

The solution depends on

Implementation

Airlines, Aggregators, TMCs to implement OrderHistory

As of 19.2, the standard has enhancements to streamline the OrderHistory capabilities, including a new version number element. This helps the TMC know if it missed an update.

Updated Implementation Guidance on OrderHistory will be released by Q2 of 2023

The 2020 action

Increase awareness of the advantages to the airline of implementing OrderHistory.

Additional Material

Related Guidance on ARM Index:

• Order: Historical Information on Orders [ORDHIS]

#8 - Refund processing is not streamlined across the value chain, preventing downstream automation
Last update on 03 February 2023

The issue

• Airlines solutions for voluntary changes vary and scenarios are not always supported in the API, requiring TMCs to use airline portals and phones. This is inefficient for TMC operations.
• There is missing Order data returned to the TMC in the refund process. This includes:
  • Accountable document status
  • Document data such as taxes, fees, penalty amount
  • Tax breakdown by passenger type

For example, when a customer no-shows and is eligible for a refund: Travel consultants and/or robotics currently use the document status and ticket validity to check for potential / outstanding refunds.

Note: TMCs also use the document status for duty of care purposes.

Accelerator because:

Downstream processes are not served if this data is missing in the TMC systems.

The solution depends on

Implementation

Airlines are to implement refund scenarios in the API as per the implementation guidance and to support common scenarios, such as the following:

• Refunds for partially flown segments
• Refunds that include ancillaries

Airlines to return the order validity period and the coupon / service delivery status to the TMC as this is used to anticipate the expiry of the order to carry out its refund request processes. Airlines and TMCs prepare to return and consume respectively, order-based data elements.

Airlines use the OrderChangeNotif message to communicate any changes in the status of the delivery of a service or coupon (which could potentially trigger a refund), as well as any changes in the refundability validity period to the Seller. Similarly, the airline returns this information in an OrderViewRS, should a Seller retrieve an Order.

Related sections of the implementation guide to support this accelerator

• "Voluntary Servicing for full cancellation, partial cancellation and order modification", page 76 of the 19.2 Implementation Guide
• "Change of Itinerary", page 207 of the 19.2 Implementation Guide

Implementation details and XPaths may be found here.

#9 - Need for streamlined implementation processes when TMC requests multiple changes to an Order on the same day (exchange/void) scenario
Last updated on: 2021-03-25

The issue

In scenarios where multiple changes are made on the same day agents need to be informed of the statuses of legacy documents so they can report these correctly. This becomes more important for airlines that support voiding of exchanged tickets.

Use Case: Order is exchanged a few days after being created (change of flight) [Step 1] and then Cancels the order on the same day [Step 2]. Where the airline voids the exchange as the cancellation is done on the same day agents need to be notified.

With NDC, when a TMC requests multiple changes on the same day:

• TMCs would like to receive the details (coupon status, correct amounts etc.) of the documents that have been impacted by the cancellation.
• This is to properly report to the Mid Back Office of seller to match against BSP data

Accelerator because:

Downstream processes are not served if this data is missing in the TMC systems.

The solution depends on

Implementation

The solutions assumes that the Seller system is capable of storing and managing the Orders they receive from Airlines. Please see the TMC Reference Architecture for more information

Click here to view a set of sample XML messages illustrating the solution, for airlines that support the scenario

Standard documentation

A clarification request is in progress for the case where TMCs may not be able to store the history of orders and tickets