A chatbot on the hotel website: scope, knowledge and handover before going live

A hotel chatbot is software on the hotel's website that answers guests' pre-booking questions from a written fact sheet the hotel controls, and hands everything else to a person. Before launch, the hotel decides its scope, its sources, whether it may quote prices, and what happens at night.

It is 23:40 and a guest on the website asks whether the airport transfer is included and whether the pool is open before breakfast. Nobody is watching the inbox. What happens in the next ten minutes was decided long before that message arrived. This guide covers the decisions to make before a hotel chatbot goes live: what it may answer, from which written facts, whether it may quote prices, and what it says at night when it cannot help.

What is a hotel website chatbot actually for?#

It answers the questions a guest asks before booking, from written facts the hotel controls, and hands everything else to a person. It is not a complaints desk and not a booking engine. Getting those boundaries right before launch is what separates a chatbot that builds trust from one that creates incidents.

The core question set is narrow and repetitive: distance to the airport or the beach, parking and whether it is free, breakfast hours, pet policy, check-in and check-out times, extra beds and child rules, accessibility, payment methods, cancellation terms. A hotel that lists its ten most-asked pre-booking questions has usually covered most of the traffic. These questions arrive every day, in almost the same words, and they are answerable from facts the hotel already knows.

Complaints, refunds and changes to an existing reservation do not belong in the chatbot. They need authority that software does not have, and a wrong answer there costs more than a slow one. A guest who is told "the team will reply by 09:00" waits. A guest who is told "your refund is confirmed" when no such decision was made becomes a case file.

Answer, sell, resolve: three jobs, three tools#

Keep three jobs separate. Answering is the chatbot's job: written facts, listed topics, immediate reply. Selling is the booking engine's job: live rates, live availability, the transaction itself. Resolving is a person's job: someone with the reservation on screen and the authority to change things. When one tool tries to do another's job, the failure mode is predictable: the chatbot quotes a stale rate, or the booking engine tries to handle a complaint.

The chatbot sits on the website first. The same written facts can later serve a messaging channel, but channel setup is a separate decision with its own rules about response-time expectations and staffing.

Four boundaries belong in the scope sheet as handovers, not as answers: the chatbot must never confirm availability, quote a rate, promise a refund or accept a change without a person. The honest promise to the guest is simple: an immediate answer on the listed topics, and a human reply on everything else within a stated time.

Chatbot or live chat: which does a hotel need?#

They solve different problems. Live chat gives a guest a person during staffed hours; a chatbot gives written answers at any hour. Most hotels need a handover between the two, not a choice between them.

Live chat is only as good as the roster behind it. If the front desk is checking the inbox between check-ins, the guest experiences a slow chat, not a live one. A chatbot is only as good as its written facts: outside them it either guesses or says it does not know, and the second is acceptable only if a person follows up.

The handover moment is the real design decision. What triggers it: a complaint, a booking change, a request for a person, a question outside the sheet. And what the guest is told at that moment, in words written in advance rather than improvised.

The cost shape differs too. Live chat scales with staffed hours; a chatbot scales with the quality of the fact sheet and the review time the hotel gives it. A queue nobody watches is worse than an honest line: tell the guest when the team replies, and mean it. Both tools should leave a transcript the hotel can read, because if you cannot read what was said, you cannot correct it.

What belongs on the scope sheet?#

Every topic a guest may raise, marked answer, hand over or refuse, with the exact wording for the handover. It is filled in once, signed by the general manager, and reviewed on a schedule. The scope sheet is the single document that decides how the chatbot behaves when nobody is watching.

Use three columns, not two. Answer means the chatbot replies from the fact sheet. Hand over means a person takes it, with a stated reply time. Refuse means the hotel chooses not to answer in chat, with a polite line and an alternative route, such as a phone number or an email address.

Write topics as a guest would ask them: "is there parking, and is it free?" rather than "parking policy". The wording you test is the wording guests use, and a scope sheet written in internal jargon will not match real questions.

Name the handover triggers explicitly: complaint, refund, group or event enquiry, change to an existing reservation, request for a person, and anything about a named guest. Refusals need a reason and a route: medical and safety questions, legal and visa questions, price negotiation, and anything about another guest go to a person, not to a generated answer.

Keep the sheet short enough that someone actually maintains it. For example, 40 to 60 topics is a workable size for a mid-size hotel; a list of 300 is a list nobody updates. Sign-off is shared: the general manager owns the sheet, the front office manager reviews hours and arrivals, the reservations manager reviews policies and rates.

Writing the handover line#

Where does the chatbot's knowledge come from, and who keeps it current?#

