A team custom becomes a clear rule
This example shows the module’s role in a hotel process. We define the source scope and available actions for each implementation.
“It depends who is on shift”
Staff respond differently to requests for early check-in. The documents do not explain the exceptions or who can approve them.
Condition, responsibility, escalation
Together, we record which data needs to be checked, what not to promise and who makes the decision. Reception verifies the examples. Only the approved rule is added to the knowledge available to the assistant or guest guide.
- Description of the process and exceptions
- Decision-maker
- Examples of the correct response
What does this module cover?
The interview focuses on specific processes: sales, the guest stay, reputation or publishing. We ask about typical matters, edge cases and the sources of discrepancies. We do not treat one person's opinion as the automatic policy of the entire hotel.
Operational knowledge
Practical decisions become available to new employees and AI tools as well.
Agreeing exceptions
It is clear when the process can run as standard and when it requires human involvement.
Property glossary
The property's names for services, abbreviations and team terminology acquire clear, consistent meanings.
How do we launch the solution?
Selecting interviewees
We invite the people who do the work and the owner responsible for the process.
Working through cases
We discuss real scenarios, uncertainties and examples of incorrect responses.
Approving the rules
The team revises the wording, identifies owners and agrees how it will be updated.
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?
- Staff knowledge
- Example situations
- Current procedures and constraints
What does the team receive?
- Approved rules
- List of exceptions and escalations
- Scenarios for AI testing
Permissions and decisions remain with the hotel
Before launch, we agree data access, responsible people and how exceptions will be handled.
Notes and working hypotheses remain separate from approved knowledge. The process owner resolves discrepancies and approves the version used by the implementation.
The interview does not establish hotel policy on its own. It does not replace integration with current booking data and does not guarantee that a procedure recorded once will remain up to date.
What changes in day-to-day work?
AI and the team work from the same rules and constraints.
The quality of the solution can be assessed using real cases from the property.
Which sources and tools do we connect the module to?
The result is knowledge that can be used across multiple modules. We define separately which roles can access it and how much can be automated.
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 that require this element
Modules this element enriches
Frequently asked questions
Do we need to have procedures ready?
No. The interview helps uncover and organise existing practice, but the hotel approves the final rules.
What if two departments work differently?
We record the difference and agree who is responsible. We do not combine conflicting rules into a single AI response.