Guest Enquiries Around the Clock: Hotel AI Chat

Most enquiries to a hotel or guesthouse do not arrive between nine and five. They arrive in the evening, at the weekend, from another time zone. Anyone who gets no answer then asks the next house. This article shows which six questions come up again and again before a booking, where the answer comes from inside the house, why multilingual service is a requirement rather than a nicety, and where the boundary runs: taking an enquiry and handing it to the booking system is not the same as promising a price.

Enlarge graphic

Labels in the illustration

• Question in chat
• Source in the house
• Change rate
• Is the date available?
• Booking system
• live
• What room types are there?
• Room records
• per season
• Can the dog come?
• House rules
• rarely
• Where can I park?
• Location record
• rarely
• When is breakfast served?
• Service times
• per season
• What applies if we cancel?
• Booking terms
• on release
• 43 of 48
• questions without a handover
• own measurement series, one assistant
• 1.3 s
• to the first character of the answer, median
• 64 questions to our own assistant

Six questions before a booking

Enquiries outside reception hours

A house with twenty rooms rarely has a reception desk staffed around the clock. A guest's enquiry, however, does not follow the duty roster. It arrives when the guest is planning the trip, and that is often late in the evening or at the weekend. Twelve hours or more then pass before the next shift, and in that time the guest has usually already asked somewhere else.

An assistant on the website closes exactly this gap. It answers what can be answered without a query back, and records what a person has to decide. How long an answer may take before the enquiry moves on is described in Speed to lead.

Six questions before a booking

If you sort the enquiries of an accommodation business over a few weeks, you almost always end up with the same small group. It differs in detail between a city hotel and a country guesthouse, but hardly in pattern.

• Availability: is the period free at all? This is the only one of these questions whose answer can change by the hour.
• Room types: what is the difference between a double room, a comfort room and a family room? How many people fit in?
• Pets: can the dog come, into which rooms, and what does that cost? The last part of this question is already a price question.
• Arrival and parking: are there parking spaces of your own, is the underground garage low, how far is the station?
• Breakfast times: from when, until when, is there an exception for early departures?
• Cancellation terms: until when is a cancellation free of charge and what applies after that?

These six questions look equivalent, but they are not. They differ in the source the answer comes from and in the rate at which it changes. That is exactly what decides whether an assistant answers reliably or passes on outdated information.

Availability and room types

Availability is the only one of the six questions whose answer must not sit in a text. It belongs in the booking system, and only there is it current. An assistant that answers availability from a knowledge base always answers with yesterday's state. So this question is not answered but passed on: if the booking system is connected as your own interface, the assistant queries it; otherwise it takes the guest to the occupancy view.

With room types, the point is less the label than what stands behind it. A guest rarely asks about the comfort room; they ask whether four people fit into one room, whether there is a room without stairs, or whether the bathroom has a shower or a tub. These details belong in the knowledge base, and in the words a guest uses, not in the words of the brochure.

Pets, arrival and parking

These three questions have something in common: their answer is nowhere automatic, it exists only where someone once wrote it down. They change rarely and are therefore easily forgotten when they do change. The rebuilt underground garage, the new rule for dogs in the breakfast room, the loss of two parking spaces: if that is not carried over into the knowledge base, the assistant gives a wrong answer for months without anyone noticing.

All six tiles have the same shape: a fixed detail, a named owner, a boundary at which the conversation is handed over. Without that boundary, every rare question eventually turns into an invented answer. How to build the transition to a person cleanly is described in Handover to human agents.

Breakfast, check-in and check-out

Times are the part of the knowledge base that goes stale fastest, because they change with the season and are nonetheless treated as fixed. Breakfast starts earlier in summer, later at the weekend, differently on public holidays. If you store only one time, you get a wrong answer for the larger part of the year.

• Store times with a scope: weekday, weekend, public holiday, season. Not one time for everything.
• Write down the exception as well: what applies for a departure before breakfast starts, is there a package to take along?
• Tie check-in and check-out to the question behind them: arriving earlier, leaving later, dropping off luggage.
• Name an owner for every time entry who reviews it at the start of a new season.
• Do not present as checked what has not been checked. Better to hand over than to guess.

