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

The Client

A specialist medical and aesthetic clinic with 2 branches and a third opening, taking payment through several channels at once — cash, payment gateways, cards through banking apps, and e-wallets.

The difficulty is that every channel reports differently. Some do not report daily. Some are up to a week behind. And no two of them share a cut-off day.

So the accounts team could not reconcile receipt by receipt. They reconciled in weekly lumps instead — a state the owner described in her own words as:

"Risky, and possibly not trustworthy."

The Challenge: 956 Lines, but Only 591 Real Receipts

Before quoting, 18 days of the clinic's real export were requested — and actually read, line by line, rather than skimmed.

The report comes out per line. Everyone totals it as though it were per receipt. The file held 956 lines representing 591 actual receipts, because one customer buying several items produces several lines. 192 receipts occupied more than one line — the longest ran to seven — and the payment amount is reprinted identically on every line of the same receipt.

Anyone who drags a SUM down that column gets an immediately inflated number:

The channel labels cannot be trusted either. The channel holding the most money — 5.3 million baht — was tagged "bank transfer". The report that provider actually sends is a credit card report, with merchant fees and card types spelled out. Meanwhile the clinic system's own credit-card fee column was zero across all 738 receipts.

The client spotted this herself, sitting and going through the file together, and annotated her own copy: "check the channel mapping — this one is a card."

The lesson became a design rule: never build any rule that trusts a channel label.

There is no shared key between the two systems. This was the single biggest technical obstacle:

No field joins those two together. Matching has to lean on date plus amount, which cannot be perfectly accurate by its nature.

Data that looks like money and is not. The same review turned up entries that skew the total the moment they are counted:

What it costs to leave alone. A revenue figure inflated by 135% does not stay in a file. It is the number used to decide on a third branch, to assess how the team is performing, and to talk to the bank. The longer it is used, the harder it is to unwind.

The Price Went Up and Then Down, and Why the Reduction Was Offered

The client arrived with a clear problem and set the priority herself in one sentence: "receipts first."

Why build a system rather than hire another person:

1. •She wanted AI on the mechanical work and people left for the exceptions — her words: "put a process in with AI at certain points, and let the team fix the points AI cannot do."
2. •She was more worried about coverage than price — "I am afraid it will not cover everything. Is there anything touching the bank side that still needs doing?"
3. •She wanted somebody who would advise back, not just take orders — "if anything is not covered, I would like you to recommend it too."

Three Things Found in the File That Made the Scope Smaller, Not Bigger

Reading the real data did not produce a bigger sale. It shrank the job in three places, and all three were reported:

One — there are 5 channels to handle, not 10 to 20. The client was worried she had 10 to 20 payment channels, which would make the job large and expensive. In the real data, most of those columns are zero from top to bottom. Only 5 channels carry actual money. She was told the quoted price already covered every channel in real use, and that it would not rise with the number of columns.

Two — connecting to the accounting software was cheaper than quoted. One tab in her own file was an import template for the accounting package, already filled in with 1,245 rows. That meant no system integration was needed at all — just producing a correctly formatted file. That line of the quotation was reduced.

Three — the accuracy figure was given before the sale, not after. Because there is no shared key between the two systems, the match rate was measured against her real sample and stated plainly up front: roughly 75-90%, with the remaining 10-25% needing a person to check. And it was also stated that the sample used to measure it was only about 30 rows, so it could not yet be treated as a final number.

The Price Moved Four Times, and the Client Moved It

What her messages actually said: she was not rejecting the full-scope price. She was afraid of a total with no ceiling.

So the right answer was not a discount. It was a ceiling. A cap for all three phases was written into the quotation rather than mentioned loosely in chat — so if phase 2 turns out harder than a 30-row sample suggested, that is a scope conversation, not a price rise.

Her reply: "Then let us do this together."

The Solution: Count the Money at the Receipt, Not at the Line

One idea holds it up: collapse the data at the receipt number, then have the system prove itself every day by adding the per-channel amounts back up and comparing them to that receipt's total.

If they stop matching on any given day, something upstream has changed — and the system reports it itself, rather than waiting for a person to notice.

The Plan, in Seven Working Days

The Technical Decisions

What Was Delivered

