Why can't a general AI assistant just answer my booking questions?

It is the first question most hoteliers ask. The AI reads the website, it connects to the booking engine, it writes better than half the team. Why does it still take weeks of work before it can talk to guests?

It is a fair question, and the honest answer is not about the AI at all.

Connecting to a booking engine is not one integration. Every engine answers the same question in its own language, and an assistant has to learn each one. A general-purpose assistant is excellent at language and has no way of knowing that the answer it just received is misleading. It will repeat that answer politely, fluently, and cost you the booking.

Two examples make this concrete.

Same question, three engines, three answers

A guest asks for a weekend for two adults and a child.

The first engine returns rooms with prices, child included. Straightforward.

The second returns rooms with no price for the child, because at that property children are priced at the desk and not in the engine. The total on the screen is not the total the guest will pay.

The third returns "no availability". What it actually means is "not for three people in one room". There are rooms free that weekend. Two of them, next to each other.

Same guest, same kind of hotel, three chances to lose the booking. A general assistant takes each answer at face value. It tells the third guest you are full, the guest books somewhere else within the minute, and nothing in your reporting will ever tell you it happened.

An assistant that knows the engine behaves differently. On the second, it does not present a total it knows is incomplete: it prices the child from your rules, or says plainly what is not included and offers to confirm. On the third, it does not accept the "no". It splits the party across two rooms, checks adjacent dates, checks whether the restriction is on arrival rather than on stock, and only then tells the guest you are full.

That is not cleverness. It is knowledge of one specific engine, written down by someone who watched it fail.

The welcome message that arrives too early

A "how is everything so far?" message reaches a guest before they have arrived, because the property system marked the reservation as checked in for an internal reason. The room was pre-assigned. The folio was opened to take a deposit. Night audit posted something.

The guest is still on the road. They now assume nobody at your hotel is paying attention, and they quietly discount every message you send afterwards, including the one that actually matters.

No general assistant can anticipate this, because no documentation anywhere says "at this property, checked in does not always mean checked in". You find it once, in a real conversation, and then you add a condition: no in-stay messages until there is a second signal, a key issued or a time of day that makes sense.

The iceberg

Those are two cases. There are dozens per booking engine and dozens more per property system.

Rates that exist but are not sellable online. Room types that can only be booked as part of a package. A closed-to-arrival restriction that reads exactly like sold out. Cancellation rules that differ by rate plan, so the correct answer to "can I cancel?" depends on something the guest never mentioned. A group block sitting in inventory that shows up as availability. A rate that returns a price in the wrong currency for a guest writing from abroad.

Each one is rare on its own. Together they make up a large share of real conversations, and they cluster exactly where the money is: multi-room, multi-person, long-stay and last-minute.

A "no" from a booking engine has more than one meaning. The assistant has to know which one before it answers. The same problem in a different shape is why an assistant has to read the calendar rather than a copy of it.

Earned, not built

You do not find these cases in documentation. You find them in live conversations, one property at a time, over months. Someone has to read the transcripts, notice that a guest walked away from an answer that looked fine, trace it back to the engine, and write the rule that stops it happening again.

That is why "we support engine X" and "we have run engine X live for a year" are not the same claim. The first describes a connection. The second describes a list of failures somebody has already paid for so that you do not have to.

It is also why the work does not stop at launch. Engines change. You add a rate plan, a colleague changes a restriction, a property system gets an update. Changing what your AI knows covers how to keep up with that without breaking the answers that already work, and human-in-the-loop versus fully automated covers why a person stays in the conversation by design rather than as a fallback.

What to ask before you sign

Which booking engines and property systems do you run live today? At how many properties, and for how long? Show me a real conversation where the engine said no and the assistant found a room anyway. What happens when the engine is slow or down? Who notices when a case is answered wrongly, and how long does the fix take?

The answers tell you more than any demo. A demo is a conversation the vendor chose. What you need to know is what happens in the conversations you will get. Twelve questions to put to any guest messaging vendor covers the rest of that conversation, and scripted bot or LLM assistant covers how to tell what is under the demo in the first place.

Takeaway

Ask a vendor which booking engines and property systems they run live, at how many properties, and for how long. That is the whole checklist.