Building an AI Concierge? Here’s the POI Data Stack You Actually Need

52% of travelers who ended up dissatisfied with an AI trip-planning tool said the same thing: the answers were not rude, or slow, just wrong. Wrong hours and places that had already closed, recommendations that felt too generic because they were built entirely on stale information.

These findings are from Simon-Kucher's 2026 Global Travel Trends Study, which surveyed more than 10,000 travelers across ten markets in mid-2025. The complaints broke down like this:

• 52% said the assistant gave factually wrong answers (hours, locations, open/closed status)
• 47% said the suggestions felt too generic
• 38% said the assistant didn't understand what they were asking for

None of that looks like a language model problem. A model can hold a conversation fine. What it can't do on its own is know that the taco place three blocks away closed for renovations last Tuesday.

What "concierge" means once an LLM is doing the talking

The term is used to describe a person behind a hotel desk. Now it's shorthand for a chat interface that plans your day, books your table, and answers "what's good and open near me right now."

Sabre gave a real, dated example of what this looks like at industry scale:

• November 20, 2025: Sabre launched Concierge IQ, a generative AI layer built for airlines
• It handles trip planning, booking, and servicing in a single conversation, combining flights with hotels and other travel products instead of routing a passenger through five separate systems
• Virgin Australia signed on as the first airline to use it

A company the size of Sabre doesn't build conversational AI into its core booking infrastructure as a demo, that's a meaningful signal. But announcements like this tend to lead with the model and the conversational polish, and say much less about the unglamorous layer underneath: how does the assistant actually know a restaurant is open, that a museum has moved locations, that a shop closed for the season?

What has to sit underneath the chat window

If we strip away the conversational interface, then an AI concierge is really running on a handful of data types, most of which have nothing to do with the model itself.

A general-purpose model trained on a scrape of the internet has some version of most of these, frozen at whatever point its training data ended. That's the entire problem: a business that closed eight months ago doesn't know it's supposed to stop existing in the model's memory. Somebody has to tell it, continuously, and that's a data engineering job, not a prompt engineering one.

The part most teams get backwards

Here's an opinion, and it's one I'll actually defend: most teams building an AI concierge spend the bulk of their budget on the model, the prompt design, and the conversational UX, and treat the location data feeding it as a commodity they'll sort out later with a cheap API call. That's exactly backwards from where the real product risk sits.

• Foundation models are close to interchangeable. Swap GPT for Claude or Gemini and a well-built concierge product barely notices.
• Location data is not interchangeable. The quality bar is higher than most teams assume. It’s not enough for a feed to have the right name and address; it needs open/closed status and business attributes that are actually verified and refreshed on a real cadence, which is the kind of thing providers like SafeGraph built their whole business model around rather than bolting on as an afterthought.

Swap a stale, six-month-old POI feed for a current one, and the entire user experience changes, because that's where the "wrong answer" complaint actually lives.

I'd go further: a mediocre model sitting on top of clean, current location data will outperform a brilliant model sitting on top of a scraped, unmaintained business directory, almost every time, for this specific use case. Concierge products aren't creative writing tools. Their entire value proposition is being right about the physical world.

Where even good data still falls short

It would be dishonest to present clean POI data as a full fix. Even a well-maintained, frequently updated dataset can't tell an assistant:

• That a restaurant is fully booked tonight
• That a museum exhibit closed early for a private event
• That a shop's posted hours are aspirational and it actually closes whenever the owner feels like it

The honest framing is layered, not solved: POI data gets you from "confidently wrong" to "usually right," and live integrations get you the last mile for anything genuinely time-sensitive. Selling one as a complete substitute for the other is where a lot of these products overpromise.

How the pieces actually connect to the model

The fix isn't retraining the model on fresher data every week, that's slow, expensive, and outdated again within days. It's giving the model a tool it can call mid-conversation. The pattern (often called function calling or retrieval-augmented generation (RAG), depending on whose documentation you're reading) works roughly like this:

1. The model recognizes it needs a fact it doesn't reliably have
2. It sends a structured query out to a live database or API
3. It gets back a current answer
4. It folds that answer into its response

Ask a well-built concierge "what's open near the hotel right now" and it isn't guessing from memory, it's querying a places database in real time and reporting what comes back. That only works if what comes back is accurate.

Who's actually selling the underlying data

There are a handful of real options here, and they're not interchangeable.

None of these is universally the right choice. The decision usually comes down to how much data a product needs to store and reuse versus querying live, and what a team's existing cloud stack already talks to.

What this actually adds up to

A traveler asking an AI concierge where to eat tonight doesn't care whether the failure came from the model, the prompt, or a six-month-old address in a database somewhere. They just get a wrong answer, and per Simon-Kucher's numbers, more than half the people who had a bad experience blamed it on exactly that kind of inaccuracy.

The model gets better every few months on its own, mostly for free, courtesy of whichever lab shipped the latest release. The location data underneath it doesn't improve unless someone is actually paying to keep it current, whether that means an in-house pipeline or a licensed feed like SafeGraph’s. That's the part of the stack worth spending real money on, because it's the part nobody upgrades automatically.