AI concierge for hotels: where local recommendations go wrong and how to check them

An AI concierge is a guest-facing assistant that answers questions in plain language about the hotel and its area. Local recommendations go wrong because facts go stale, seasons and hours change, and a language model will invent a plausible venue rather than admit ignorance. The fix is a hotel-checked list with dates, disclosed paid placements, and handover to a person for health, safety and transport.

A guest asks the hotel's assistant for a good fish restaurant within walking distance. The answer is fluent, specific and wrong: the place closed in October. The guest walks there, finds shutters, and comes back to a desk that now owns a recommendation it never made. After reading this, you will know how an AI concierge works, why local facts go wrong, and how to run one from a list your team has actually checked.

What is an AI concierge, and what is actually being sold?#

An AI concierge is a guest-facing assistant that answers questions in plain language about the hotel and the area around it, usually inside the hotel's guest app or on its website. What vendors sell under that name varies a great deal, and the differences decide whether it helps or embarrasses the desk.

Three shapes share the name: a chat window on the hotel website, a module inside the guest app, and a stand-alone area guide marketed to the whole destination. Only the first two are the hotel's to control. The stand-alone guide answers to whoever published it, and its mistakes still land on your desk if guests find it through you.

The part the product does well is the property itself: breakfast hours, pool rules, parking, late checkout, where the lift is. These facts sit in the hotel's own system and change rarely. The part it does badly is everything outside the door, because those facts live with other people and change without notice. If you want to know what guests actually ask, start with what a concierge desk really answers every week.

An AI concierge is not the same product as a website chatbot scoped to hotel questions or as automatic replies to guest messages. The difference is that here the answer leaves the building and the guest acts on it. That is why the checking burden is higher.

Before any demo, ask the vendor four questions: where does the local content come from, who edits it, does every answer show a date, and what does the assistant say when it has nothing on file. Then run your own test. A demo that only shows property questions tells you nothing about the risk. Ask it about a restaurant that closed last month and watch what it does.

Why do local recommendations go wrong?#

They go wrong because the facts behind them belong to someone else and move without telling the hotel. A language model makes this worse: when it has no record, it produces the most plausible next words instead of an admission that it does not know.

Stale facts are the quietest failure. A restaurant changes hands, a beach club closes for renovation, a shop moves. The list still says otherwise, and the assistant repeats it with full confidence. Seasonal facts are the most predictable failure: ferry timetables, lifeguard cover, mountain road closures and museum hours all change with the calendar, sometimes twice a year and sometimes with a week's notice.

The worst failure is the invented venue. Asked for a pharmacy nearby, a model without a record can produce a name, a street and opening hours that read perfectly and exist nowhere. This is not a bug in one product; it is how the technology works when it is asked to fill a gap. Two quieter failures sit beside it: misapplied proximity, where "nearest" computed from a map pin ignores a motorway, a hill or a dark alley, and missing conditions, such as price band, whether a table must be booked, or whether the place suits a family.

The hotel owns the outcome in every row. The guest did not ask a search engine; the guest asked the hotel's assistant, and the desk carries the complaint.

Who owns the checked list of places, and how often is it reviewed?#

One named person owns the list, and every entry carries a date. Without a name and a date, the list is a set of opinions that the assistant will repeat as facts.

Name the owner in the document itself: the guest relations lead or the concierge chief, with a deputy for days off. "The marketing team" is not an owner. Fix the fields before the first entry: name, address, walking time from the door, phone, opening hours, closed days, season, price band, whether booking is needed, accessibility, last-verified date, verified by. If structuring facts is new to your team, the same principles apply as in a hotel fact sheet an assistant can use.

Set two review cycles. A short one, weekly, for anything that moves often, such as restaurants and boats. A long one for museums and monuments. Add a full re-check before each season change. When the date is old, the assistant says so out loud or hands the question to a person; an entry that has not been checked should not be served as a plain answer.

