This feature is only available for clients
For more information on how to enable this feature in the backend of your TripBuilder, please contact your account manager or Support Team.
How to Modify an Itinerary
Post-booking changes are made via the Nezasa Cockpit in Customer Care and can only be applied to confirmed itineraries.
The following instruction will give you a detailed overview of how to change an existing booking.
Steps to Modify an Itinerary
- Open the respective itinerary in the cockpit, under customer care
- Click on Initiate Booking Change under the Action button
- The itinerary is set to Change Initiated status
- The link to modify the itinerary on the planner is displayed in the Open Booking Change section
- A toggle next to Itinerary allows you to switch between the Original and Alternative view of the itinerary
- Click on the link to Modify the Itinerary on the Planner
- The itinerary will be opened in the planner
- Possible adjustments/changes can be made to:
- Rental Car
** Number of PAX changes are not allowed.
Changes to booked accommodation, activities and rental cars will trigger a cancellation of the original component and will require a new booking of the newly selected component.
- When adjustments have been made in the planner, the user clicks on the button Continue in Cockpit
- The itinerary will be displayed in the Customer Care
- Click on Complete Booking Change under the Actions button
You may click on Discard Booking change to return to the original itinerary.
- Pop-up Complete Booking Changes will be displayed.
- Users can choose from the following options:
- Set a processing fee per pax or in total
- With fee
- Without fee
- Keep original sales price
- Apply a total discount
- The itinerary is set to Change in progress status
- An overview with booking updates will be displayed
- Booking change is completed
After the booking changes have been made, the data of the itinerary will be updated accordingly including the travel documentation.
This section describes the technical details of the entities involved in booking changes.
Itineraries and Checkouts
There are two entities involved in any type of bookings: Itineraries and checkouts.
Itineraries represent the trip itself with its structure, components and pax while checkout represents the process of performing a booking (or booking change or cancellation). On a business level, the identifier for the customer is the refId, which is generated at the time the itinerary is created (template instantiation). As soon as the user clicks on "Checkout" (on planner), we create a checkout and re-use the refId from the itinerary.
This ensures a consistent experience for the user: There is one identifier referring to their booking.
Initially, the checkout does not contain a lot of information other than a link to the itinerary, a state (BookingInitiated, also see Itinerary Status) and some company information. As soon as the user performs the booking, the components in the itinerary are updated and the checkout is set to BookingCompleted (there are some intermediate states). An important detail here is that the state of the checkout is propagated to the itinerary. Therefore, after a successful booking, the itinerary is in the state BookingCompleted as well.
Starting from a completed booking, a user can initiate a booking change. In the background, this creates a clone of the checkout as well as the itinerary. The new checkout will now be in state BookingChangeInitiated and its attribute current Alternative points to the cloned itinerary. The cloned itinerary is in the state Alternative.
What happened to the refIds?
Let's look at the checkouts first: We now have two checkouts.
One is in state BookingCompleted and another one in BookingChangeInitiated, however, both of them share the same refId, because for the customer, it shall still be one booking. The itineraries, on the other hand, do not share refIds. Instead, the original (the one that is currently in state BookingCompleted) still has the same refId as the checkouts while the cloned alternative has a new generated refId.
The Alternative Becomes the Primary Itinerary
With this cloned itinerary, the user can now again open the planner and do some modifications. Once all changes are done, the user can click on Back to Cockpit. When completing the booking change, this is what happens in the background:
Nezasa creates a difference of the original and the cloned itinerary
the new components are booked
the old components are cancelled
The cloned itinerary replaces the original on the checkout
set the itineraryId to the cloned one
the currentAlternative attribute is set to None
the cloned itinerary changes its refId to the original one
the original itinerary gets a new refId
The checkout state is set to BookingChangeCompleted
the cloned itinerary is set to BookingChangeCompleted
the original itinerary is set to status Superseded
So after all these changes, the new checkout points to the new primary itinerary by _id with the attribute itineraryId.