1. •A reader for both report formats
2. •A line-to-receipt collapser with duplicate detection
3. •A per-channel versus receipt-total check, on every receipt
4. •A channel classifier plus four exclusion rules
5. •Five report views across seven tabs — daily, clean, exceptions, channel-label mismatches, and a monthly archive
6. •A daily summary into the team chat
7. •A 109-case test suite

The Results

1. The revenue figure being used to make decisions was overstated by 135%

The clinic had been totalling straight from its own system's report. Analysis of 18 days of real data found the number inflated by 135% — 21.4 million against a real 9.1 million.

That is the same number used to assess performance, to plan a third branch, and to talk to the bank.

2. Verified by checking every qualifying receipt, not a sample

Collapsing lines into receipts is only safe if the payment amount really is repeated identically on every line.

So all 192 receipts with more than one line were checked, and 0 exceptions were found.

The new figure is not an approximation. It comes from a rule proven against the entire set of real data.

3. The clinic's software vendor shipped a new feature within 3 days

At the start of the project the vendor had no scheduled export and would not give a timeline.

After the issue was escalated with evidence that the channel data was incomplete, the vendor released gateway-level fields within 3 days.

The clinic gets permanently better data at no extra cost — and so does every other customer of that vendor.

The Story That Almost Became the Headline, and Why It Was Cut

The client asked whether any receipts had a payment amount that did not match the value of the items.

The first pass found 14 receipts totalling 4,142,175 baht that did not match — a number large enough to lead the whole report.

But it was re-checked before sending, and it collapsed entirely:

From 4.1 million, down to 2 receipts.

The 4.1 million figure was thrown away and only the 2 provable receipts were reported — and that caution became the selling point instead of the headline.

A big number that has not been re-checked is not a discovery. It is a debt that comes due the moment the client checks it themselves.

A Note: the Bug This Project Exists to Fix, Caught by Measuring Itself

On another day of data, collapsing the lines turned 45 lines into 32 receipts and matched the payment total of 458,218.00 baht exactly.

On that same day, a straight column sum inflated one gateway by 3.2 times and the banking app by 1.9 times.

Voices From the Project

"Risky, and possibly not trustworthy."

— The owner, describing her own existing reconciliation process

"Put a process in with AI at certain points, and let the team fix the points AI cannot do."

— The owner, setting the scope

"She was not rejecting the price — she was afraid of a total with no ceiling. So the answer was a ceiling, not a discount."

— The decision note, written when the cap went into the quotation

Lessons Learned

• •Read the client's real export before quoting, not after winning. Eighteen days of real data shrank this job in three separate places and cut a line off the quotation — and it also produced the finding the whole project now rests on.
• •A report that prints per line will be summed per line by somebody. The payment amount repeated identically down every row of a receipt is not a bug in the source system, but it guarantees that a spreadsheet total is wrong, and nothing anywhere says so.
• •Never write a rule that trusts a label. The channel holding the most money was labelled a transfer and was actually card, and the fee column that should have proved it was zero on all 738 receipts. Mismatches got their own report rather than a quiet correction inside the system.
• •A big number that has not been re-checked is a liability, not a finding. Fourteen receipts worth 4.1 million became two receipts under a second pass. Reporting the 4.1 million would have been the most impressive and the most expensive thing in the project.
• •Give the accuracy range before the sale, with the size of the sample it came from. There is no shared key between the two systems, so a perfect match rate was never possible — saying 75-90% up front, measured on about 30 rows, is worth more than a precise-sounding number nobody can stand behind.
• •Deduct at the right layer. E-wallet deposits are counted in the source system's totals, so removing them at the checking layer instead of the reporting layer would have failed every receipt that used a deposit.
• •A ceiling answers a fear that a discount does not. The client was not resisting the price; she was resisting an open-ended total. Writing the cap into the quotation rather than saying it in chat is what closed it.

Not Sure the Sales Figure You Are Looking At Is Real?

If any of these describes your business, the number you are working from may be more inflated than you think:

• •Your system exports per line, and you total the whole column
• •One customer buying several items on one bill is normal for you
• •You take money through several channels, and each report arrives in a different format on a different cycle
• •Month-end closing runs a week late because the totals never agree
• •The accuracy of your numbers depends on one member of staff

Send a month of your export and we will tell you what the real figure is.

Talk to us →