Overview

During planning, booking and even when conducting post-booking changes, there's always a status associated with an itinerary.

Article Itinerary Status in Customer Care comprehensively explains the available itinerary status and the rationale behind each classification.

Particularly, the Booking in Progress and Booking Change in Progress states can be defined as "The booking has started and is currently in progress. This is an intermediate technical state during the booking, which means we're currently booking the components in external systems, and nobody must make changes to this checkout at this time.". The difference between both states is having the first booking (Booking in Progress) or applying a Booking Change to a previous Booking (Booking Change in Progress).

As both itinerary states relate to actions on external systems, unexpected behaviour from a supplier system may result in an edge case where the itinerary status isn't updated accordingly.

Previously, in this scenario, the itinerary would become "stuck" as no actions were available to the user and a support ticket needed to be raised to Nezasa.

Know more: Please check the article How to manage component confirmation failures during booking? for an explanation of how TripBuilder manages booking failures. Watch the Product Spotlight Webinar about Booking Rescue Tools here.

 

Please note: An itinerary is considered "stuck" in the state Booking in Progress or Booking Change in Progress, after reaching the time threshold of ten minutes. This is enough time for a booking process to complete and exceeding it's a clear indicator that something went wrong and it isn't possible to recover from it automatically. While the value of 10 minutes is recommended by Nezasa, a different value can be set by a customer request to Nezasa.

 

This article explains how users can get themselves out of a "stuck" booking (including booking changes) by resetting it and applying follow-up measures.

 

How to retry a failed booking

Important: It's possible to reset an initial booking before being able to retry a failed booking. This process follows the same structure as the retry booking change process, which is detailed in the next section of this article, How to reset a booking change.

 

In Customer Care, an itinerary displays the Manual Processing status when a booking request has been performed, but the booking hasn't yet been fully confirmed on the supplier side. An example of this would be if some components failed to book in an external system, so now the booking must be completed manually.

To retry the booking request, click the Actions button on the right side of the page and choose the Retry Failed Bookings option. A pop-up is displayed to confirm the action.

When you click the Confirm button, TripBuilder attempts to create a new booking for each component that previously failed to book. This retry flow, doesn't affect components that were booked successfully on the previous attempt, as no action is required for them.

If every component is booked successfully during the retry flow, the itinerary status then updates to Booking Completed.

 

If the Retry Failed Bookings action fails and is still unable to confirm the non-booked components, you can still use the available actions to complete the booking manually, perform a booking change or cancel the booking.

Please note: As with any failed bookings, it’s important to check manually if the component has been confirmed with the supplier before attempting the Retry Failed Bookings action. This will help to avoid booking duplication. The Booking History tab can also be useful for checking the booking status in TripBuilder.

 

How to reset a booking change

In Customer Care, an itinerary is identified as "stuck" when it presents Change in Progress as the itinerary status and significant time has passed (i.e. over 10 minutes).

By clicking on Services & Price List, inspect the different components in the itinerary and their individual status (for example, Booked versus Cancelled).

After analysing the status of the itinerary components and conducting all required follow-up actions, if you intend to go forward with the itinerary "reset", go to the Actions menu at the top right of the screen and click on the Reset Booking confirmation option.

A confirmation popup is presented to the user, explaining the operation.

When confirming the action, the user is taken back to the change-initiated state, being able to review the original and the alternative itinerary versions.

At this stage, depending on the type of error and components that succeed/failed booking, two options can be made available to the user:

Use Case	Actions Available	Operation Results
All components on the alternative itinerary are booked	Retry	As on the original booking, the Retry attempts to re-book all the non-booked components. If successful, the itinerary is moved to a “booking change completed” state.
Not all components on the alternative are booked	Discard or Retry	A user can “Discard” the alternative version. Once discarded, the user returns to the original itinerary, where they may cancel or initiate a new booking change.

 

Important: It's essential that the customer care user checks the statuses of the components with the external supplier offline, so they know exactly what happened on the supplier side on a booking/booking change where a failure has occurred. Due to a potential mismatch between the components booked/cancelled in the itinerary and the booking information present at each supplier system, consider the Booking History feature that provides further insights into the interactions with supplier systems and information that may support an offline follow-up. Failure to ensure a manual check of your components might lead to double bookings or cancelled bookings being undetected. If the customer has no external link to the supplier, a helpdesk ticket to Nezasa should be created, asking for the booking status of the components they attempted to book or cancel on the booking change.

 

"All components on the alternative itinerary are booked" Use Case

The example below describes the steps to understand the use case and apply a Retry action to the itinerary.

1. We can confirm that although the itinerary booking didn't go through, all three accommodations bookings were successful. You can accomplish this either by:

a. At the Itinerary detail page, click on Booking History under the Behind the Scenes menu.

Analysing the Booking Entries table, we can confirm the following:

• three bookings were Requested
• three bookings were Completed successfully
• Each of the three successful completions has an Ext. Booking ID returned from the supplier platform.

Know more: Please check the article Booking History for a complete explanation of this feature.

 

b. Alternatively, the user can check the individual state of each component booking in the "Services & Price List" (in this example for Accommodations) having the Alternative itinerary previously selected.

2. Return to the Original itinerary by clicking on the Original/Alternative toggle at the top left of the screen.

3. In the "Actions" menu in the top right of the screen, click on Retry Booking Change

4. The popup Complete Booking Changes is presented, highlighting:

• Potential cancellation costs
• Cost of the actual bookings

5. Select if a processing fee shall be applied to the itinerary. If so, define how this should be defined (i.e. absolute versus per PAX).

6. Click OK.

7. At this stage, the itinerary state changes to Change in Progress while cancellations and bookings are executed in the background.

8. After a few seconds and considering actions were successful, the itinerary state changes to Change Completed. At this stage, the alternate itinerary is committed and the actions Print Documentation, Cancel Booking and Initiate Booking Change are made available in the Actions menu.

9. The user can confirm that operations went well by repeating the validation steps 1a and 1b.

 

"Not all components on the alternative itinerary are booked" Use Case

The example below describes the steps to understand the use case and apply a Discard Booking Action action to the itinerary.

1. We can confirm that the itinerary booking didn't go through, and one of the three accommodations bookings was unsuccessful. You can accomplish this either by:

a. Having the itinerary selected, on the Itinerary detail page, click on Booking History under the Behind the Scenes menu (similar to item 1 in the previous use case), or,

b. Comparing the Services & Price List for the Original and Alternative itineraries, we can see that one of the accommodations in the Alternative has failed to book and is with status Available. Also, no Supplier ID for the accommodation is available in the Supplier column. This represents a booking error in the Alternative itinerary.

Original itinerary

Alternative itinerary

2. In the Actions menu in the top right of the screen, two options are available for this use case: Retry Booking Change (equivalent to the use case explained in the previous section) and Discard Booking Change.

3. Clicking on the Discard Booking Change for the Alternative itinerary will present a confirmation modal. Here, besides the Cancel and Confirm actions, it is highlighted the potential impact on going forward with the Discard action.

4. By selecting the Confirm action:

• the Original itinerary is kept with the initially selected services and their underlying booking status.
• the itinerary changes its state to Confirmed by Supplier (as in this example all components - in the Original itinerary - were already confirmed).

5. At this stage, the actions Print Documentation, Cancel Booking and Initiate Booking Change are made available in the Actions menu.

 

Important: When Discarding a Booking Change, either partial/entirely successful (e.g. booked), the agent is responsible for the offline follow-up actions to guarantee reservation consistency between TripBuilder and the suppliers' systems.