Restaurant enquiries have a peculiar timing problem. The phone gets answered during service. Badly, in a rush, by someone who's also running food. And the website gets visited at eleven at night, by people deciding where to eat tomorrow, when nobody is answering anything at all.
The result is that the two busiest enquiry channels are both handled worst at exactly the moment they matter.
What people are actually looking for
Sit with a restaurant's website analytics and the intent is obvious. People land, and within thirty seconds they want one of four things:
The menu, in a form they can read. Frequently a PDF that doesn't open properly on a phone. This alone loses bookings.
Whether you're open, and until when. Especially on bank holidays, when your Google listing and your website disagree.
Whether they can get a table. For tomorrow, for Saturday, for eight people.
Whether you can accommodate something. Vegan, gluten-free, a highchair, a dog, a large group, a birthday cake.
Every one of these is answerable from content you already have, and every one goes unanswered between the end of service and mid-morning.
The menu question is bigger than it looks
A chatbot that can actually answer questions about the menu (rather than pointing at a PDF) resolves a surprising amount of decision friction.
Diner: Do you have anything substantial that's vegan? My partner doesn't eat dairy either. Bot: Yes, the roasted celeriac with hazelnut and the wild mushroom orzo are both fully vegan as they're served. The flatbreads can be made without the yoghurt too. If you let the team know when you book, the kitchen will flag it.
That's a booking that might otherwise have gone to whichever restaurant had a clearer website. And it took no staff time at all.
Allergens: useful, but with a hard limit
This needs care, because it's the one area where a wrong answer has real consequences.
A bot can state what your published menu and allergen matrix say. It should not be the final word on whether it's safe for someone with a serious allergy to eat with you, because that depends on kitchen conditions, preparation surfaces, and what's being cooked that night. None of which is in any document.
Configure it explicitly: state the published information, then always add that anyone with a serious allergy should tell the team when booking and again on arrival so the kitchen can advise directly. And route anything that sounds like a severe or anaphylactic allergy straight to a person rather than answering at all.
That's not hedging. It's the same thing a well-trained front-of-house would say.
Capturing the booking
Unless you've connected live availability, the bot's job is to capture, not confirm:
- Date and time
- Party size
- Any dietary requirements or access needs
- Occasion, if there is one
- Name and phone
Then be clear: someone will confirm. That's still dramatically better than a voicemail left during service that nobody plays back until Thursday.
The occasion field is worth including for a commercial reason. Birthdays and anniversaries are your upsell, and knowing about them in advance is the difference between a table and a bottle of something plus a dessert with a candle.
Private events are the real prize
Here's where a restaurant chatbot earns money rather than saving time.
Private dining, large group bookings, catering, and Christmas parties are worth many multiples of a normal cover. They arrive through the same website. And they routinely sit unanswered for days because the enquiry went to an inbox nobody owns.
A bot should identify these immediately (anything over a certain party size, anything mentioning an event, anything asking about exclusive hire), capture the date, headcount, budget indication, and requirements, and route it to whoever actually handles events.
Christmas party enquiries start arriving in late September, through a generic contact form that a manager checks weekly. Routing them separately, with the details already captured, tends to fill December considerably earlier than usual.
Tourists and language
If you're near a hotel, a station, or an attraction, a meaningful share of your traffic isn't local and isn't reading in English.
A bot that detects and replies in the visitor's own language removes a real barrier. Someone reading your menu in their second language is far more likely to book somewhere they were able to ask a question. It costs nothing to enable and it converts traffic you're currently getting no value from.
What it has no business doing
Don't let it confirm a table it can't see. Don't let it promise a specific server or a specific table. Don't let it improvise about dishes that aren't on the published menu. Specials change and a bot describing last week's is worse than saying "ask the team".
The practical setup
Point it at your website. If your menu is a PDF, upload it as a document too. That's the single highest-value thing you can give it. Add your opening hours including holiday variations, your allergen matrix, and your private dining information.
Set the capture fields above, add the allergen escalation rule, and set a party-size threshold that routes to events.
The numbers worth tracking
Booking requests captured outside service hours, and event enquiries routed within a day rather than a week. In a business with thin margins and perishable capacity, an empty table on Saturday that could have been filled by a midnight enquiry is the most expensive thing in the room.