From one written fact sheet the hotel owns, with a named person responsible for each block and a review date on every policy. Anything not on the sheet is not answered. This is the rule that keeps a chatbot honest, and it is the one most often skipped.

Separate stable facts from changeable policies. Address, distances, room types and facilities change rarely. Cancellation terms, children and pet rules, parking fees and seasonal closures change often and need dates. Give every row a source and a date, and give seasonal rows an end date, so the answer changes when the season does instead of lingering into October with a closed pool described as open.

Assign one owner per block: front office for hours and check-in, reservations for policies and rates, food and beverage for restaurant times, the spa or beach team for their own. The same facts must match the website, the booking engine, the channel content and what staff say on the phone. Guests notice the contradiction before they notice the chatbot.

The change procedure matters more than the initial document: a policy or price change goes into the sheet the day it is decided, not at the next website update. When a fact is missing, the only allowed answer is a handover: "I do not have that here, let me pass it to the team." Never a guess.

If you are starting the fact sheet from zero, a hotel fact sheet for AI assistants: what to write down first covers the first pass.

Should the chatbot quote prices or take bookings?#

No. It should send the guest to the booking engine with the dates already filled in and let the engine quote the live rate. This is the single most valuable boundary on the scope sheet.

A rate quoted in chat is a commitment made from a snapshot. Rates move with availability, length of stay and channel, and a stale quote becomes either a complaint or a discount the hotel did not plan. Availability is the harder problem: a chatbot that says "yes, we have a room" without checking inventory creates exactly the overbooking risk the reservation system exists to prevent.

The right pattern answers around the price: what is included, whether breakfast and taxes are in it, what the cancellation terms are, then hands over a link that carries the dates. The guest gets a useful answer and the booking engine gets a warm lead with the dates attached. For more on the broader pattern, see how to increase direct bookings on your hotel website.

If the hotel does want the chatbot to hold or book, that needs a real connection to the reservation system, with limits the hotel sets and a person confirming anything unusual. Group, event and long-stay enquiries go to a person every time; they are negotiated, not quoted. And whatever the chatbot says must not undercut or contradict the contracted rates the hotel publishes elsewhere.

What happens at night when the chatbot cannot help?#

The guest is told exactly what happens next: who will reply, by when, and through which channel. A promise the hotel cannot keep is worse than a short wait.

Two different promises must be written separately: an answer now, from the sheet, or a reply later, from a person, with a time attached. "I can answer questions about the hotel right away; our team replies to other messages from 08:00" is two promises, and each needs to be true.

Capture only what the follow-up needs: name, contact, dates and the question in the guest's own words. Never ask for card details or identity documents in a chat window. There is no payment and no check-in happening there, and a chat window is not a secure channel for either.

Split the night rules. General questions and future bookings can wait until morning. A guest locked out, a safety issue or a same-night arrival problem goes to the duty phone, not to an inbox. The handover note must land in a queue someone owns, with an owner and a due time; a shared inbox nobody checks is a lost guest with a transcript.

Tell the truth about hours, and read the overnight transcripts weekly. The questions that arrive at two in the morning are usually the ones missing from the fact sheet. For the broader handover decision, AI replies to guest messages: when to hand over to staff goes deeper on the triggers.

How do you tell guests it is software, and what do you review in the first weeks?#

Say it plainly at the start of the conversation, offer a person at any point, and read the transcripts every week for the first month. Disclosure is one short line naming it as an automated assistant, plus a visible way to reach a person. Do not let it present itself as a named receptionist; a guest who believes they are talking to a person will treat a wrong answer as a staff error, not a software error.

Transparency expectations differ by market. What one country asks a hotel to disclose about an automated assistant may not match another, so confirm your own case with a legal adviser before relying on any rule.

Soft launch on a handful of topics first: hours, location, parking, breakfast. Keep everything else on handover and widen the scope as the transcripts show the answers hold. The weekly review asks four questions: which questions had no answer, which answers a person had to correct, which conversations ended with no reply, and what guests asked twice. Fix in the fact sheet, not in the chat: every correction goes back to the written source so the next guest gets the right answer.

Test before staff or guests see it, with a set of real questions and the answers you expect, run by someone who did not write the sheet. How to test a hotel AI assistant before staff or guests use it gives a full method. Measure what you can count honestly: unanswered questions, handovers, corrections, and time to the first human reply.

What to do next#

Book a working session this week with the general manager, the front office manager and the reservations manager. Fill in the scope sheet together, mark every row answer, hand over or refuse, and name the owner of each block of the fact sheet. Scope, sources, the price boundary, the night rules, disclosure and the weekly review are one loop, and the loop only closes when a correction made in a transcript ends up back in the written facts.