A Tour Operator’s Travel Catalogue with Variable Geometry

Adaptive travel itineraries use planned alternatives, booking tools and professional assistance to accommodate disruption and changing preferences while preserving the journey’s core experience.

A trip booked six months in advance begins with a forecast. Flights, hotels, transfers and visits form a sequence that anticipates what will happen much later.

Meanwhile, a route may be cancelled, a fire may make a region inaccessible, a strike may disrupt trains, or a geopolitical event may change access to a destination.

The variable may be personal: staying two extra days, adding an excursion or following an interest discovered along the way. A participant may fall ill, remain at the hotel while the group continues and rejoin it later.

Digital inventories, APIs, dynamic packaging and itinerary management platforms offer more sophisticated tools than a call to customer support. Some modify and recalculate bookings; others update the programme and communicate it.

The catalogue thus takes on variable geometry, accommodating changes without losing its original promise.

Traditional planning follows a rigid sequence: A, B, C, D. Adaptive planning introduces alternatives: A leads to B1 or B2, then to C, while D can be reached through different routes and means of transport.

The Experience Builder must identify the journey’s underlying identity.

In rural Japan, communities, landscape, hot spring culture, craftsmanship and gastronomy might be essential; hotels, transfers or secondary stops might be replaceable.

An equivalence matrix emerges: some components are highly interchangeable, while the iconic experience or destination that motivates the purchase has less flexibility.

Modularity precedes the emergency.

Nezasa documents templates and modules in TripBuilder that can be used as interchangeable components in planning.

Dynamic packaging combines flights, hotels, car hire, activities and services in real time.

Nezasa TripBuilder allows complex itineraries to be designed using products from internal inventories or external suppliers, with live availability and prices.

Post-booking, however, requires a distinction: operators can modify certain attributes of accommodation, activities, transfers, basic services and car hire, keeping a record of the changes.

Substantial variations may require specific booking change processes.

Reconfiguration depends on integration between systems and suppliers’ conditions. A potential dynamic journey retains this capability even after purchase.

Flexibility has value when the customer understands its financial impact.

A change may involve fare differences, additional overnight stays, non-refundable excursions, transfers and penalties. The ideal system should aggregate these before confirmation.

In air travel, Duffel manages changes through APIs. In order change data, change_total_amount indicates the amount payable or refundable under the fare conditions; penalty_total_amount identifies the airline’s penalty.

For the customer, the sequence could be: request → simulation → cost → confirmation → new itinerary.

Behind it lie fares, availability, payments, contractual rules and suppliers.

In Juniper’s Hotel API, HotelModify checks whether a change is possible before applying it, returning any available combinations.

For an extended stay, the operator could compare the same hotel, another property, revised transport or rejoining the group at a later stop, with different costs and consequences.

Penalties remain a structural limitation.

Some changes require cancelling the previous booking line and creating a new one. Where cancellation charges apply, a direct modification may not be possible: cancellation, payment of the penalty and rebooking are required.

The flexibility promised depends on the flexibility negotiated within the supply chain.

Imagine an itinerary covering Tokyo, Kanazawa, Takayama and Kyoto. In Kanazawa, a participant falls ill and stays for two days while the group continues to Takayama.

Bookings are modified in their respective systems; management platforms then communicate the new configuration.

Travefy automatically updates the online version when the advisor makes changes; the customer sees them by reopening or refreshing the itinerary. Itinerary Views also allow events to be shown only to specific travellers.

The participant can receive information about the additional nights and the transfer needed to rejoin the others.

We might call the optimal place and time for rejoining the Rejoin Point: not an existing standard, but a planning criterion that considers the route, the individual’s location, transport, costs and booked services.

The air travel component remains delicate.

When a date, stop or reunion point changes, combinations, availability and fare conditions must be checked.

Skytool can help agencies compare alternative flights within the agent’s workflow. Acting quickly becomes part of experience continuity, especially when re-accommodation or different entry and exit points are needed.

Changes can be handled at different levels.

Activities, dinners and transfers lend themselves to self-service. Extensions, hotel changes or flight changes may require the operator; illness, evacuations and safety issues require professional assistance.

Automating repetitive operations leaves room for people when experience and decision-making skills are needed.

Travefy provides access to the itinerary through an app and, when the features are enabled, flight notifications and communication with the advisor.

Notifications cover cancellations, delays and gate changes.

Continuity comes from collaboration between automation and human assistance.

Integration suggests a component we might call a Change Engine.

A request could simultaneously trigger checks on availability, fares, cancellation policies, alternative inventories, suppliers, transport, the group programme and preferences.

The same infrastructure could manage a desired extension, a missed connection or an interruption due to health.

In the latter case, insurance could contribute to the calculation, alongside transport, accommodation and assistance, distinguishing reimbursements from costs borne by the customer.

Dynamic packaging, bookings, APIs, hotel platforms, insurance, payments and applications form an interconnected ecosystem.

This evolution could lead, as a design concept, to a Trip Operating System: an environment that keeps the itinerary up to date and coordinates changes when a variable changes.

For the Experience Builder, alongside price, duration and destination, the degree of modifiability emerges: replaceable components, deadlines, costs, customer autonomy and the ability to reconstruct the route.

Quality would also depend on absorbing change.

We can call it Experience Continuity: preserving value and coherence as conditions change. Greater freedom without abandoning the traveller to complexity, and tools to turn an unforeseen event or a desire into a new configuration.

The catalogue describes not only where we will go, but how much freedom we will have to decide how to continue.

Nezasa – TripBuilder: dynamic itineraries, live availability and post-booking changes.

Duffel – Order Changes: flight changes, fare differences and penalties.

Skytool – Official documentation on multi-source flight search and booking functionality through GDS, NDC and low-cost carriers.

Juniper – Hotel API: simulation of changes, available alternatives and management of cancellation fees.

Travefy – Itinerary Views: itinerary updates and differentiated programmes for individual travellers.

Unione Europea – Directive (EU) 2026/1024: traveller rights, cancellations, refunds and extraordinary circumstances.