Skip to main content
DoneThat

AI Adoption GuideHospitalityStay

AI concierge (RAG-powered)

Chat interface answers property and local queries using a structured knowledge base plus live availability data, using tools like Ivy by Go Moment.

Hospitality processBookConfirmPrepareArriveStayDepartReviewReturn

By Don, DoneThat’s AI coach · updated

Cite a knowledge-base passage or leave the field empty

A concierge reply is usable only when it can point at a knowledge-base passage. If a guest asks whether children can use the rooftop pool, retrieve the current house rule, draft from that passage, and keep the cite attached. If retrieval does not return a passage that actually answers the question, the answer field stays empty. Empty is a handoff to a person, not an invitation to improvise.

You already run this rule at the desk: look it up; do not invent a pet policy. Retrieval-augmented generation is that lookup, with a model writing the guest-facing sentence only after the lookup succeeds. Property and local facts need a visible knowledge-base passage. No passage, no answer.

Keep this path from swallowing other stay work. Pool hours, parking rules, and walking directions belong here. Extra towels belong with the in-room service request router. Holding a room type for a later stay belongs with the conversational booking agent. One fluent bubble that mixes those jobs is how a polite chat becomes an unconfirmed promise.

Load the guest query as a ticket. Capture property, stay dates, reservation or room identifier when the guest is in-house, language, and the exact question. Retrieve next. Do not generate first. Generation-first produces confident sentences that never touched the binder.

When a passage comes back, show the cite to the agent even if the guest never sees a document ID. The agent should see which SOP or FAQ chunk produced the sentence. If two chunks conflict, do not pick the friendlier one. Leave the field empty and escalate. Conflicting cites are a content problem.

Treat availability as a timestamped claim, not a guess

A spa description can sit in the knowledge base for months. A 7 p.m. table for two cannot. Whenever the reply claims something can be booked, reserved, or is still available, attach a live availability vintage: which system was read, the timestamp, and the inventory record. If that vintage is missing, availability is unknown. The chat does not say you have a table.

Guests screenshot replies. If the restaurant book moved five minutes later, you need to show that the bot reported a specific read. If the live system did not return a holdable unit, the availability part of the answer stays empty even when the knowledge base can still describe the amenity.

Do not pad the gap with local color. "The Italian place around the corner is usually quiet on Tuesdays" is not an availability cite. Neither is "the spa should have openings this afternoon."

If the guest wants a recommendation rather than a hold, you may still cite hours, dress code, walking time, and what the rate includes. Stop there unless live availability was retrieved. A personalized f-and-b offer generator can suggest a cuisine or a time window from preferences. It still does not mint a table.

Walk one query from load to agent confirmation

Use this as a training pass, not as a success story. At 4:12 p.m. a guest writes: "Can we get a late checkout tomorrow and a table for two at the restaurant at 8?"

Load the query and split it. Late checkout is a stay product with a cutoff and often a fee. The table is restaurant inventory. Both need the knowledge base for policy and the live systems for whether the request is possible right now.

Retrieve the late-checkout policy: cutoff, fee, notice period, who can waive it. Retrieve the restaurant chunk: name, hours, dress code, cancellation language. In parallel, read live availability for late checkout on that reservation and for an 8 p.m. two-top. Stamp both reads with a vintage.

Compose only from those results. If the policy chunk and the late-checkout availability read both exist, the draft may state the cutoff, the fee, and that inventory was open as of that vintage. If the restaurant hours chunk exists but the book returns no 8 p.m. slot, state the hours from the knowledge base and leave the table claim empty. Do not invent 8:15. Do not say the chat booked it.

Send the draft to a guest-services agent before any booking or charge. The agent posts late checkout and any fee on the reservation, then places a restaurant hold only in the book the property uses. The chat is a request file, not a reservation.

If either cite is missing, that part of the answer stays empty. The agent still sees the ask and the failed retrieval. The empty field is a work queue, not a blank for the model to fill.

After the agent acts, write back what was actually posted. "Late checkout until 1 p.m. is on the reservation, fee posted" is a confirmation. "I have you down for 8" is not, unless the agent completed the book.

Do not promise a crib or high floor from this path. Hand them to guest preference-based room setup so housekeeping gets a task instead of a chat rumor.

Stop the three ways this chat starts lying

An answer with no knowledge-base cite is the first failure. Models will describe a 24-hour fitness center that closed at 10 p.m. last year. Fluency is not evidence. If the retrieved chunk is about a sister property or last season's hours, treat it as no cite. Empty stays empty.

Treating the chat as a reservation is the second. Guests will say the bot booked them. If the interface uses confirmed, reserved, held, or charged before an agent has written to the PMS or the restaurant book, you taught that belief. Keep guest-visible language in request terms until the agent finishes. Do not auto-book. Do not auto-post a charge from a model output.

Inventing a restaurant table is the third. The guest arrives dressed for dinner. The host has no name. You cannot unsay an 8 p.m. two-top. If live availability did not return a slot, do not round up a nearby time or quote a third-party book as yours. The knowledge base may still describe the restaurant. The table claim stays empty.

Inspect cites the way you inspect a folio. Wrong property, expired SOP, missing vintage, or a fee that never appeared in policy: any of those is a stop.

Keep messaging tools and the PMS on the same quality bar

Guest-messaging and concierge products such as Ivy by Go Moment, HiJiffy, and other chat layers already sit in front of the guest. Property systems such as Oracle Hospitality, Mews, and other PMS platforms already hold reservations, rates, and often outlet configuration. Make retrieval and vintage mandatory between those classes of tool. Do not rank them.

Require four outputs on every concierge turn that claims a fact or an opening: the guest-facing sentence, the knowledge-base passage identifier, the live availability vintage when inventory is claimed, and a flag that booking and charging still sit with the agent. If a workflow cannot emit the empty state, do not let it speak to guests about inventory.

Keep the knowledge base current and plain: hours, policies, fees, walking directions, and what the rate includes. Update it when the outlet calendar changes. RAG cannot rescue a binder that still lists last winter's spa hours.

Sample threads for missing cites. Match restaurant and late-checkout promises to the book and the reservation. Count how often the empty field correctly became an agent task. That is the quality outcome: an answer that cites a knowledge-base passage and, when availability is claimed, a live availability vintage. Empty when neither cite exists. A guest-services agent still confirms any booking or charge.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first