AI Concierge Across a Hotel Group — 3 Properties, 3 Channels, 4 Languages, 91.7% Handled by the Bot, Improved From Real Chats Every Day

At a Glance

The Client

A Thai hotel group running nature resorts, city hotels and riverside floating accommodation. Guests reach out mostly through Facebook and LINE. Every property already publishes complete information on its own website, yet the admin team was still typing the same answers every day, at every property.

The Problem

The group's commercial lead put it plainly at the meeting on site:

"Getting AI is our goal this year, because our admin team can't keep up."

And: "The hotel already has everything on its website, but guests don't really read it."

• •The same questions every day at every property: room rates, check-in times, what the resort offers
• •Each property has its own inbox, with no overall view
• •Foreign guests write in many languages; the team answers in Thai and English only
• •Guests compare three or four places at once, so a slow reply is a lost guest — and staffing every property around the clock is a cost nobody wants to carry

The client's technical advisor asked the two questions that ended up shaping the whole architecture: "We'd have to teach it. Who's going to teach it?" and "What if it gets something wrong — says the restaurant opens at 6 instead of 7?"

Why Start With One Property — and the Hardest One

The group did not build all 16 accounts at once. The client proposed starting with a single property, and with the hardest one: the widest range of guest questions, the most languages and the most complex rate and activity structure. If the formula held there, the other properties could copy it. If it broke, it would break early and cheaply, on one property instead of sixteen.

Who Teaches It: The Hotel Does

The answer to "who's going to teach it" became the design. The hotel team owns its data in a Google Sheet — FAQs, rates, promotions, child and extra-bed rules — and edits it whenever it likes. The bot picks up the change by itself. No programmer, no charge.

That decision shaped how support is paid for. Management was offered a fixed monthly retainer or paying only for system-level work actually used, and chose the second, agreed before the build started. A 90-day care window came first (bug fixes within 24-48 hours, weekly reporting, automated monitoring). I gave up recurring income on purpose, because the system is built so the client doesn't have to depend on me.

The answer to "what if it's wrong" became the rule: the bot may answer only from the hotel's own data. Anything that isn't there goes to a person.

What I Built

Every guest message goes through the same path, at every property, on every channel.

Answering guests (every message)

1. •Join the lines a guest types in a row into one question, read the intent, and remember the topic in play
2. •Decide whether the bot should answer at all. Total prices, room availability, complaints and urgent in-stay requests always go to a person
3. •If it can answer, answer from the hotel's own data (82 FAQ sets in Thai and English at the first property), with room photos, activity cards, maps and booking links from a 688-item captioned image library
4. •If it has to hand off, alert staff on Telegram once per conversation, not once per message, with a button that pauses the bot in that chat. The bot comes back on its own when the pause runs out
5. •Log every message, every lead and every unanswered question to Google Sheets, and calculate KPIs every night
6. •Staff can stop or restart the bot themselves from a Telegram group

Key technical decisions

• •One conversational core runs identically on Messenger, LINE and the website widget, rather than three separate bots, so the answer doesn't depend on the channel a guest picked
• •Four languages from day one, because the guest base isn't Thai-only. Anything beyond the core set falls back to English
• •The bot's knowledge started from each property's real website, pulled with an automated tool rather than retyped, so its answers match what the hotel already says in public
• •Two years of real Facebook chat history — about 6,000 messages, with all personal data removed and only user IDs kept — was used to learn how the real front desk sounds
• •The OpenAI account belongs to the hotel. The hotel pays for it directly and can revoke my access at any moment
• •Only anonymised user reference IDs are stored, never names, phone numbers or emails, under a data protection agreement signed on day one

From Kickoff to Production in 14 Days

The first property ran from kickoff on 9 June to production on Monday 22 June 2026.

• •Day 1: Kickoff — access opened on all 3 channels, the AI account set up, confidentiality and data protection agreements signed
• •Days 2-4: Knowledge gathering — 50 FAQs, room photos, activities and nearby attractions. The knowledge base has since grown to 82 FAQ sets in Thai and English, a room-rate table and the 688-item captioned image library, all in a sheet the hotel owns and edits
• •Days 5-7: Build — tone analysis from the chat history, the bot assembled in 4 languages, Rich Menu shortcuts installed, chat widget embedded on the website
• •Days 8-10: 35 real-world test scenarios on all 3 channels before the client saw it
• •Days 11-13: UAT with the client's own team — tone and FAQ fixes from real staff feedback
• •Day 14: Production launch on all 3 channels, with monitoring through the first 24 hours

