AI Concierge Across a Regional Hotel Group — 370 Leads, 92-96.8% Self-Service, Second Property Live in Half the Time

The Client

An occupational safety and health training institute in Bangkok, running more than 28 certified courses — safety supervisor and technical safety officer programmes, safety committee training, fire and evacuation, first aid — with 36 specialist instructors, delivered both as public and in-house training.

The chat assistant went live after a 7-day build. Everything worth telling started afterwards.

The Second Set of Problems: The Ones Nobody Knew Existed

The first set of problems was the set everyone knew about before the project started — staff retyping the same course-schedule answers every day, enquiry details scattered through chat threads.

The second set was the one nobody knew existed until somebody went and looked.

The bot made promises on behalf of people who were not in the room. One month after launch, the team reported that the bot had been telling customers it would "call back within 15 minutes". Nobody called back within 15 minutes, and customers complained. The bot was not wrong on any fact — it had committed the staff to a deadline written into its instructions by someone who would not be the one keeping it. The sentence was removed and replaced with an acknowledgement that promises nothing it cannot control.

Ten more items came out of that same meeting: the bot offering to send certificates and course materials it did not have, ignoring a phone number a customer had just typed, asking again for details the customer had already given, and still quoting April's schedule in May.

"Mostly it is the going-round-in-circles. There is a problem now, and the customers get confused."

— The client's operations lead, one month after launch

The core complaint was never that the bot said false things. It was that the bot repeated itself until customers gave up.

The leads the system "captured" but did not capture. Lead capture worked from day one. Over one 14-day window it recorded 6 rows. Reading every real conversation from that same window found 16 customers who had given contact details, and 15 of them had no row in the system. The system was working. Its capture rule was simply too narrow, and nobody could tell, because nothing ever errored.

Staff alerts that went silent with no signal. The messaging platform allows 300 free outbound messages a month. The system was using around 12 a day — so it ran out around the 17th of every month. From then on, staff alert cards were simply not delivered, with no error anywhere. Staff did not know a customer was waiting.

The bot silenced by its own closing line. The bot's own sign-off sentence was setting the "pause the bot" state, and every new customer message renewed it. The worst case: a customer sent 15 messages over 133 minutes and received no reply at all. One of them read "quotation please... urgent".

Why this set is the dangerous one. The real risk in an automated system is not that it stops working. If it stops, everyone knows within the hour.

The real risk is that it works 95% of the time and fails the other 5% in silence — no alarm, no error, and nobody finds out until a customer complains, or never.

Why They Stayed — and Why the Price Went Down

The client asked for an ongoing maintenance arrangement themselves, one month after launch. Three months later it was restructured onto an annual footing — and that restructure cut the maintenance fee by 44%.

The reason was plain: the system had become stable enough that it genuinely needed less work. Rather than let an old price keep running against a smaller workload, the price was cut to match.

One working habit changed at the same time. Instead of the team collecting problems for a monthly meeting, they now screenshot anything odd straight into a shared chat the moment they see it — because people lose the context of what they saw within hours, and a month of saved-up detail arrives as a month of lost detail.

The Solution: A System That Finds Its Own Problems

Silent problems have to be hunted. They will not report themselves, and waiting for the client to complain means the only failures you ever fix are the ones a customer was annoyed enough to mention.

The maintenance method. Roughly every two weeks, every real conversation in the window is read, failures are grouped, anything that is correct-by-design is set aside, and what remains is ranked by how often it happens and how much it costs. Across the five months this ran about 17 rounds over roughly 24,800 real conversations. Every round ended with a list of problems nobody had reported.

A decision the client did not have to pay for. The alert quota ran out every month. There were two ways to fix it: have the client upgrade their messaging package, or move the alerts somewhere else. The alerts were moved to a free, unlimited channel instead. Running cost stayed where it was.

The system did not stand still. It grew from 36 steps at handover to 95 — nearly three times the machinery in five months — while the client paid the same maintenance fee, and then 44% less.

