Why AI Recommendations Need More Than Ratings

Does a high rating answer every hotel question?

Imagine a family choosing a Prague hotel for a weekend with a stroller, an early breakfast, and a step-free route to a museum. Two properties appear in the answer. One has the higher rating. The other has a slightly lower score, but a step-free entrance, breakfast served early, a lift to the rooms, and a tram stop nearby.

Which is the better recommendation?

I have had the opposite experience in several luxurious hotels. One that stands out was ten years ago in New York. Its rating was excellent, and the staff were attentive to the point that the attention felt intrusive. Each interaction was surely intended to feel thoughtful: another bit of small talk, another offer of help, another reminder that someone was nearby. I was not in the mood for that kind of personal service. I wanted quiet. The hotel was delivering something many guests valued; for me, it was a poor fit.

Nothing about the rating had to be false. It described a broad pattern of satisfaction, not my preference.

The better choice changes with the traveler, the room, the conditions, and the quality of the facts behind each option. A rating can establish a baseline. It cannot, on its own, explain fit.

For an AI assistant, this changes the job. A useful shortlist needs interpretation: who is traveling, what they want to feel, what they need to do, what constraints matter, and which properties can support the request.

The hospitality industry has spent years making ratings visible. The next challenge is making the reasons behind a recommendation visible and verifiable too.

What do ratings measure well?

Ratings are valuable. They compress a large amount of guest experience into a signal that is easy to compare. They can help a traveler distinguish a consistently well-reviewed property from one with widespread service problems. Review volume and recency can add context about how much evidence exists and whether the experience appears current.

Compression helps with a broad question. A specific stay requires more work: the assistant has to understand the situation, not just compare the scores.

An overall score usually does not tell an agent whether a hotel is quiet at night, whether a room has a usable desk, whether the Wi-Fi supports a video call, or whether a family can reach breakfast without navigating stairs. Those are not universal attributes. They are questions about a property in a situation.

Hotels expose this problem clearly because the same property can create very different stays. A street-facing room and a courtyard room may differ materially. A work-friendly lobby may be useful during the day but not after an evening event. A hotel near public transport may still be inconvenient for a stroller or a guest with limited mobility if the entrance and route are not described clearly.

What does the AI recommendation research show?

The strongest new evidence concerns the influence reputation signals can exert when models choose among otherwise comparable hotels.

In an algorithm audit of reputation signals in LLM-assisted hotel selection, researchers ran a pre-specified choice experiment across 12 open and proprietary language models. The experiment varied hotel attributes including guest rating, review volume and recency, management response, chain affiliation, price, eco-certification, and list position.

In that controlled setting, moving a hotel's rating from 3.9 to 4.7 increased its selection probability by 31.6 percentage points.

When an agent cannot find specific evidence about the stay, a compact reputation measure can crowd out richer property context.

The result comes from a controlled comparison. A high rating still does not make a hotel a poor choice. When the model lacks concrete information about quietness, workability, accessibility, or atmosphere, the rating has less competition.

We have covered the complementary HotelQuEST benchmark and Tokyo grounding study in our article on making hotels discoverable to AI. That article explains how hotels become legible to AI retrieval; this one addresses the next decision: what happens when an agent must compare properties and explain why one fits the traveler better than another.

Why is fit harder than a score?

Fit only appears when a traveler, an experience, a place, and a set of conditions line up.

“Family-friendly” might mean adjoining rooms, child-safe common areas, flexible meal timing, or a short step-free route to an attraction. “Good for remote work” might mean a real desk, dependable connectivity, low daytime noise, and a policy that permits longer stays in a public workspace. “Romantic” might refer to privacy, a particular view, a restaurant, or the feeling created by the setting rather than an amenity that exists in every room.

A label such as “family-friendly” earns its place when the hotel can explain what makes it true. The description needs observable facts and the conditions that limit the promise, especially when the underlying idea is a mood rather than a facility.

Reviews add texture here, although they need careful interpretation. “I worked comfortably here” records one guest's experience at one time. A verified statement about every room needs different support: a suitable desk and a connection tested for a particular use. Reviews provide lived context; owned and current property data provides accountable facts. A recommendation is stronger when the two agree.

What information should a hotel make legible?

Hotels make their public footprint more useful when they describe the relationships that affect a decision.

At GoVisit, the practical vocabulary is place, amenity or service, experience, feeling, claim, evidence, and fit. These concepts can be represented through ordinary content and structured records:

Evidence does practical work. A fact without a source or review date may still be true, but an agent has less basis for deciding whether it is current and applicable.

Consider the claim “courtyard-facing rooms are a calmer fit for remote work.” The rooms or revenue manager owns it. Its source is the hotel's canonical room-detail page and booking-engine inventory, and its boundary is clear: it applies to courtyard-facing room types, not automatically to every room or every time of day. Reviewed: 2026-08-24. Those details give an agent something it can inspect and give the hotel something it can keep current.