Before go-live the client's team verified all 12 agreed acceptance criteria themselves — language accuracy, all 50 FAQs present, the Rich Menu working, leads writing correctly to the sheet, handoffs behaving as designed, all 35 test scenarios passing, and confirmation they could run the system after training. Counting every stage: the pre-sale demo bot passed 35/35, the first property's UAT passed 36/36 automated checks plus 5/5 by hand. Launch happened only once every criterion was confirmed.

What Was Harder Than Expected

Two things did not behave as designed on first contact with real guests. The staff pause was scoped too broadly at first, so pausing the bot for one conversation quieted it more widely than intended. And room availability turned out to be a question the bot cannot answer honestly, because it has no connection to the booking system — so it sends the booking link and phone number instead of guessing.

The Second and Third Properties

The second property, a riverside resort, took 7 days and went live on 21 August 2026, with the same three channels and four languages on the same structure. Only the data changed. In its first two and a half weeks it handled 374 real conversations (191 on Facebook, 157 on LINE, 26 on the website) and closed its first month at 79.0% self-service against a month-1 target of 70%. After launch the hotel team raised 168 items through the shared feedback board; 154 were fixed at the time of that count.

The third property, a floating-raft stay, went live on 11 October 2026. It opened with the bot running 10:00-18:00 and moved to 24 hours on 20 October, when the hotel decided to.

The later properties started with the first property's lessons already built in: answering availability questions without inventing data (booking link and phone number instead), following up a guest who asked for a price and went quiet, handing off in-stay requests (food orders, housekeeping, broken equipment), and recommending a sister property when a guest asks for somewhere else. Every property passes a 35-scenario test set before it opens.

The Daily Improvement Loop

Since late September 2026, every property goes through the same loop every day:

1. •Read yesterday's real chats at every property. Check every point where the bot said "I've passed this on" or "I've sent the photo" against the system's actual execution history
2. •Open a ticket for every wrong or incomplete answer. If a ticket needs a policy the data doesn't cover, ask the hotel team first — the bot does not guess
3. •Fix on a copy, and add a new test case that must fail on the old version and pass on the new one
4. •Replay the fix against more than 4,000 real chat messages and read every answer that changed
5. •Approve ticket by ticket. Anything touching prices, deposits, cancellations or bookings always needs approval
6. •Ship to all 3 properties at once, read everything back to confirm it matches what was tested, and keep the pre-change copy for rollback

One round, 7 November 2026: 69 messages reviewed, 11 tickets opened, the new test set passed 87/87, a replay across 4,221 messages found 26 changed answers — every one of them an intended fix — and the live read-back matched 18/18.

The Results

1. 91.7% handled by the bot — a number that came from admitting the old one was measured wrong

The raw "handled by the bot" reading for 24 Aug - 5 Sep was 48.2%. On its face, the system was failing. Splitting the handoffs by who started them changed the picture completely:

Across the longer 22 Jun - 28 Aug window, the bot-only figure was 96.8%. The target was 85%. The second property's first month came in at 79.0%, above its month-1 target of 70%.

The raw number was measuring staff behaviour, not bot quality. Keep the two mixed together and every decision made from the number is wrong.

2. Leads, and messages outside office hours

Every lead carries a name, a phone number, the channel and the date, ready for the sales team to call back. In a separate 13-day window (24 Aug - 5 Sep), the bot captured another 88 leads from 677 messages, and 21.9% of all messages arrived outside office hours — one in five people who reached out did so when nobody was at the desk.

3. The next property is faster

First property: 14 days. Second: 7 days, with the same channels and languages.

4. It is used, and it is improved from use

• •More than 10,900 chat messages logged across the 3 properties (to 7 Nov 2026)
• •The improvement ticket counter across the 3 properties has passed 900 since June — raised both by the hotel team on the board and by the daily chat review

5. Reliability

• •About 99.4% uptime across the first 13 days at the first property, with no blank replies in that window
• •Answers in 4 languages, with automatic fallback to English beyond the core set

