Restaurant Chatbot: What to Automate and What Not

A narrow band of questions, asked constantly

Unlike most sectors, a restaurant's inbound questions are highly repetitive: is there a table, what time do you close, do you have parking, is there a children's menu, can we bring a cake. Perhaps fifteen questions account for the overwhelming majority of contacts.

They also arrive at the worst possible time. The phone rings during service, when the person who can answer it is carrying plates. A message at eight in the evening asking about tomorrow's availability competes directly with the guests already in the room.

That combination — few distinct questions, high volume, terrible timing — is close to ideal for automation. The caveat is that two of the fifteen carry real risk, and they are covered separately below.

Reservations: live or not at all

A reservation confirmed against stale data is worse than no reservation, because the guest arrives expecting a table. This is the one place where indexing is not an option.

1. 1Check availability live, alwaysTable availability must come from the booking system at the moment slots are offered. If that connection is not possible, the bot should collect the request and state clearly that it is a request rather than a confirmation.
2. 2Collect the four fields that define a bookingDate, time, party size and a contact. Everything else — high chair, window table, occasion — is preference and belongs after the booking is held, not before.
3. 3Ask about the occasion, onceBirthdays and anniversaries change what the restaurant does, and guests answer happily. One question, asked after the slot is secured.
4. 4Confirm concretelyDate, time, party size, the name it is under, how long the table is held and the cancellation courtesy. Vagueness here produces no-shows and disputes at the door.
5. 5Make cancelling and changing trivially easyA restaurant would far rather receive a cancellation than a no-show. Hiding the cancel path converts one into the other.

Safe to automate

• Opening hours, including holiday exceptions and last orders, which is the most asked question and the most frequently out of date.
• Location, parking, accessibility and how to find the entrance.
• Whether children are welcome, whether there is a children's menu and whether high chairs are available.
• Group size limits, private areas and whether the restaurant can be booked exclusively.
• Dress code, if there is one, and whether pets are allowed.
• Payment methods, whether service is included and whether vouchers are accepted.
• The menu as published, with prices, and whether it changes seasonally.
• Whether takeaway or delivery exists and through which service.

The allergen boundary

This is the question that must never be answered casually, and it is asked constantly. A wrong allergen answer is not a service failure — it is a safety incident, and the fact that a chatbot said it does not reduce the restaurant's responsibility.

• The bot may state the published allergen information for a dish, quoted exactly from the restaurant's own documentation, and nothing beyond it.
• It must not infer. 'It probably does not contain nuts' is an unacceptable sentence in this context, and inference is exactly what a language model does by default.
• It must never confirm that a dish is safe for a specific person or condition. Suitability is a judgement that involves kitchen practice and cross-contamination.
• Any conversation mentioning an allergy, intolerance or dietary restriction with a medical dimension should offer a person, with the restaurant's own wording.
• If the published allergen material is incomplete, the bot should say so rather than fill the gap. An honest 'I cannot confirm that — let me put you through' is the correct answer.

Write this section as material rather than as configuration, in every language the restaurant serves, and have whoever is responsible for food safety approve the wording. It is the one part of a restaurant bot where the review matters more than the technology.

Where a person must answer

• Allergen suitability, as above, without exception.
• Large groups and events, where the price, the menu and the room are negotiated rather than published.
• Any complaint about a meal or a visit, immediately and without qualifying questions.
• Special requests that affect the kitchen: off-menu dishes, timing around a performance, a cake brought in.
• Anything about a bill already paid or a dispute at the table.
• Press, partnership and supplier enquiries, which should be answered with the right address rather than a conversation.

What to measure

1. 1Bookings taken outside service hoursThe clearest value in this sector. These are the bookings that previously went to whoever answered the phone first, which was often somebody else.
2. 2Calls during serviceBefore and after. The operational benefit of a restaurant bot is felt by the floor staff, and this is how it shows up.
3. 3No-show rate on bot-taken bookingsCompared with phone bookings. If it is higher, the confirmation is too vague or the reminder is missing.
4. 4Allergen escalation countThis should be non-zero. A bot that never escalates an allergen question is answering them, which is the failure this section exists to prevent.
5. 5Repeat-question distributionWhich questions are still being asked most. In restaurants this list is short and it tells you exactly which material to fix first.

How Vexvon works for a restaurant

The bot answers from the knowledge base — your site crawled to as many as 4,500 pages, PDFs up to 25 MB for menus and allergen sheets, and manual or bulk entries at up to 200 per request. Entries are typed into thirteen categories including opening hours, branch, pricing and campaign, so a holiday schedule or a seasonal menu can be swapped without touching anything else.

Availability is the value that must not be indexed, and does not have to be: your booking system can be registered as an API tool the agent calls mid-conversation. When the lookup fails, the defined behaviour is to say it could not be checked rather than to confirm a table — which is exactly the rule the reservation section above requires.

For the allergen boundary the relevant mechanisms are the ones that stop rather than extend: there is a defined fallback when no context is found, so the bot says it cannot confirm rather than inferring; a request for an operator raises a notification; and answer transparency records which entry produced a reply, so an allergen answer can be traced to the document it came from.

Channels share one customer record, so a guest who messaged on Instagram and later called is one record. Language is detected per message, which matters for a restaurant serving visitors as well as regulars, and a lead or booking request reaches the team as a Telegram notification with a Start button.

Frequently asked questions

1. 1What should a restaurant chatbot handle?Opening hours and holiday exceptions, location and parking, children and high chairs, group limits, dress code, payment methods, the published menu and takeaway options — plus reservations, provided availability is checked live.
2. 2Can the bot confirm a table?Only against a live booking system. If that connection does not exist, it should take a request and say plainly that confirmation will follow, rather than using the word 'confirmed'.
3. 3How should allergen questions be handled?The bot may quote published allergen information exactly and nothing more. It must never infer, never confirm a dish is safe for a specific person, and should offer a person whenever an allergy is mentioned.
4. 4What must always go to a person?Allergen suitability, large groups and events, complaints, special kitchen requests, billing disputes, and press or supplier enquiries.
5. 5How do you reduce no-shows?A concrete confirmation naming the date, time, party size and how long the table is held, plus a reminder and a cancellation path that is easy to find. A restaurant would rather have a cancellation than a no-show.
6. 6Which metric matters most?Bookings taken outside service hours, together with calls during service. Those two numbers are where a restaurant bot either earns its place or does not.

Write down your fifteen questions

Ask whoever answers the phone to list the questions they get most, in order. In a restaurant this list is short, stable and almost entirely factual. It is your bot's specification, it takes twenty minutes to produce, and the two entries on it that carry risk will be obvious immediately.