Cancellation terms: binding, not editorial

Cancellation terms are the most delicate entry in the whole knowledge base. They look like text but they are contract content. A wrong deadline in the chat is not an inaccuracy, it is information the guest relies on. So a separate rule applies to this entry: it is not changed in passing but released by management only, and the assistant reproduces it verbatim instead of summarising it.

On top of that comes a peculiarity of the accommodation trade that many guests do not know and therefore ask about in the chat: for overnight stays there is no general right of withdrawal in distance selling. The German Civil Code expressly excludes these contracts.

For the assistant that means two things. First, it must not confuse the question about withdrawal with the question about the cancellation deadline: one is law, the other is the terms of the house. Second, it must not infer from the absence of a right of withdrawal that a cancellation is never free of charge. What applies is in the booking terms, and those are all it reproduces.

Multilingual service as a requirement, not a nicety

In many industries a second language is an add-on. In the accommodation trade it is the normal case. A guest from abroad writes in their own language because they have read the website in translation anyway. If the answer then comes back in German, it reads like a rebuff, even when the content is right.

Technically this is no great step: the assistant recognises the language of the question and answers in it. The hard part sits in the knowledge base. An answer in French is only as good as the German entry it comes from. If the house rules exist only as brochure copy, the translation is just as vague. How to build this without maintaining every language separately is described in Multilingual assistant. What the feature covers is described on the multilingual assistants page.

• Do not translate proper names: room types, the name of the house, districts stay as they appear on the invoice and on the key.
• Output times and dates in the format of the target language, but without changing the content.
• Supply legally binding texts such as cancellation terms in the source language as well, where the translation only serves as an explanation.
• Check that the handover to a person continues in the same language. A change of language mid-conversation reliably loses guests.
• Carry the language through into the conversation analysis, so it becomes visible which languages actually enquire.

One obligation applies equally in every language: the guest must be able to tell that they are writing to a system. The European Union's AI Regulation requires this disclosure for systems that interact with natural persons. A short sentence at the start of the conversation is enough, and it belongs in every language offered, not only in German. The details are in Transparency obligation.

The boundary to the booking

The most tempting idea with an assistant in a hotel is to let it book straight away. We advise against exactly that, and not for technical reasons. A booking is the conclusion of a contract with a price, a scope of services and a withdrawal notice. Moving that into a conversation shifts obligations to a place where they are hard to evidence.

• The assistant records the period, the number of people, the room preference and any special requirements.
• If the booking system is connected as your own interface, it checks there whether the period is possible at all, rather than asserting it.
• It hands the recorded enquiry to the front desk or, with an interface of your own, to the booking system.
• The price, the binding availability and the conclusion of the contract arise there, not in the chat.
• The guest receives the confirmation by the route they know: as a message from the booking system.

This boundary also has a formal side. For contracts in electronic commerce the German Civil Code requires the consumer to expressly confirm that they are entering into a payment obligation, and that the button for this is labelled with nothing other than the words order with obligation to pay or a correspondingly unambiguous formulation. A chat window has no such button. The booking system does.

What can be measured

Whether an assistant brings anything to the house shows in two figures: how many questions stay without a handover to a person and how quickly the first answer arrives. For our own assistant there are measured values. In our own measurement series 43 of 48 questions stayed without a handover to a person; this was measured on a single assistant on our own knowledge base, not on customer projects, and a figure from live operation is not yet available.

The second figure is the wait until the first character. In our own measurement series the time to the first character of the answer was 1.3 s at the median, measured across 64 questions to our own assistant, not to customer projects. How to measure this time cleanly and which mistakes are common is described in Measuring response time; the raw values are under Measurements.

Neither figure says anything about your house. They come from a measurement series on one assistant with a knowledge base we maintained ourselves. An accommodation business with six seasonal schedules, three languages and a connected occupancy system sits elsewhere. The value of these figures is not their level but the fact that they exist at all: if you do not know your own rate, you cannot say whether anything has improved. How an assistant for restaurants and hotels is set up is shown on the industry page AI assistant for restaurants and hotels. Which of the six questions your house should cover first is something we are glad to discuss using your own website.

Frequent questions