Teaching a Small Model to Work the Front Desk
How I taught a small AI model to talk and act like a hotel receptionist — 9,500 practice conversations, five rounds of fixing my own data, and the exam the model failed.
At a glance
- What: I taught a small, free AI model to talk and act like a hotel front-desk receptionist, in Vietnamese and English. The result is free to download on Hugging Face.
- Why: CapyInn, my hotel management app, runs entirely on the hotel's own computer — so its future AI receptionist has to run there too, with no internet required.
- My role: solo. I designed the whole process and wrote the specifications; AI coding agents wrote most of the code.
- The data: 9,564 clean bilingual conversations (62% Vietnamese / 38% English) covering 40+ everyday front-desk situations.
- The honest part: on a 30-scenario final exam, the published model passed only 2 — and its download page says so, plainly. A later retrain on improved data reached 26, still below my release bar.
Why teach an AI to work a front desk?
CapyInn runs the front desk of a real mini hotel in Vietnam, and it runs without the cloud on purpose: the owner's computer, the hotel's data, nothing sent anywhere. An AI receptionist added to it has to live by the same rules. Big AI services like ChatGPT live in the cloud — guest conversations would leave the building, every question would cost money, and everything stops when the hotel wifi does.
The alternative is a small local model: an AI compact enough to run on an ordinary computer. I started from Gemma, a small free model made by Google, which compresses down to a single 3.62 GB file. A model that size can't memorize everything about a hotel — but that was never the goal. The question was whether it could learn to behave like a receptionist.
The big idea: teach manners, not facts
The most important decision came before any data was collected: train behavior, not facts. Room prices and availability change every day. If you bake today's prices into the model, next month it will recite the old ones with total confidence — and a made-up room price isn't a small bug in a hotel, it's a refund and an argument at checkout. So facts stay in the hotel's software, where they belong, and the model learns the part of the job that never changes: how a good receptionist behaves. Five habits, specifically:
- Answer directly when the question is safe and general.
- Ask a follow-up when details are missing, instead of guessing.
- Say "let me check the system" for anything about prices, availability, or bookings.
- Hand off to a human for complaints, refunds, and anything risky.
- Politely decline requests that are out of scope or unsafe.
More than half of all the training examples teach the middle habits — knowing when not to answer. That is deliberate. In a hotel, restraint is the skill.
The hard part was the data
An AI model learns from examples: thousands of sample conversations that show "when a guest says this, a good receptionist responds like that." No such collection exists for Vietnamese boutique hotels. The public datasets I found were a mess — broken template text shipped as answers, conversations labeled Vietnamese that were actually English, and replies that confidently invented hotel policies out of thin air.
And the thing I needed most can't be downloaded at all: the warm, natural voice of a Vietnamese receptionist — "Dạ, để em kiểm tra giúp mình nhé" — polite without being stiff. That voice had to be created, checked, and re-checked into existence. Here is what one finished training example looks like:
{"messages": [
{"role": "user", "content": "Phòng mình còn trống cuối tuần này không em?"},
{"role": "assistant", "content": "Dạ để em kiểm tra lịch phòng trên hệ thống giúp anh nhé. Anh cho em xin ngày nhận phòng và số đêm dự kiến với ạ?"}
],
"lang": "vi", "intent": "check_room_availability", "route": "needs_system_check"}A guest asks if a room is free this weekend. The receptionist doesn't guess — she warmly says she'll check the system and asks for the dates. That exact habit, repeated across thousands of examples, is what the model learns.
A factory for conversations
I built the dataset the way a factory builds products — an assembly line with a quality check at every station:
- Automatic filters throw out the obvious garbage first. Every rejected conversation is saved with the reason, so nothing disappears silently.
- An AI writer rewrites usable English examples into natural hotel Vietnamese, and writes brand-new conversations for situations the collection still lacks.
- An AI grader — a second, separate AI — scores every conversation against a checklist. Failures go back for repair, not into the pile.
- My own review. I read sampled batches myself in a review tool and rejected what the machines missed.
- Final packaging: near-duplicates removed, the data split carefully so the final exam never overlaps with the study material, and every release ships with its statistics.
The current release holds 9,564 clean bilingual conversations — 62% Vietnamese, 38% English — covering more than forty situations, from check-in and housekeeping to refund complaints and guests trying to trick the AI.
Five versions of being wrong
The data went through five major versions, and every version exists because I caught the previous one being wrong somewhere:
- Conversations labeled Vietnamese that were actually English — so I added an automatic language check on every single example.
- Labels that lied: an example tagged "check the system" whose reply quoted a price anyway — so a rule now reads every reply and verifies it does what its label promises.
- The AI writer quietly inventing hotel policies — so its instructions were tightened until it had no room to improvise facts.
- The duplicate-removal step deleting too much: different phrasings of the same request are useful variety, not noise — so its strictness was tuned by hand.
- A caching shortcut that could silently reuse outdated results after a failed run — so the cache now invalidates itself whenever instructions change.
None of these are exotic AI problems. They are careful-checking problems, and each one now has a permanent automatic guard so it can't come back.
The exam the model failed
Training was the easy part. I took Google's Gemma model and gave it extra lessons on my data — a process called fine-tuning — first on Google's research computers through a free grant, later on a rented GPU. By the standard measure of training, it went well: the model got steadily better at imitating the example conversations.
Then came the real exam. Fixed30 is a set of thirty scripted front-desk scenarios — normal requests, tricky requests, requests it should refuse — checked against the habits the data was supposed to teach. The model passed 2 of 30. It struggled most with housekeeping requests and lost-and-found situations, where it wandered off script instead of following its training.
Here is the lesson worth taking away, in plain terms: the training numbers said the model was doing great, and the exam said it couldn't do the job. Both were measuring the same model. Training scores measure how well an AI imitates its examples; only a real test tells you whether it can work. At a front desk, only the second one matters.
I published the model anyway — on purpose. It proves the whole pipeline works end to end, it's useful for anyone experimenting with local AI, and its download page says exactly what it is: a preview that must never make real booking, payment, or refund decisions. Shipping the model together with the truth about it felt more honest than shipping neither.
And the failing grade is where the factory proved its worth. Two data versions later, a retrained model took the same exam and scored 26 of 30, with zero serious failures — from 2 to 26 purely by fixing the data, not the training. That one still sits below the bar I set for release (95%, or 29 of 30), so it stays in the lab while version 5.11 of the data repairs the four remaining weak spots ahead of the next run.
What's next
- The exam now gates every release. The test that failed the first model was built after its training. It has since become the gate: the retrain that scored 26 of 30 stays unpublished, because close to the bar is not the bar.
- A bigger, better exam. Thirty scenarios were enough to say "no", but not enough to say exactly why. Version 6, in progress, pairs a smaller hand-audited dataset with a much larger test.
- Keep the factory. The data improved through five versions precisely because every reject was kept, every reason was logged, and every step could be re-run. That machinery — not the model file — is the real asset.
The end goal hasn't changed: this receptionist, built into CapyInn, greeting guests at a real front desk — with the hotel's software, not the AI's memory, holding the facts.