How can hotels move beyond ratings in practice?

Start with one question the reservations team hears repeatedly. There is no need to model the whole hotel at once.

1. 1

   Identify the intent behind the query

   Collect questions reservations staff already hear: quiet room, family stay, accessible entrance, late arrival, work trip, celebration, or proximity to a particular venue. These reveal the dimensions that a broad rating hides.

2. 2

   Describe the conditions that make the fit true

   Replace “ideal for remote work” with the facts that support it. Which room types have desks? Where does noise vary? What does “reliable Wi-Fi” mean in the property's own testing? Is the workspace available to day visitors, and at what times?

3. 3

   Attach ownership, source, and freshness

   Give each decision-relevant claim a clear owner and a review cadence. Keep room facts aligned with the booking engine, property identity aligned with maps and listings, and changing offers aligned with their terms. An agent should be able to distinguish a current hotel statement from an old third-party description.

4. 4

   Test the answer, not just the markup

   Ask several AI systems the same situational question and record which properties they recommend, which evidence they cite, and what they get wrong. Test variations in audience, language, neighborhood, constraints, and dates. A ranking is only one output; the useful test is whether the hotel is represented accurately when the request becomes specific.

5. 5

   Make the recommendation explainable

   Keep the rating as a baseline, then give the agent enough current evidence to explain why this property fits this traveler, in this situation.

How can the model appear in structured data?

GoVisit can use Claim for a specific, factually oriented proposition, while keeping CreativeWork for the richer experience narrative around it. “A calm base for several days of remote work” is an experience description. “Courtyard-facing rooms provide a calmer setting for remote work” is a claim that can be checked against room information, Wi-Fi testing, and the hotel's own source pages.

Schema.org has no generic Experience type. GoVisit's current Place graph uses CreativeWork for experience collections and cards, Audience for the intended guest group, and DefinedTerm for the relevant intent or category. A claim can sit underneath that experience through interpretedAsClaim, then carry its own source, owner, and freshness information.

The following fragments are simplified from the Place-page structure. They show the existing relationship between a hotel, its amenities, and an experience, followed by the proposed claim layer:

{
  "@context": "https://schema.org",
  "@graph": [
    {
      "@type": "Hotel",
      "@id": "https://govisit.ai/en/places/example#place",
      "name": "Example Hotel",
      "amenityFeature": [
        {
          "@type": "LocationFeatureSpecification",
          "name": "Guest desk",
          "value": true
        },
        {
          "@type": "LocationFeatureSpecification",
          "name": "Wi-Fi",
          "value": true,
          "description": "Connectivity tested for guest use."
        }
      ],
      "subjectOf": {
        "@id": "https://govisit.ai/en/places/example#experience-remote-work"
      }
    },
    {
      "@type": "CreativeWork",
      "@id": "https://govisit.ai/en/places/example#experience-remote-work",
      "name": "A calm base for several days of remote work",
      "description": "Work from a courtyard-facing room with a desk and tested Wi-Fi.",
      "about": {
        "@type": "DefinedTerm",
        "name": "Remote work"
      },
      "audience": {
        "@type": "Audience",
        "audienceType": "Solo business travelers"
      },
      "interpretedAsClaim": {
        "@id": "https://govisit.ai/en/places/example#claim-remote-work-fit"
      }
    }
  ]
}

{
  "@type": "Claim",
  "@id": "https://govisit.ai/en/places/example#claim-remote-work-fit",
  "text": "Courtyard-facing rooms provide a calmer setting for remote work.",
  "about": {
    "@id": "https://govisit.ai/en/places/example#place"
  },
  "audience": {
    "@type": "Audience",
    "audienceType": "Solo business travelers"
  },
  "citation": [
    "https://examplehotel.com/rooms",
    "https://examplehotel.com/wifi"
  ],
  "author": {
    "@type": "Organization",
    "name": "Example Hotel"
  },
  "dateModified": "2026-08-24"
}

Claim does not give GoVisit a standard fit, feeling, or evidence property. In the graph, the experience carries the guest-facing description. The claim carries the proposition. Citations, ownership, dates, and boundaries give an agent the context it needs to judge the proposition.

What will better recommendations require?

AI recommendations will continue to use ratings because ratings are useful, familiar, and compact. Hotels should keep them while publishing enough context to prevent ratings from becoming the only legible signal.

A property that publishes only a score asks an agent to infer the rest. A property that publishes audience, experience, feeling, fit, conditions, place relationships, and evidence gives the agent material for a more accountable answer.

A better information contract sets out what the hotel offers, who it suits, under which conditions, and how recently the claim was checked. The assistant can then compare options on more than reputation and tell the traveler why one recommendation fits better than another.

That is the next layer of hotel discoverability: being understandable when the traveler asks a question that matters to the stay, alongside being visible and highly rated.

Begin with an audit of what agents can currently find. Then improve the facts they use to explain a fit.