The guest does not have to enter everything again
This example shows the module’s role in a hotel process. We define the source scope and available actions for each implementation.
Dates chosen during the conversation
In the chat, the guest provided the dates, number of guests and breakfast preference. A general link to the hotel website would force them to start the search again.
A specific booking journey
The integration checks the available options and prepares the relevant link or a partially completed form, if the engine supports this. The guest confirms the terms and finalises the booking in the system, which verifies availability again.
- Search parameters
- Available options from the relevant source
- Handover for finalisation
What does this module cover?
We agree which dates, options, stay restrictions and required data can be read. The integration may have different levels of scope: from a link with parameters to access to offers through an API. We do not present these options as technically identical.
Parameters from the conversation
Dates and number of guests are passed to the right booking step if the system supports this.
Offer from the source
AI does not calculate the price independently from an outdated marketing description.
Clear completion
The user knows that a link or suggestion is not yet a confirmed booking.
How do we launch the solution?
Checking the engine’s capabilities
We verify the available APIs, parameterised links and supported offer options.
Mapping requirements
We connect conversation data with stay parameters and system restrictions.
Finalisation testing
We check price changes, lack of availability and confirmation without bypassing the engine.
What goes into the module and what comes out?
We separate source material from the tool’s output. This helps subsequent modules understand which context they can use.
What does AI use?
- Stay parameters
- Offer data or the engine’s linking mechanism
- Guest handover rules
What does the team receive?
- Options that can be offered
- The right link or form
- Context for sales and stay-service modules
Permissions and decisions remain with the hotel
Before launch, we agree data access, responsible people and how exceptions will be handled.
The hotel approves the scope of supported offers. If fresh availability or support for a particular condition is missing, the tool should direct the guest to the search function or a staff member rather than promise a room.
Creating a link does not mean that a room has been held or payment taken. The offer may change before finalisation; the booking engine returns the binding result.
What changes in day-to-day work?
The guest can continue the conversation at the appropriate booking step without unnecessary searching.
The price and restrictions come from the system responsible for selling the stay.
Which sources and tools do we connect the module to?
We do not assume that all providers are supported to the same extent. We confirm the capabilities of the specific engine and any access requirements.
Related process elements
Its place in the implementation journey
These links come from the roadmap. Requirements form the basis of each node, while enrichments extend its capabilities. This does not mean that all subsequent modules must be launched at once.
Modules this element enriches
Frequently asked questions
Is this the same as a PMS integration?
No. The booking engine displays the offer and handles the guest’s purchase, while the PMS provides the operational context of the booking and stay. The scope may partially overlap.
Does AI confirm the booking?
The integration module itself does not promise this. Confirmation must result from a completed operation in the engine, not from a generated message.