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
It's 9:40 on a Saturday night. A guest wants to move their stay two days forward, and the receptionist on shift has done this in the PMS exactly once, three months ago, with someone standing next to her. So she does what every hotel employee does: she messages the manager on WhatsApp. The manager is at dinner, or asleep, or in a place with no signal. The guest waits.
Most independent hotels run on this pattern. Procedures live in one or two heads, and WhatsApp is the help desk. The fix is not another manual nobody opens. It's putting the answers where the question already happens.
This is the second case in our HotelOperations series. It covers a small WhatsApp bot built for the front desk of a remote lakeside hotel in Patagonia. A receptionist types a question into a WhatsApp group, and within seconds the bot replies with a link to the right step-by-step tutorial in Notion. If there is no tutorial, it says so and logs the gap. That is all it does, and that is the point.
Why a manual doesn't solve this
Hotels have written SOPs for decades. The problem is rarely that the procedure doesn't exist. It's that finding it takes longer than asking someone. A 40-page PDF on a shared drive loses every time against a two-line WhatsApp message to the boss.
So the design brief was narrow. The staff should not change their habit at all. They keep asking on WhatsApp, in their own words. What changes is who answers.
Three constraints shaped everything else:
The team is small and rotates each season, so knowledge walks out the door every March. Connectivity is limited, which rules out anything heavy. And the manager has no time to maintain a chatbot, so the system has to tell him what's missing rather than wait for him to notice.
How the bot works
The flow has five parts, and none of them requires a developer:
A message arrives in a dedicated WhatsApp group. A WhatsApp gateway (here, 360Messenger) forwards it to a Make.com scenario. Make filters out noise, pulls the list of published tutorials from Notion, and sends that index together with the question to Claude. Claude decides whether the message is actually a question and, if so, which single tutorial answers it. Make then replies in the group with the link and writes a row in a log.
The tutorials themselves were recorded with Scribe, which captures clicks and screenshots as you perform a task in the PMS or accounting software. Each Scribe lives in a row of a Notion database, one tutorial per page, so each has its own link.
Build the tutorial database for search, not for reading
This is the part most hotels would get wrong, and the part that matters most.
A raw Scribe export reads like "Click 28, type in field, click Save." No search engine, human or AI, can match "how do I change a guest's dates?" to that. So each tutorial page carries a short summary in plain language on top, with the original Scribe below it.
Here is the structure of the Notion database:
Property | Type | Purpose |
Title | Title | Written the way the person asking would phrase it |
System | Select (PMS, accounting, admin, Notion, other) | Sorting |
Summary | Text | One or two lines: what it solves |
Questions it answers | Text | One question per line, in the team's own words |
Status | Select (Draft / Published) | The bot only reads published rows |
Scribe link | URL | The original recording |
The "Questions it answers" field does most of the work. If your receptionists say "block a room" rather than "create an out-of-order status," that's what goes in the field. Write it the way they talk, not the way the software vendor talks.
The filter saves money and embarrassment
WhatsApp groups are chatty. People write "ok," "thanks," "👍," "haha." Sending each of those to an AI model costs money and, worse, invites a bot that replies to "thank you" with a tutorial link.
So Make filters before anything else happens. The message must come from the right group, must not come from the bot's own number (otherwise it answers itself in a loop), must contain text, and must not match a courtesy pattern: short words like ok, thanks, great, done, yes, plus emojis and punctuation. Those messages stop at the filter and cost nothing beyond the trigger.
Anything that gets past the filter goes to Claude, which makes a second, smarter call. "Great, found it" isn't a courtesy word, but it isn't a question either, and Claude stays silent.
The prompt
The model is Claude Haiku via OpenRouter, at temperature 0. The original prompt is in Spanish because the team is; this is the English equivalent, ready to adapt:
You are the internal front-desk assistant of [Hotel name]. You receive an INDEX
of tutorials (one line per tutorial: ID | title | summary | questions it answers
| page_id) and a MESSAGE a receptionist wrote in a WhatsApp group.
Step 1: decide whether the message is a question, meaning a question or a request
for help on how to do something. Greetings, thanks, confirmations, reactions,
jokes or comments that don't ask for help are NOT questions.
Step 2: if it is a question, choose the ONE tutorial that answers it. If none
answers it clearly, do not guess: return page_id null.
Reply ONLY with a valid JSON object, no extra text and no code blocks, in exactly
this shape: {"is_question": true or false, "id": "TUT-n" or null, "page_id":
"page_id copied exactly from the index" or null, "reply": "one or two lines saying
which tutorial it is and what it solves"}.
If is_question is false, id and page_id are null and reply is an empty string.
If page_id is null, reply is an empty string. When in doubt about whether it is a
question, treat it as one. Never invent steps or tutorials that are not in the index.One detail worth copying: Claude returns the page ID, but Make builds the link. Claude never writes a URL, so it can't invent one.
Four design decisions that matter more than the tools
No vector database. With fewer than about 100 tutorials, the full index fits in every call, and a model reading the whole list picks better than keyword search. A hotel doesn't need retrieval infrastructure for this.
When there's no answer, it doesn't improvise. The bot replies "I don't have a tutorial on this yet, check with the manager" and marks the question as uncovered. A bot that makes up PMS steps is worse than no bot.
Read-only. It reads Notion and posts in one group. It never touches the PMS, accounting software or anything else. The risk surface is a wrong link, nothing more.
A dedicated group, not the hotel number's inbox. The bot only listens inside one WhatsApp group, so it never replies to a supplier or a guest. Being in the group is the authorization. There's no whitelist to maintain.
A brief caveat: 360Messenger is an unofficial WhatsApp gateway, working like a linked WhatsApp Web session. The hotel accepted that risk because the use is internal and low-volume. Never use such a number for mass messaging.
The log is the real product
Every question lands in a second Notion database: the question, the tutorial chosen (or a "no tutorial" checkbox), the reply, the sender, a status and a "reviewed" checkbox.
Filter it by no tutorial = yes and reviewed = no, and you have the list of next tutorials to record, ranked by what the team actually asks. After a few weeks you stop guessing which procedures to document. The staff tells you, without anyone writing a memo.
This is what makes the system maintain itself. The manager's job shifts from answering the same question for the fourth time to recording a two-minute Scribe once.
What it costs to run
Each question uses around nine Make operations and a fraction of a cent on OpenRouter. The WhatsApp gateway needs a plan that supports incoming messages by webhook; on 360Messenger that's Standard or above, and the "Receive messages" setting must be switched on. That toggle was what blocked the first test here. If no executions reach Make, the problem is the gateway, not the scenario.
What to do on Monday
Don't start with the bot. Start with the list. Open WhatsApp and scroll back through the last month of questions your staff sent you. Pick the ten that repeat. Record each one with Scribe the next time you do the task, and add a plain-language summary plus the exact questions people used.
Once ten tutorials exist, the bot takes an afternoon to wire up in Make. To replicate it at another property, only the Notion database IDs, the WhatsApp connection, the group ID and the hotel name in the prompt change. The rest of the scenario copies over as is.
If you'd like to see where your operation stands before building anything, the HotelOperations self-diagnosis at hotelmarketingpoint.com/hotel-operations takes about ten minutes.
Written by
Seba Blanco
I help independent hotels sell more effectively and operate smarter by combining hotel technology with sales and marketing.