Two rules protect the list itself. The assistant never adds a place on its own, even when a guest suggests one: a guest suggestion goes to the owner as a candidate, not into the answer. And any staff member can take a place off the list the same day with one message, with the reason written down. Write the list as a document a person can read, not only as a database, so the desk and the assistant work from the same words.

How do you tell a guest that a recommendation is paid?#

In the same answer, in plain words, before the guest acts. If money or a partnership affects which places appear or in what order, the guest is told at that moment, not in a footnote on another page.

Three commercial models behave differently: a flat paid placement, a commission when the guest books through the hotel, and a free editorial list. Each needs its own disclosure sentence, and the sentence belongs in the assistant's answer. Disclose the fact, not the amount: "this is a partner of the hotel" is enough. Guests rarely object to the arrangement; they object to finding out later.

Order matters. If partners are listed first, say so. If the list is sorted by walking distance and a partner happens to be first, say nothing extra, because nothing was bent. One boundary is fixed: a paid place never displaces a safety-relevant answer. If a guest asks where to swim and the only safe option is not a partner, the safe option is the answer. The assistant must never invent a partnership or a discount; if the arrangement is not written in the list, it does not exist for the assistant.

Expect a small cost in clicks and a larger gain in credibility. A guest who learns the hotel hid a paid placement discounts every future recommendation, including the honest ones. Write the disclosure sentences once, in both languages the desk uses, and keep them in the same document as the list so they are reviewed together.

Which questions should never reach the AI concierge?#

Health, safety, transport, money and anything involving children go to a person, every time. These answers carry physical or legal consequences, change by the hour, and often need a phone call that the assistant cannot make.

Health covers pharmacy, doctor, dentist, hospital, allergies, food intolerance and accessibility needs. A wrong pharmacy at midnight is not a service failure, it is a harm. Safety covers sea and beach conditions, whether a street is safe after dark, a lost passport, a theft, harassment and a fire alarm; these need a trained person and often a record. Transport covers ferry and bus times, airport transfers, taxi fares, driving conditions and parking. Times change and fares are disputed, so the desk should say them, not a model. Children's questions, such as car seats, high chairs, babysitting and age limits, commit the hotel to a duty of care. Money and disputes, such as refunds and complaints, belong to a person with authority to decide.

Build the routing as a rule, not a hope. The assistant recognises the topic, says it is passing the question to the desk, and the desk receives the question with the guest's name and room. The same handover logic applies more broadly, as covered in when an AI reply should hand over to staff.

How do you test an AI concierge before it goes live?#

Write twenty local questions the desk has actually been asked, add five it must refuse, and score every answer on three things: correct, sourced and handed over when it should be. A confident wrong answer is a fail; "I do not know, let me pass you to the desk" is a pass.

Draw the twenty from real asks, not from a brainstorm. The desk hears the same ten questions every week; those are the test. Include at least three questions whose true answer is "that place has closed" and three about a venue that does not exist, and watch whether the assistant invents.

Score three columns per answer: is it correct against the list, does it show where the fact came from and when it was checked, and did it route to a person where the rules require it. Add the five refusals: a medical question, a safety question, a transport time, a child-care request and a refund demand. Each must reach a person. These tests sit inside the broader discipline of guardrails for a guest-facing AI assistant.

Re-run the whole set after every list update and at each season change, because the list is what the assistant answers from and the list is what moved. Keep a log of the answers guests actually saw and read it weekly: the test set tells you what you thought of, the log tells you what guests asked. Record the result in writing, with the date and the person who ran it, so the next review starts from evidence rather than memory.

What to do next#

Start with the list, not the software: name one owner, write the fields, put a date on every place, and only then decide what the assistant is allowed to say. The order matters because the technology is the easy part; the checked facts and the routing rules are what keep a fluent answer from becoming the hotel's mistake. Your first concrete step is a one-hour meeting with whoever runs guest relations: agree the twelve fields, agree the owner and the deputy, and set the date of the first full re-check.