All case studies
Hero display of A Beauty Clinic AI Assistant Got an Answer Wrong — Stopped in 4 Minutes, Then Traced to Why Using 345 Real Staff Replies
AI Chatbot Case Study

A Beauty Clinic AI Assistant Got an Answer Wrong — Stopped in 4 Minutes, Then Traced to Why Using 345 Real Staff Replies

An AI sales assistant on Facebook Messenger for a single-branch beauty and weight-loss clinic, with medical-safety gates before and after the AI, PDPA consent, staff alerts on LINE and a kill switch. Three weeks after launch it told a real customer something that broke clinic policy. The owner stopped it within 4 minutes. What followed: closing a hole in the kill switch, a refund gate, and using 345 real staff replies to find that the bot's data — not its prompt — was the problem.

RoleAI Systems Architect
ClientBeauty and Weight-Loss Clinic, 1 Branch (NDA)
StatusLive 29 Jun 2026 · Stopped 17 Jul 2026
Interested?
Facebook MessengerSafety GatesPDPAn8nClaude

At a Glance

BusinessBeauty and weight-loss clinic, single branch
ChannelsFacebook Messenger (most customers come from ads) + team alerts on LINE
UsersThe clinic owner (who also examines and treats patients) and an admin
What was builtAn AI assistant that answers chats and captures leads, with medical-safety gates, follow-ups, a dashboard, and a toolkit for the owner to train the bot herself
Toolsn8n (on the clinic's own server) · Claude · Google Sheets · LINE
TimelineBuilt and delivered in 2 installments, Jun 2026 · live 29 Jun 2026 · stopped 17 Jul 2026
From wrong answer to bot stoppedReal staff replies used as the standardPregnancy gate after the fix
4 minutes345 pairs from 135 conversations (1 month)17/17 caught, 0 of 12 false alarms

This is not a straightforward success story. The bot was stopped after it gave a real customer an answer that broke the clinic's policy. I tell it because work in a clinic needs a clear answer to one question: when the AI is wrong or unsure, what happens next?

The Client

A single-branch beauty clinic that gets most of its customers from Facebook ads. Its main product sits in a category Meta restricts heavily (weight-loss pens). The owner is the examiner, the practitioner and the person answering the chat.

The Problem

From what the owner described at the start:

  1. •The owner had to answer the chat herself, because the assistant who answered couldn't close a sale. She was clicking saved replies by hand, and the same questions came round every day
  2. •Front-desk staff kept coming and going. Hired, then gone — and the load fell back on the owner
  3. •Advertising is restricted because of the product category, so every chat that comes in is valuable
  4. •Customer data kept disappearing. Staff once kept it in Excel, and that stopped when they left

The goal she set: a salesperson who doesn't quit — one that answers chats, closes sales, follows up customers who go quiet, and keeps customer records.

What I Found Before Building, and the Key Decisions

  • •The clinic's system can't be connected from outside, so the bot cannot check open appointment slots in real time. I said so in the quotation, and the bot instead collects the customer's preferred day and time for the clinic to confirm
  • •A beauty clinic carries medical and legal risk. The design rule: the AI may not promise results, state a dose, or diagnose. I did not rely on prompt instructions alone — explicit rule-based checks sit both before and after the AI
  • •The owner owns the data. Promotions, prices and answers live in a Google Sheet the clinic edits itself, and the system runs on the clinic's own server and accounts

What I Built

  1. •A safety gate before the AI. Messages about pregnancy, after childbirth, or medical questions are routed to a doctor by explicit rules. The AI never answers them
  2. •The AI drafts an answer from the clinic's own data — answering questions, explaining promotions, sending price cards and moving toward an appointment
  3. •A second check before sending. If an answer promises weight lost, results within a number of days, uses the word "guarantee", states a dose, makes a diagnosis or offers a discount that isn't in the promotion, the system doesn't send it. It sends a holding message instead and alerts the team
  4. •PDPA-compliant lead capture. Before asking for a name and phone number, the bot attaches a consent message every time. Leads go into a restricted sheet the clinic owns, and I drafted a privacy policy under Thailand's Personal Data Protection Act B.E. 2562 for the clinic to use
  5. •Team alerts on LINE for a genuinely interested lead, a medical question, a complaint, or anything a person needs to answer
  6. •Follow-up for customers who go quiet — once, within 24 hours, under Messenger's rules. After that it becomes a task for the team
  7. •A lead dashboard and Thai-language user guides for the owner and admin (a 15-topic team guide)
  8. •A kill switch. The owner can stop or restart the bot from the chat
Workflow diagram: every customer message on the left; stop, check, fix and approve on the right. Diagram labels are in Thai.Open full size

Before launch, a full 29-case test set covering every function and every promotion passed in full (24 Jun 2026), and the bot went live on 29 Jun 2026.

What Happened on 17 July 2026, and What Followed

What happened. A customer who had already paid a deposit wrote in to cancel an appointment. The bot replied that the appointment had been cancelled (it cannot do that, and had not), asked which account to refund to while citing an account the clinic no longer uses, and promised a refund — which is against clinic policy. A staff member saw it, stepped in to apologise, and resolved it by extending the customer's entitlement. The owner stopped the bot within 4 minutes.

What I did next

  1. •Tested the kill switch myself — and found a hole. Because a default value had never been filled in, any customer could have stopped the bot. I changed it to require a command with a secret code. If the setting is incomplete, the system now refuses every command rather than accepting anyone's. And the code had to be saved in exactly the right place before going live, or the owner herself would not have been able to stop the bot
  2. •Built a refund gate. The bot must never promise a refund, because the clinic has no refund policy. Passed 11/11 cases on the test copy
  3. •Used the weeks the bot was off as the standard for answers. At first I concluded, wrongly, that with the bot off there was nothing to measure. Then I saw that while the bot was silent, every reply on the page was human — the best possible record of how the team actually answers customers. I pulled one month of chats (135 conversations, 1,768 messages), extracted 345 customer-question / staff-answer pairs, and confirmed they were written by real people, not the bot

What the team's real replies showed

What was foundWhat would happen if the bot reopened unfixed
The deposit account in the bot's data was an old one; staff gave a different account in 15 of 16 deposit answersEvery online booking would be sent to a retired account
The clinic's main product had changed (weight-loss pens), but the bot's promotion data was missing sizes and packagesThe bot couldn't quote a price for the question customers ask most
The "bot dodges price questions" problem — treated as a prompt-writing issue for a month — was actually data missing from the sheetNo amount of prompt editing would fix it; the data had to be filled in
The follow-up system had twice sent customers an "internal instruction" instead of a real messageCustomers saw text they should never have seen

The pregnancy gate. Testing the bot herself, the owner found that some phrasings, such as "3 months pregnant", still reached the AI. I merged my fix with the fix her own AI had made on her machine, because each covered things the other missed. The result: 17/17 caught and 0 of 12 false alarms, deliberately making sure "slimming the belly" is not read as pregnancy — otherwise the clinic's main sales question would be routed to a doctor every time. A later fix narrowed another word that was too broad (one customers use to ask "is a staff member free?"): I first checked which real pregnancy cases that broad word was catching, then replaced it with 8 specific phrases. Result: 27/27 and 13/13. Every test ran against the code actually saved on the server, not a local copy.

Working With the Owner: Making Her Able to Run the Bot Herself

  • •A toolkit for the owner to train the bot herself — short commands to test, train, roll back, check status and request go-live, with a Thai guide and examples
  • •A test copy separate from the live bot. Every change happens on the test copy first, there is a guard against editing the live bot directly, and going live requires the owner's own approval command
  • •The best outcome of the training: the owner, who is not a programmer, was the one who found the hole in the pregnancy gate, and the AI on her own machine proposed a fix close to mine. I merged both and credited her in the fix ticket
  • •The backup handover. Before handing over, I found the backup files in the pack were an old version — restoring from them would have undone both fixes. I re-exported all 9 from the live system, and sent the credentials file separately, not inside anything that could be forwarded

Privacy and Safety

  • •A PDPA consent message before asking for a phone number, every time, and a privacy policy drafted for the clinic
  • •Leads are kept in a restricted sheet the clinic owns
  • •Medical topics are filtered out before reaching the AI, and the AI's answer is checked again before sending — two layers
  • •The owner can stop the bot instantly; ordinary customers cannot
  • •All systems and accounts belong to the clinic
  • •Reports and tickets carry no full customer names or phone numbers beyond what is needed

Lessons, and Limits I State Plainly

  • •A "dodging" answer may not be a prompt problem — it may be missing data. Check the data before editing the prompt
  • •The business's data changes faster than the bot's. The payment account changed, the main product changed, and nobody updated the sheet. Looking after an AI therefore needs periodic checks against how the team actually works — it is not build-once-and-done
  • •Testing on made-up cases is not enough. All 29 cases passed, and the real incident was a case that wasn't in the set
  • •I concluded wrongly before I concluded rightly — both on "there's nothing to measure" and on the kill switch, which I had believed expired on its own after 30 minutes until the real data showed otherwise. The lesson: open the real data before concluding from the code
  • •The honest current state: the bot is still off. More defects have been found and are waiting on the owner's decision before it reopens, and there is no measured sales outcome, so I claim none. The dashboard in the sheet contains test conversations, so I do not use it as a result

Where It Stands (8 Nov 2026)

  • •Both installments delivered, and the toolkit and guides handed to the owner (17 Aug 2026)
  • •The bot is off according to the latest records (its live state on the clinic's own server has not been checked)
  • •Before reopening, the owner needs to confirm the deposit account, fill in the missing product data, decide on the further defects found, and reopen with someone watching

Running AI Where a Wrong Answer Matters?

If your business answers questions where a wrong answer has a medical, legal or financial cost, the question to settle first is not how clever the AI is. It is what happens the moment it's wrong.

Design the stop before the start — talk to us →