Seba BlancoI help independent hotels sell more effectively and operate smarter by combining hotel technology with sales and marketing.
Do not index
Do not index
Open ChatGPT and ask for a quiet lodge on a lake in your region. Maybe your hotel comes up. Maybe a competitor does. Or maybe your hotel appears with a phone number you stopped using and a season that ended years ago.
Most independent hoteliers have tried this once, got a mixed answer and moved on. The trouble is that one test proves very little. These assistants answer differently depending on the day, the language and the wording, and the pages they read keep changing.
So I stopped testing by hand. I built a system that asks for me every week, checks every answer against the hotel's real data and turns the results into a short monthly to-do list. This post explains what it does, how the pieces fit together, and what it can and cannot tell you.
Three questions the monitor answers
Everything the system does comes back to three questions.
Discovery. When a traveller asks an AI assistant for a recommendation without knowing your hotel, does it name you? Does it actually recommend you, or just drop you into a list of ten?
Accuracy. When it does mention you, is what it says correct? Location, distances, phone, opening season, services. A wrong season can send a guest to a closed door. A wrong phone number turns a ready-to-book traveller into a lost one.
Sources. Where did the assistant get its information? This is the question that matters most, because it is the only one you can act on. You cannot edit ChatGPT. You can edit what ChatGPT reads: your website, your Booking.com and Expedia listings, your Tripadvisor page, and the regional tourism directories that nobody on your team has checked since they were set up.
How it works, piece by piece
The queries come from Google Search Console. I pulled the searches that already bring people to the hotel's website over the last 16 months and rewrote them the way a traveller would type them into an assistant, in Spanish and English. That matters: the monitor measures questions real guests ask, not phrases I would like to rank for.
A Make.com scenario runs those queries on a fixed schedule, one model per day: ChatGPT on Monday, Claude on Tuesday, Gemini on Wednesday, Perplexity on Thursday. Every model has web search switched on, and every query runs twice, because the same question to the same model can come back with a different answer an hour later. All four models are called through OpenRouter, so there is one account and one API key instead of four.
Each answer then goes to an auditor step, which compares it against a fact sheet stored in Notion. The fact sheet is the hotel's source of truth: address, road marker, distances, phone, season dates, services. The auditor records whether the hotel was mentioned, in what position, whether it was an explicit recommendation or a neutral mention, which facts were wrong, and which URLs the model cited. Every answer becomes one row in a Notion database, with the full model response saved inside the page.
A Notion dashboard shows the running totals per query: how many answers, how often the hotel appeared, and a simple green, amber or red status.
The monthly report that turns rows into decisions
Rows are not decisions. A table with a few hundred AI answers is something you open once and never again.
So on the first days of each month, a scheduled Claude task reads the previous month's rows, calculates every metric with database queries rather than eyeballing, and writes two things into Notion: a report and a task in the hotel's task list with an action plan attached.
The plan has a hard cap of seven actions, and each one has to say what to do, exactly where, why (which models, which weeks, the exact wrong sentence), how long it takes, and how we will know it worked. Priority follows a simple rule. A wrong fact that could cost a booking, like phone, season or location, repeated by two or more models, is high priority. A cosmetic issue, like appearing fourth instead of second, is low.
The report is also forbidden from recommending anything the hotel cannot do alone. No agencies, no paid tools, and no "optimise for AI" in the abstract. The actions are things like correcting the season dates on an OTA listing, fixing a paragraph on the website, or emailing a regional directory that publishes the wrong road marker.
Each month, the task also reviews the previous month's plan. Did the action work, has it had no effect yet, did it fail, or is there no sign it was ever done? That last category is the uncomfortable one, and it is there on purpose.
Separating real changes from noise
AI answers are noisy. If the hotel appears in a query 60% of the time one month and 50% the next, that probably means nothing.
The report treats a change as real only when it moves by 15 points or more, has enough answers behind it in both months, and points in the same direction in at least two separate weeks. A large move without enough data is labelled a weak signal and cannot justify a high-priority action on its own. Anything under 15 points is not discussed as a change at all.
It also measures how often the two runs of the same query disagree with each other. In the first baseline, English answers flipped between runs noticeably more than Spanish ones, which tells you how much to trust a single test in each language.
What the first baseline taught us
The baseline run, all four models on the same day, did not produce dramatic headlines. It produced something more useful: specific, fixable errors. A road marker off by a few kilometres. A camping season listed for the wrong months. Both appeared to trace back to the same regional directory.
It also produced a finding I did not expect. Several models agreed on a drive time from the nearest town that did not match the fact sheet. When three or more models agree against your own data, the report now flags it as "verify the fact sheet" rather than "third-party error". Sometimes the assistants are repeating a mistake. Sometimes they have noticed something you got wrong.
What it is not
This is a new system. The automated weekly runs started at the end of September, and the first full monthly report is due in October. I cannot tell you yet whether correcting sources moves the answers, or how fast. That is exactly what the monthly follow-up is built to find out.
The limits are worth stating plainly. The queries are a sample, not every question a guest might ask. The API version of each model with web search is close to, but not identical to, the app a guest uses on their phone. And the monitor does not track competitors, by design: it measures how the assistants describe your hotel, which is the part you control.
Running costs are modest. The API calls come to roughly nine US dollars a month for all four models, on top of Make and Notion plans many hotels already pay for. The real cost is the build, and the discipline to read one report a month and act on it.
The point of all this
Travellers are starting to ask assistants the questions they used to type into Google, and those assistants answer with confidence whether they are right or not. You cannot control the answer. You can control the sources, and you can know, month by month, which ones are hurting you.
If you want this monitor running for your hotel, with queries built from your own Search Console data, your fact sheet, the four models and a monthly action plan inside your Notion, Hotel Marketing Point sets it up for independent hotels.
Written by
Seba Blanco
I help independent hotels sell more effectively and operate smarter by combining hotel technology with sales and marketing.
