Hotels can prepare multilingual guest support by separating written policies from questions that need live booking information or a decision from staff. Build a source matrix for check-in, pets, accessibility, and transport; draft answers from approved material; then have a native speaker compare each translation with its source. This is a practical guide, not a report of observed hotel deployments. Language capability alone does not establish that a translation is accurate.
Make a source matrix
Start with the questions your team is prepared to answer and the current source that governs each answer. Use the worksheet below to assign an owner and mark the boundary between general policy and information that must be checked for an individual guest.
The bracketed text is a prompt, not sample hotel policy. Replace it with details from your own approved materials.
| Topic | Source to check | Answer to prepare | Do not imply without verification | Owner or next step |
|---|---|---|---|---|
| Check-in | Current arrival instructions | “Check-in begins at [time]. [Add other source-backed instructions.]” | Early access is available or arranged | Front desk or policy owner |
| Pets | Current pet policy | “Our policy says [approved terms].” | An exception is approved or a particular room is suitable | Policy owner |
| Accessibility | Current accessibility information | “The information we have describes [specific feature]. Contact us to discuss your requirements.” | A general description establishes that a space meets a particular guest’s needs | Guest-services or accessibility contact |
| Transport | Current directions or transport guidance | “Our published information says [route or option].” | A live schedule, service status, seat, or booking is confirmed | Transport contact or current provider information |
| Room availability | A channel or staff member able to check current inventory | Direct the guest to the place that can check the requested dates | A room or rate is available | Booking contact |
| Refund request | Current cancellation or refund policy | Explain the written terms and how to request a review | A refund is approved, authorized, or issued | Authorized staff member |
| Reservation status | Booking record or staff member able to check it | Direct the guest to a person or channel that can confirm the reservation | A reservation exists, is confirmed, or has changed | Booking contact |
Keep three kinds of answers distinct. A policy explains general terms. A live status answer reports current information, such as inventory or a reservation record. An approval is a decision by someone with authority. A policy that explains when a guest may request a refund does not itself approve that refund. A booking link can direct someone to a place to check dates, but it should not be described as a confirmed reservation.
Draft bounded answers from approved sources
For each policy question, write a short answer using the source’s actual conditions, times, dates, fees, and exceptions. If two documents disagree, ask the policy owner which one governs. Do not resolve a conflict by choosing the wording that sounds more generous or convenient.
Be precise about what a source does and does not say. If the check-in instructions give a start time, do not add a promise about arriving earlier. If the accessibility material names a feature, describe that feature rather than making a broad promise about suitability. If the transport information describes a route but not a current departure, do not turn it into a live schedule answer.
If you use a knowledge source for answers, remember: A source must finish processing before its content can be used in answers. Once it has finished processing, compare proposed answers with the original material. A successful attachment alone is not evidence that its contents are ready or that the source covers every question.
A useful answer pattern is: state the verified information, name any important limit, and give the next step. For example: “Our current information lists [documented accessibility feature]. If you share what you need, [contact or route] can discuss the details with you.” The example is a template, not a claim about any hotel’s facilities.
Review each translation against the source
A translated answer can sound fluent while changing a condition, omitting an exception, or making an option sound guaranteed. Ask a native speaker to compare the guest-facing wording with the approved source. If the meaning of the policy itself is unclear, ask the policy owner to settle it before finalizing the translation.
Give the reviewer the source and translated answer side by side. Ask them to check:
- Are the conditions, exceptions, and limits preserved?
- Are times, dates, amounts, names, and contact details correct?
- Does the answer distinguish policy from live status or a staff decision?
- Could a guest reasonably read the wording as a promise the hotel has not made?
- Is the next step clear, including where to check or whom to contact?
For example, confirm that “you can request a refund under these conditions” has not become “your refund is approved.” Check that an accessibility description has not become a blanket assurance when the source lists only one feature. If you cannot arrange qualified review for a language, do not label its content as reviewed; arrange review before relying on it as guest guidance.
Treat the language setting and translated copy as separate checks. In LoopReply, the model-context language setting is live and takes effect immediately; wording in draft Agent instructions waits for Publish. Check the exact field you are changing, then review guest-facing answers in the selected language. Ask a qualified reviewer to check each proposed language before deployment.
Test policy answers and boundary questions
Before relying on the FAQ, prepare a small review sheet. For each test, write the guest question, its source, the answer you consider acceptable, and the boundary the answer must respect. Include both questions the written policy answers and questions that require current booking information or staff authority.
| Guest question | Suitable answer should | Boundary to check |
|---|---|---|
| “What time does check-in begin?” | State the approved time and relevant instructions | Do not promise early access unless it is confirmed through the proper route |
| “Can I bring my dog?” | Summarize the current pet terms | Do not approve an exception or promise a particular room |
| “Is the entrance step-free?” | Describe only what the source documents | Do not infer that the information meets an individual guest’s needs |
| “Can you refund my booking?” | Explain the written policy and how to request review | Do not say the refund is approved or issued without authorization |
| “Is my reservation confirmed?” | Direct the guest to a person or channel that can check | Do not invent a reservation status |
| “Is a room available on Friday?” | Direct the guest to a route that can check current inventory | Do not present general policy as a live availability check |
Repeat the review for every language you plan to use. Compare each answer with its approved source and reviewed translation. If an answer crosses a boundary, revise the wording or source as appropriate and run the check again. For a related worksheet on questions the available material does not answer, see What should your Agent say when its knowledge has no answer?.
Set a route for questions that need staff
Choose where guests should go when they need current availability, confirmation of a reservation, an individual accessibility discussion, or a decision about a refund. Name the relevant contact or channel in the answer. Avoid vague timing promises such as “someone will reply soon” unless you can support them.
Authorized Workspace members can take over a conversation and reply as a human. While a conversation is waiting or in human-takeover, the widget does not receive an AI response. Human handover provides a route for help, not a response-time guarantee. Decide who will handle these requests and what guests should do outside staffed hours. See the human handover guide for more on planning that route.
Keep the worksheet current
Assign an owner to each source and set a review reminder that fits your policy-change process. When a policy changes, update the approved material, recheck affected answers, and repeat the language review for any translation that may have changed. Knowledge sources are live settings and take effect immediately. Check the intended content and source before replacing one.
The practical outcome is a bounded guest FAQ: policy wording that has been reviewed against approved material, clear limits around live booking information and staff decisions, and an explicit route for questions that require a person. Keep the review record with the source so the next policy or translation update has a clear starting point.
A hotel FAQ source you can reproduce
For a fictional hotel, write three facts: check-in begins at 15:00; breakfast is served from 07:00 to 10:00; early check-in requires reception confirmation. Ask “Can I arrive at 11?” The expected answer can explain the early-check-in request process, but cannot confirm room readiness from this source.
Repeat the question in each language you plan to support and have a fluent reviewer compare the time and condition. Link the confirmed booking route separately. The no-code build tutorial shows the configuration sequence, while the handover guide covers reception questions that need a person.