Before / After

How I Work With the Hotel Team

• •The hotel owns the data. The team edits answers in Google Sheets directly; I am not a bottleneck
• •The hotel owns the policy. Answers about flooding, child pricing, travel or facilities use only wording the hotel's project lead has confirmed. When the data is missing, I send a short question with options to pick from, instead of letting the bot guess
• •A Notion issue board lets the hotel team report what needs fixing and follow the status themselves
• •Staff control the bot. During the late-September flooding, when the hotel switched the bot off, every new chat went straight to staff — and I excluded those days from measurement, because they did not measure the bot
• •Hours follow the client's decision. The floating-raft property started at 10:00-18:00 and moved to 24 hours when the hotel decided to

Privacy and Safety

• •The chat history used for learning had all personal data removed
• •Issue tickets carry no full names, phone numbers or emails — only what is needed
• •The bot takes no money, takes no bookings and does not calculate total prices (there is an explicit no-calculation rule)
• •Every change is tested on a copy first, with a pre-change copy kept for rollback. Nothing touching money or bookings ships automatically
• •Testing on a live channel sends real alerts to real staff. I once triggered a real alert during a test, so the rule now is to test with staff alerts switched off, and to delete any alert that slips through immediately

Being Honest About the Numbers

Chat volume is still modest. Roughly 5-15 people a day at the first property, so weekly percentages swing hard (80% to 93% to 71% across three consecutive weeks). I told the client this from the first report.

Two figures given at the start did not survive measurement. I correct them here rather than drop them quietly.

The cost error ran in the client's favour. The response-time miss is real: the target has not been moved to match reality, and it is still recorded as not met. The cause is the size of the prompt the bot carries, around 37,000 tokens at the median. A change that halved it was built and measured, gave no material speed-up, and was not shipped.

The chat log is a floor, not a total. At times the Google Sheets quota dropped about 14.5% of log rows, so every count is checked against the system's own execution history.

Bookings closed still cannot be measured, because the bot is not connected to the hotel's booking system. What I can state is leads captured, not bookings won.

Staff choose to step in on 84-86% of handoffs. Why is a policy question for the team, not a technical one, and the data alone cannot answer it.

What Didn't Go Smoothly

• •The bot went silent for 41 hours after a misconfigured message-receiving connection during a system edit. Real guest messages were dropped while the backend kept reporting "success". It took ruling out 9 wrong hypotheses to find the cause, then live test messages on all 3 channels to confirm the fix
• •The bot's core instructions were overwritten during a live edit, so it briefly ran without its tone or guardrails. It was caught quickly and restored from a backup, and every core prompt now keeps a dated copy outside the running system
• •The self-service rate was reported as a flat 100% for over a month because of a calculation bug: a timestamp column went blank whenever staff paused the bot, so staff interventions went uncounted. Caught, fixed, and every historical figure recalculated — every percentage on this page is a corrected one

Lessons Learned

• •A big replay catches what a small test set misses. One replay across 4,152 real messages caught 2 fixes that were too broad — one of them changed 17 answers — which a 768-message check had not found. So I read every changed answer, every time
• •"Ticket closed" does not mean "live". I check what is actually running against what was tested, every time, instead of trusting the status on the board
• •"Success" does not mean the message arrived. A fix only counts once a real message reaches its real destination
• •A metric that looks too perfect is a signal to investigate. The flat 100% sat unquestioned for a month
• •A raw percentage can be measuring the wrong subject. Splitting staff handoffs from bot handoffs turned an alarming 48.2% into an accurate 92.0%

Where It Stands (8 Nov 2026)

• •Live at 3 properties on all 3 channels (the floating-raft property has run 24 hours since 20 Oct 2026)
• •The daily review-and-improve loop runs every day; the latest round was 7 Nov 2026
• •The remaining properties in the contract will follow on the same structure

Running Several Branches and Not Sure Where to Start?

This group did not build all 16 accounts at once. It started at one property, deliberately the hardest one, and proved the formula there before going further.

The first property took 14 days. The second took 7.

If your business runs several branches and each one answers customers its own way, I can set up a system that starts at a single branch and expands from there.

Start with the hardest branch first — talk to us →