A question on site, answered in the hotel’s context
This example shows the module’s role in a hotel process. We define the source scope and available actions for each implementation.
A guest is looking for somewhere to spend the afternoon
Anna opens the guest guide and asks where she can sit with her pet. She needs a specific answer, not a general description of the city’s attractions.
Guidance based on current knowledge
The guest guide shows the patio and the rules for staying with a pet, if the hotel has provided them. A request for an additional need can be passed to the service team once the relevant process is connected. Information about a room or booking number requires guest identification.
- Property content and map
- Answer from hotel sources
- Actions available through the integrations
What does this module cover?
The foundation is the website content and an index of additional sources. Staff interviews can add practical rules. PMS data, the booking engine and correspondence extend the context only within an agreed, authorised scope.
Access without installing an app
The guest opens the guide from a QR code or a link they have received.
Knowledge tailored to the property
Opening hours, rules, the map and answers use materials approved by the hotel.
A place for further services
Requests, recommendations and guest support can use a single interface.
How do we launch the solution?
Choosing information and cases
We decide what the guest should be able to handle independently and what should go to the team.
Building the guest guide
We connect approved sources, navigation and agreed AI features.
Testing the guest journey
We check the guest’s phone, content freshness, languages and request handovers.
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?
- Knowledge from the website and documents
- Approved stay procedures
- Optional context from hotel systems
What does the team receive?
- Mobile guest guide
- Answers and guidance for guests
- Agreed requests and actions
Permissions and decisions remain with the hotel
Before launch, we agree data access, responsible people and how exceptions will be handled.
The hotel identifies content owners and rules for keeping content up to date. A public QR code must not, by itself, provide access to data from a specific booking or authorise paid transactions.
The guest guide does not automatically become an autonomous stay companion. Personalisation, orders and bookings require the relevant integrations and confirmations.
What changes in day-to-day work?
Basic questions do not always have to end with a call to reception.
New stay-support features can be made available in a place guests already know.
Which sources and tools do we connect the module to?
This solution is designed for bespoke implementation. It does not describe the ready-made QR Guest Guide included in the Platform offering, nor does it promise all features from the outset.
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.
Required foundations
Additional context and capabilities
Modules that require this element
Frequently asked questions
Does the guest guide know the guest’s room number straight away?
No. Personal context requires appropriate identification and integration; a public QR code provides access to general information.
Can we start without a PMS?
Yes. Property information and responses from approved sources can work without specific booking data.