How does an AI assistant decide which hotel or restaurant to recommend?

These are the questions that decide hospitality answers, and they are a different shape from the ones that decide a shop. A guest types a place, a date and a party, and the assistant returns a short list of properties that fit all three at once.

Comparison sits a level down and it takes two forms here. One named property against another, which every category has, and a property against a neighbourhood, which is the version a shop never sees. A guest weighing your street against the district by the station is comparing you with a place rather than with a rival.

Destination questions come earlier still, before any property is named at all. Which area is best to stay in, when is the quiet season, is it walkable. Those set the language a later answer uses, and the properties described well in that language are the ones a shortlist reaches for. At the other end sits the narrow one: where to book and at what rate, which is as close as this category comes to a buying question.

A hotel, a restaurant or a venue is a set of rooms or tables at one address, and that address is half the answer. A firm covers a territory it can name and a software company is bound to neither an address nor a region, so an assistant recommending either has the category to get right and nothing else. Here it has the category and the place, and the place is the half a destination question turns on.

So the reading that matters most here is whether the property, its address and its category are machine-readable. Not whether the address appears somewhere on the site, but whether a machine can tie the three together and be confident it has one place rather than three, because a property, a brand and a group can all carry names that look alike.

The rest of the placing is done by other people. Destination guides and city guides describe an area and name the places in it, and a property that appears in those descriptions is a property an assistant can put on a list when somebody asks about that area.

A guest asking for a room is asking about a moment: a weekend in June, a family, a dog, a car. A shopper asking for a rucksack gets the same rucksack whenever they ask, which is why the constraints a guest travels with are the ones this category is measured on.

Which means the properties recommended well are the ones whose own pages say what fits what. Room types and how many they sleep, what a family arrangement looks like, whether there is parking, whether pets are welcome, what the terms are. Those are the exact constraints a guest puts in the question, and an assistant can only match them where somebody has written them down in a place it reads.

The rate that settles the choice sits in a booking engine on a host you do not own, and so does the availability. That is the ordinary arrangement in this business, and it is why the last step reads the answers a guest is given: the rate an assistant quotes and the terms it describes are what the guest is deciding on.

That list is worth reading twice, because only the last item is yours. An assistant answering a destination question is drawing on platforms, guides and threads written by other people about your property, and it repeats the verdicts it finds in them.

Guest review platforms carry a different kind of thing from the booking platforms beside them: a verdict about a named property, in sentences an assistant can lift straight into an answer. Both count as decisive sources for hospitality, so a property described well on the review platforms tends to be described well by the assistants.

Your own pages do a narrower and more precise job. They are what an assistant reads for the rooms, the terms and the location, which is the detail no aggregator states in your words. They are also the one source you fully control, which makes them where a wrong claim about you gets answered.

The fifth and final step is where a recommendation either reaches a booking or stops. For hospitality most of that route runs on a host you do not own, which is why the step reads what the assistants say rather than what a checkout of yours does. That is the right way round here: the guest meets the answer long before they meet the booking form.

A property can be recommended warmly and then described with terms you do not offer, or with a rate you do not charge, or sent down a link that has moved. Each of those loses the booking after the hard part is already done, and each one is visible in the answer itself.

So the link check goes all the way through the handover rather than stopping at your own page. A booking route that ends somewhere unreachable sends the guest back to the assistant, and the assistant offers the next name on the list.

A retail brand is read on a catalogue and a product feed, because that is where a shop keeps its prices and its stock. A property is read on what a property has instead: the rooms and the terms as your own pages state them, the address and the category in a form a machine can tie together, and every route a guest could be sent down, followed through to the platform at the end of it.

Rates are read too, and they are read where they count, which is in the answer a guest is given. A rate or a term quoted by an assistant is a claim about you in front of somebody deciding, and it is worth checking against what you publish, whichever system the real number lives in.

That is the shape of the whole reading for hospitality. The checks that fit a shelf are replaced by checks that fit a property, and the last step is scored on what the guest is actually told.