& Digital Experience
Travel booking journeys: monitoring the experience across services
Booking a trip on a smartphone can feel like a single interaction with a travel provider. Behind the interface, however, the task may involve several applications and services. A traveller selects dates, checks availability, signs in, reviews a price, and proceeds to payment. At each transition, the information needed to continue must remain available and consistent with the traveller's choices.
As holiday travel approaches, these connections deserve attention.
Can the traveller continue when the booking moves between interfaces?
Do the selected details carry through as expected?
Does the confirmation clearly communicate the result?
These questions reflect current industry discussions. Ahead of its World Financial and Passenger Symposiums, held on 28–29 October 2026, IATA highlighted connected digital journeys, payment modernisation, and the implementation of modern airline retailing.
Its discussion emphasises coordination across airlines, travel sellers, and technology providers. For digital-service teams, the operational question is how to observe the experience delivered across those connections.
Read IATA's discussion on the vision and implementation of modern airline retailing .
Follow the task and its data across services
A handoff in a digital travel journey occurs when one application or service passes a task, along with the information needed to continue it, to another application or service. Examples include a mobile app opening an embedded booking page supplied by another service or directing the traveller to payment authentication.
Other steps rely on background data exchanges, such as retrieving loyalty benefits, without transferring the task itself. Across both types of interaction, monitoring teams need to establish whether the traveller can continue with the expected information.
The architecture varies by provider. Consider an illustrative journey in which someone selects accommodation in a mobile app and continues to a booking page. Checking that the page opens provides useful evidence. Checking that it displays the selected property, dates, and number of guests provides a more meaningful view of the transition.
A technically successful response can still leave someone unable to complete the booking.
The next screen might appear without the selection, require information to be entered again, or display an unexpected result.
Digital experience monitoring (DEM) examines application availability, performance, and experience from the user's perspective. For a travel booking, this means checking whether selected steps work and deliver the expected information.
The following approach connects those observations with the task the traveller wants to complete.
Start with a small number of important booking journeys and define their boundaries. For each one, specify where the check begins, what it attempts, which values it compares, and what constitutes completion.
The following sections explain how to check data consistency, choose representative mobile conditions, establish what booking confirmation proves, and use failures to guide investigation.
Check data consistency throughout the booking journey
Data consistency means that information remains aligned between steps and across the sources involved in a journey. Alongside response times and errors, teams can check that selected details carry through as expected.
These checks serve three purposes: to verify that information is preserved, to assess values against a rule or reference, and to compare what an interface displays with another accessible source. In a controlled booking scenario, checks could establish whether:
Selected dates and traveller counts carry into the booking summary.
The displayed total reflects the selected options and applicable pricing rules.
Information returned by an accessible API agrees with the corresponding interface.
Confirmation details match the expected result of the configured test.
Where access and validation mechanisms allow, synthetic monitoring can compare displayed information, API responses, and documents with defined expectations. These data consistency checks across the user journey help establish whether each step delivers the expected information, beyond simply displaying a screen.
Agreement alone does not establish correctness: two interfaces may display the same incorrect value.
Dynamic prices may legitimately change, and additional options can alter a total. The task is to determine which values should remain stable, which may change, and what rules define an acceptable result.
The people who understand the booking process need to help define those rules. Their knowledge turns a sequence of automated actions into a meaningful service check.
Choose the mobile conditions that each test represents
On mobile, a booking journey takes place within a particular device and application environment. It may combine native screens with web content, while authentication introduces another transition.
A synthetic scenario executes a predefined sequence of actions and checks the results. On a configured mobile device, it can test whether selected steps produce the expected response within an agreed time.
Teams should choose and record the conditions represented by each test: application version, device, network, authentication method, and path through the journey. A successful run provides evidence about that configured journey under those conditions. Coverage across other environments requires further checks or other relevant evidence.
Define what booking confirmation proves
Booking confirmation needs an explicit success criterion. The presence of a confirmation screen establishes less than a verification of its content against the expected booking details.
Interface confirmation
Verify that the interface displays an expected reference and booking summary.
Reservation status
Verify that the reservation was correctly recorded in another system through a check of that system or an appropriate response.
Payment settlement
Establish payment settlement using separate evidence.
A controlled check can verify that an interface displays an expected reference and booking summary. Establishing that the reservation was correctly recorded in another system requires a check of that system or an appropriate response from it. Payment settlement requires separate evidence.
The monitoring scope should therefore specify the result being verified. A journey that stops before payment answers a different question from one that creates an authorised test booking and checks its subsequent status. Each can be useful when its purpose is clear.
The goal is to create evidence that teams can interpret confidently, with each conclusion tied to an observation.
Use a failed step to guide investigation
When a monitored handoff fails, begin with a precise description of what was observed and how it differed from the expected result.
The booking page opened, but the expected dates were absent.
An authentication step completed, but the scenario did not reach the expected confirmation within the defined time.
For example, the booking page opened, but the expected dates were absent. Or an authentication step completed, but the scenario did not reach the expected confirmation within the defined time.
Screenshots, video recordings, timestamps, step timings, and comparisons of expected and observed values can help teams reproduce and examine the problem. Where accessible, API responses, application logs, and traces can add context about the services involved.
Screenshots and video recordings.
Timestamps and step timings.
Expected versus observed values.
Accessible API responses, logs, and traces.
The failed step provides a starting point for investigation. An unexpected screen might reflect an application change, an unavailable dependency, an expired test account, or a restriction affecting monitoring traffic. Teams need to distinguish these possibilities before concluding that customers experienced the same failure.
Short disruptions can occur between scheduled checks. Consider check frequency alongside the importance of the task and the duration of the problems teams want to detect. Other available operational evidence can help investigate periods that the controlled checks did not capture.
A failed monitoring step is a starting point for investigation, not automatic proof that every customer experienced the same issue.
& Physical devices
Extend the approach to self-service travel
The same principles apply when travellers use a self-service terminal: check the task and the information presented during it. Device connectivity and a controlled interaction with the interface provide different observations.
For a ticketing kiosk, a scenario might, for example, check whether the selected ticket type, date, and passenger count appear as expected in the summary before confirmation. This applies the data-consistency principle to a different interface.
Ticketing kiosk
Verify that the selected ticket type, date, and passenger count appear as expected in the booking summary before confirmation.
Ticket validator
Present a ticket and observe the expected acceptance response through a controlled interaction.
At a ticket validator, the task is to present a ticket and observe the expected acceptance response. Synthetic monitoring on physical devices can check configured interactions and capture visual evidence of the result. The scope should distinguish an interface response from any physical outcome that needs separate verification, such as ticket printing or gate movement.
An interface response and a physical outcome require different evidence.
Discover how Ekara Pod supports synthetic monitoring on physical devices .
& Key takeaways
Conclusion: monitor the booking the traveller expects
A traveller needs to complete a booking with confidence that the details still reflect their choices. Following the task across services gives digital experience monitoring teams a practical way to examine that experience: identify the important handoffs, check the information carried between them, and define the evidence of completion. This connects technical observations with a recognisable customer task and gives teams a clearer basis for investigation when the journey delivers an unexpected result.
Monitor the complete booking journey, not just the availability of each individual service.