Why most restaurant chatbots fail
We have deployed RAG chatbots for cafes, fine-dining restaurants, and small hotel groups across Belgium and the Netherlands. The failure mode is always the same: the bot answers a question the documentation does not actually support. A guest asks "do you have vegan options?" and the bot, hallucinating from a generic LLM prior, invents a dish that does not exist.
Three patterns prevent this. They are cheap, boring, and we ship them on every restaurant deploy.
Pattern 1: tight scope
The chatbot answers only from indexed documents. If the answer is not in the retrieval results, the bot says "I do not have that information. Let me put you in touch with the team." No generic-LLM fallback, no fabricated specifics.
Restaurants are an environment where being wrong about an allergen has real-world consequences. Tight scope is not a UX choice, it is a safety choice.
Pattern 2: source citation
Every answer includes the document or page it came from. Guests rarely click. But knowing the source exists is what makes the answer feel trustworthy, and it is a free debugging tool for the restaurant owner.
When a guest reports a wrong answer, the owner can see exactly which document chunk the bot pulled from and fix the source, not the bot.
Pattern 3: graceful fallback
A confidence drop below 0.7 triggers immediate human handoff. We would rather lose a self-service win than answer wrong on an allergen question.
The handoff message is scripted: short, in the guest's language, and warm. "I want to make sure I get this right. I am connecting you with someone from the team." Not "I am just an AI."
What this looks like in production
On a recent restaurant deploy in Hasselt, the bot hit 90% auto-resolve in week one and zero hallucinations on a 200-question audit. The 10% that escalated were genuinely things the bot should not have answered: complaints about a past visit, requests for the chef, off-menu questions.