The Results

1. 96.5% handled without a human, returning 2.4 times its upkeep

Measured across 1,788 real messages over 14 days, against targets agreed up front of 70% in month 1 and 85% by month 3.

At the hourly rate the client confirmed themselves, the time saved is worth about 2.4 times what the maintenance costs — measured from real data, not estimated.

What 96.5% means — and what it does not

It counts one failure mode only: the bot going in circles until a person has to step in. That was the definition agreed with the client at the start.

It does not mean the bot is right 96.5% of the time. If the bot answers badly and the customer gives up, that conversation still counts as handled. In this same window, the conversation review found 11 more answerable questions — price, schedule, venue — that were handed to a person and do not appear in the 96.5% at all.

And 57.4% of users in that window still ended up talking to a person, through 116 deliberate, designed handoffs. All of them are correct behaviour today. All of them are also work that could still be automated.

The heaviest day in the window carried 299 messages and four repeat loops, dropping that day to 86.2% — the same day the schedule-repeat bug and the duplicate lead rows appeared. The volume spike and the looping were one problem, not three.

2. Leads: from 6 to 23

Lead capture had run since day one. In one 14-day window it caught 6 rows, while 16 customers had actually left their details.

After the capture rule was widened:

• •23 leads from 22 customers, with no junk rows, plus a fallback path that caught 11 more cases
• •Customer-stated dates captured rose from 16 to 89 — 5.6 times
• •384 previously mis-saved phone numbers repaired

The missing leads were invisible because nothing errored. They were found by reading the real conversations, not by waiting for a report.

Before / After — Five Months

Being Honest About the Numbers

Reporting only the best figures costs more credibility than it buys. The other side of this project:

• •50 issues in five months. This is not a system with no problems. It is a system with somebody hunting its problems.
• •3 of them had to be fixed twice, because the first fix was incomplete.
• •The measurement itself was wrong twice in one day — first too high (a dead input read as a flat 100% for six straight weeks), then too low (a wrong definition read as 42.6%) before the correct 96.5% was established. Neither wrong figure was ever sent to the client.
• •Response speed still misses the original target. The first target was under 5 seconds; the measured median is 8.3. The target was openly re-set to under 15 seconds rather than reported as a pass.
• •The next reading will go down, and that is good news. The repeat-detection added recently will start catching cases that previously slipped by uncounted. Failures that used to be invisible will begin to register, so the number will fall without the bot getting any worse.

Lessons Learned

• •A system that reports success has not necessarily done anything. Lead capture ran clean for months while catching roughly one customer in three, because a too-narrow rule is not an error — it is just quiet. Anything that is supposed to collect data now gets checked against the raw conversations, not against its own status.
• •A free quota is a silent deadline. Staff alerts died on the same day every month because a platform limit was reached, and nothing anywhere said so. Any dependency with a monthly cap now gets either a counter or a channel that has no cap.
• •A bot should never promise something a human has to keep. The single most damaging sentence in five months was an offer to call back in 15 minutes, written by someone who was not going to make the call.
• •Measure the thing, then question the measurement. The same metric read 100%, then 42.6%, then 96.5% in the space of a day. A number that looks perfect deserves more suspicion than a number that looks bad.
• •Say what the number does not cover. Publishing 96.5% without saying it counts only one failure mode would be technically true and practically misleading — and the first person to find the gap would be the client.
• •A maintenance fee should follow the workload down. When the system stabilised and genuinely needed less attention, the fee was cut by 44% rather than left running at its original level.

Already Have a Bot, but Not Sure It Still Works?

Automation that fails silently can only be found one way: by opening it up and reading what really happened.

This client had 15 of 16 leads falling through, alerts going dead halfway through every month, and a customer who sent 15 messages without an answer — and not one of those things ever raised an error.

If you have a bot or an automated process that has been running for a while and you are not sure it is still doing all of its job, it can be checked.

It starts by reading the real conversations — talk to us →