The seven most common are: letting AI take bookings it can't see the floor plan for, having no rules for large parties, sending reminders guests can't act on, losing special requests between chat and kitchen, auto-posting review replies, replies that expose or argue with guests, and using AI to filter who gets asked for reviews. Each is fixable with rules, not new software.
Most of these share one cause: the AI was switched on before anyone wrote down how the restaurant actually runs. A good host knows the corner table is held for a regular, that the kitchen can't do fourteen covers at 8pm on a Saturday, and that a review mentioning "my wife's birthday" deserves a personal reply. None of that reaches an AI unless someone types it in.
1. Letting AI take bookings it can't see the floor for
The mistake. An AI phone line or website chatbot takes reservations, but it isn't connected to the live table plan, or it reads a simplified version of it. It sees "two tables free at 7:30" without knowing that one is a four-top held for a regular and the other is next to the kitchen door and only used when full.
How it shows up. A Friday night: the bot books a table of four at 7:30 through a calendar-style availability feed. The host has already promised that table to a walk-in regular. One party waits at the bar for 35 minutes, and the other leaves a review about it.
The fix. Either the AI books through your reservation system with the same rules your hosts use (table combinations, held tables, turn times), or it takes requests that a person confirms. Reservation platforms such as OpenTable, Resy and SevenRooms are where those rules live; SevenRooms has its own built-in AI features, and several third-party voice agents connect to the main platforms. Ask any vendor to show a booking landing in your real system with the right table and duration. For the phone side in particular, see whether AI can answer the phone and take restaurant reservations.
Watch out for two booking systems running at once, such as a new AI tool with its own diary alongside your existing platform. Double bookings are almost guaranteed.
The same mistake in a small place with a paper diary. A 30-cover café-bistro that takes bookings in a book by the till has no live system for an AI to read. That is fine, as long as the AI is set to request-only: it collects the name, number, party size and preferred time, tells the guest a person will confirm within a set window ("by 11am tomorrow"), and sends the request to a phone the owner actually checks. The mistake is letting it say "you're booked" when nobody has looked at the book.
A quick test before trusting any AI booking channel: make, move and cancel a test booking through it, then check each change in the reservation system within a minute. Then try to book a held table, a time after last orders and a table combination the system shouldn't allow. If any of those go through, the AI is working from a simplified feed, not your real rules.
2. No rules for large parties and exceptions
The mistake. The AI is told how to book a table, but not when not to. Large groups, set menus, private hire, prams and wheelchairs, the dog-friendly corner: exceptions are where a restaurant's real rules sit.
How it shows up. The chatbot confirms a party of 14 for 8pm on a Saturday because 14 seats were technically free across four tables. The kitchen can't send 14 mains together at peak, the tables aren't next to each other, and nobody asked for a deposit.
The fix. Write the exceptions as rules. A filled-in example for a 60-cover restaurant:
BOOKING RULES FOR AI (updated 1 September)
- Parties of 1-6: book directly if the system shows a table.
- Parties of 7-10: book directly only Sun-Thu. Fri-Sat: take a
request; manager confirms within 4 hours.
- Parties of 11+: always a request. Mention set menu options and
that a deposit applies.
- Last booking: 9:15pm. Sunday lunch sittings: 12:00, 12:30,
2:30, 3:00 only.
- Hold tables 12 and 14 for walk-ins Fri-Sat. Never book them.
- Wheelchair users: book table 3 or 8 (step-free, wide aisle).
- Dogs: terrace tables only; say so before confirming.
- Birthday cakes from outside: allowed, $2 per head service fee.
Say so before confirming.
- Anything else unusual: take a request, don't improvise.Your reservation platform may enforce some of this for you: OpenTable, for example, lets restaurants set booking policies that require a credit card or deposit for certain bookings, such as larger parties or busy shifts. Make sure the AI tells guests about those requirements before they commit, not in a surprise email afterwards.
With the rules loaded, a large-party enquiry should go something like this illustrative chat:
Guest: Hi, can I book for 12 this Saturday at 8? It's a leaving do.
Bot: Thanks for thinking of us for the leaving do. For groups of
11 or more, our manager confirms each booking personally so
the kitchen can plan. On Saturdays large groups choose from
our set menu, and a deposit applies. I'll send your request
now: 12 guests, Saturday, around 8pm. What name and mobile
number should the manager use? You'll hear back within 4
hours, and until then the booking isn't confirmed.It mentions the set menu and the deposit before the guest commits, and it says plainly that nothing is booked yet. The one thing to check in testing is the last sentence: bots trained to be helpful often drop "isn't confirmed" and end with "See you Saturday!", which the guest will reasonably take as a yes.
A realistic slip even with rules. The rules above say "parties of 11+: always a request". A guest books two tables of six, ten minutes apart, under two names, for the same party. The AI has no way to know. Your hosts do, once they see two sixes at 8:00 with the same surname or phone number, which is why the manager's morning scan of the day's AI bookings matters as much as the rules. It takes five minutes and catches most of these.
Watch out for rules going stale. The terrace closes for winter, a new set menu starts, the private room is booked out for December. Every change of this kind needs a named person to update the AI's rules on the same day, or the bot keeps booking last season's restaurant.
3. Reminders that guests can't act on
The mistake. Either no reminders at all, or automated reminders that make cancelling harder than not turning up. A text that says "Reply STOP to opt out" but gives no way to cancel or change the booking teaches guests to ignore it.
How the numbers look, as an illustration. A 50-cover bistro books about 90 covers on each Friday and Saturday night. With an 8% no-show rate, that is about 7 empty covers a night. At an average spend of $45, roughly $315 a night, or around $2,500 across the month's eight peak nights, before counting wasted prep.
Now add a reminder the day before with two buttons, "Confirm" and "Can't make it", and a waitlist. Suppose no-shows fall from 7 to 4 a night because three parties cancel in advance, and two of those three tables are resold from the waitlist. That recovers about $90 a night, or roughly $720 a month, from a feature most reservation systems already include. The AI's part is small: writing the reminder wording, and perhaps handling the replies ("can we move to 8 instead?") that a plain system can't.
The fix. Make cancelling easy and early, and put deposits only where the numbers justify the friction. Here is the reminder wording in an illustrative before and after. Before: "Reminder: your booking at [restaurant] is tomorrow at 7:30pm. Reply STOP to opt out." After: "Looking forward to seeing you tomorrow, Friday, at 7:30 for 4. Tap to confirm, or let us know if plans have changed so we can offer the table to someone on our waiting list: [Confirm] [Change or cancel]." The second one gives guests a reason to cancel (someone else gets the table) and a way to do it in one tap. Reducing no-shows with AI reminders and automatic rebooking goes further into timing and wording.
A realistic slip once guests can reply. A guest answers the reminder with "Can we make it 5 instead of 4? And maybe 8pm?" An AI told only to "help with changes" replies "No problem, you're now booked for 5 at 8pm!" The booking was on a four-top, and the only table for five at 8 is held for walk-ins. Give the AI a short rule for replies: time changes within 30 minutes and cancellations can be done directly if the system shows the table; any increase in party size, or a move to a different day, goes to a person as a request, with a reply saying so.
4. Losing special requests between the chat and the kitchen
The mistake. The AI has a lovely conversation in which the guest mentions it's their parents' 40th anniversary, that one guest uses a wheelchair, and that another is coeliac. The booking that lands in the system says "Table for 6, 7:30".
How it shows up. The information exists only in a transcript nobody reads before service. The coeliac guest has to explain from scratch at the table, and the anniversary passes without a word.
The fix. Tell the AI to put requests into the booking's notes field in a fixed format that front-of-house scans at the pre-service briefing:
OCCASION: 40th wedding anniversary (parents)
ACCESS: 1 wheelchair user - table 3 or 8
DIETARY: 1 coeliac - manager to call before visitWatch out for notes fields with character limits that cut the text, and systems that show notes to the host but not on the kitchen ticket. Check where a note actually appears: on the floor plan, on the printed run sheet, on the ticket. If the chef never sees "coeliac", the note has done half its job. Train front-of-house to read the notes at the briefing, and put dietary notes on the kitchen ticket if your system allows it.
Order matters when space is short. If the notes field shows only the first 60 characters on the run sheet, "OCCASION: 40th wedding anniversary (parents) ACCESS: 1 whe" is what the host reads, and the coeliac guest disappears entirely. Put the lines in order of consequence, dietary first, then access, then occasion, so any truncation drops the birthday rather than the allergy.
Allergies need their own rules about what the bot may and may not say; whether a chatbot should answer allergen questions covers that in detail.
5. Auto-posting review replies that miss the point
The mistake. A review tool replies to every review automatically, triggered by star rating.
Before (auto-posted under a four-star review): The review read: "Food was excellent, but we waited 50 minutes for mains and nobody came to explain." The reply: "Thank you so much for your wonderful review! We're delighted you enjoyed your evening and hope to welcome you back soon."
After (AI-drafted, manager-edited): "Thank you, and I'm glad the food lived up to it. A 50-minute wait for mains without anyone checking on you isn't acceptable, and I'm sorry. We were a chef down that night and should have told tables straight away. If you come back, please ask for me. [Name], Manager."
One detail in that "after" reply needs care: "we were a chef down that night" came from the manager, who knew it. AI drafts invent explanations like this all the time. An illustrative draft for the same review offered: "Unfortunately our kitchen was exceptionally busy with a private event that evening." There was no private event. A guest who knows that, or a regular who was there, now has a reason to doubt everything else on the page. Add a line to the drafting prompt: "Never give a reason for a problem unless it's in my notes; if there's no reason, just apologise."
The first reply tells every future reader that nobody reads the reviews. The second tells them someone does. For which reviews, if any, are safe to reply to automatically, see whether to let AI auto-post replies to Google reviews.
What to automate instead. Let AI draft every reply in your voice, overnight, and have the manager approve them in one sitting the next morning. For a restaurant getting 40 reviews a month, that is perhaps 20 minutes of reading and editing a week, and every reply can mention something the guest actually said. The saving from skipping those 20 minutes is small; the cost of a page of hollow replies is not.
Google has been testing its own AI-suggested replies with some Business Profile accounts since March 2026. If yours has the option, treat its suggestions exactly like any other draft: read the review, check every claim, then post. Remember too that an owner reply can take up to 30 days to appear on Google, so a bad reply fixed today may still be visible for a while, and a good one may not show straight away.
Watch out for replies that all start the same way. Scroll your review page on a phone. If five replies in a row begin "Thank you so much for your kind words", readers notice, and it undoes the effort you put into the ones that matter.
6. Replies that expose guests or argue with them
The mistake. When a review is unfair, it's tempting to paste in the booking record and ask AI to "set the record straight". AI is good at that, which is the problem.
How it shows up. Illustrative prompt and output:
Prompt: Write a reply to this review. The guest says we gave their
table away. Our system shows they booked 8:00 for 4, arrived 8:45
with 6 people and didn't call ahead.
Output: "We're sorry you were disappointed. However, our records
show that your booking was for 8:00pm for four guests, and your
party arrived at 8:45pm with six people without contacting us.
We held your table for 20 minutes in line with our policy."Factually accurate, and a bad idea. It publishes the guest's booking details, sounds like a rebuttal, and future readers side with the guest by instinct. It may also breach platform rules: Tripadvisor's guidelines for management responses prohibit personal information that isn't already in the review, giving a guest's full name, medical information or travel itinerary as examples. What I'd change in the prompt: "Don't mention times, party sizes or any booking details. Acknowledge their frustration, state our policy on holding tables in general terms, and invite them to contact me directly." The result is shorter and far more convincing. An illustrative version: "I'm sorry your evening started this way. We hold tables for 20 minutes after the booking time, and when a party arrives larger or later than booked we sometimes can't keep the same table. I'd like to hear more about what happened; please contact me directly and ask for the manager." Nothing in it is private, nothing argues, and it still makes the policy clear to every reader. Answering restaurant complaints with AI without escalating has more wording to borrow.
7. Using AI to decide who gets asked for a review
The mistake. An automated flow sends a quick "How was your evening?" survey after each visit. Guests who answer "great" get a link to your Google profile; guests who answer "not great" get a feedback form. It looks clever, and some tools use AI sentiment scoring to do it.
Why it backfires. This is review gating. Google's policy prohibits business owners from selectively soliciting positive reviews or discouraging negative ones, and Google can restrict a profile that breaks its fake-engagement rules: stopping new reviews for a period, unpublishing existing ones, or showing a warning to visitors that fake reviews were removed. Having AI write reviews, or "improve" guests' reviews before they post, is worse still.
The fix. Ask every guest the same way, and use AI for the part that helps: reading the reviews you get, sorting them by theme and spotting what keeps coming up. An illustrative prompt and output:
Prompt: Here are our last 60 Google and Tripadvisor reviews.
Group the complaints and compliments into themes. For each theme,
give the number of reviews that mention it and quote one example.
Don't infer anything that isn't in the text.
Output (illustrative):
Compliments: food quality (41), friendly staff (28),
Sunday roast (17), value set lunch (9)
Complaints: wait for mains on Fri/Sat (11), noise level (7),
booking changed or table moved (5), card-only payment (3)
Example (wait): "Loved the food but 50 minutes for mains..."That output is useful, but check two things before acting. Count a few themes yourself, because models sometimes miscount or merge themes ("booking changed" may include guests who were late). And notice what the list says about the other six mistakes: "booking changed or table moved" appearing five times is a hint that mistake 1 may be happening. What review gating is and how it can get you penalised explains where the line sits on asking for reviews.
Watch out for incentives. "10% off your next visit for a review" feels harmless, but Google's content policy treats incentivised reviews as a problem too, and an AI-written request email may add an incentive if you ask it to "make the message more persuasive". Read the final wording of every automated request yourself, once, before it goes live.
Watch out for requests that steer what guests write. Since April 2026 Google's rules also bar asking for reviews that mention specific content, such as a staff member's name, and bar staff quotas for reviews. Both are easy to slip into with AI-written requests. Before: "Thanks for dining with us! If [server first name] looked after you well, we'd love a review mentioning her by name, and don't forget to tell people about our Sunday roast." After: "Thanks for coming in last night. If you have a minute, we'd be grateful for an honest review on Google: [link]." The "before" breaks the rule twice, and a staff contest for "most reviews mentioning you" breaks it a third way, however friendly the intention.
A 20-minute check to find which of these you're making
Run through this with whoever manages bookings, ideally on a quiet afternoon with the reservation system and review profiles open. Write down what you find as you go, because the list becomes your fix plan for the next month.
- Book a test table through every AI channel (phone line, website chat, social messages) for a party of 12 on your busiest night. Does it confirm, request or refuse? (Mistakes 1 and 2.)
- Open last Saturday's bookings. Do the AI-made ones have notes for occasions, access and dietary needs, or are the notes empty? Compare with the transcripts. (Mistake 4.)
- Read your own reminder text on a phone. Could you cancel in one tap? (Mistake 3.)
- Scroll your last 20 review replies. Count the ones that don't mention anything specific from the review. More than a few means automation is replying for you. (Mistake 5.)
- Search your replies for times, party sizes or names that the guest didn't mention. (Mistake 6.)
- Check your review-request flow. Does every guest get the same message and the same link? (Mistake 7.)
An illustrative filled-in version from a 70-cover bistro:
| Check | What they found | Mistake | Fix, and who |
|---|---|---|---|
| Party of 12, Saturday, via website chat | Confirmed instantly, no deposit mentioned | 2 | Add large-party rules; manager, this week |
| Party of 12 via AI phone line | Took a request correctly | None | Copy the phone line's rules to the chat |
| Last Saturday's AI bookings | 9 of 31 had empty notes; transcripts showed 3 birthdays and 1 nut allergy | 4 | Fixed notes format; supervisor checks at briefing |
| Reminder text | "Reply STOP to opt out" only | 3 | Add confirm and cancel buttons in the reservation system |
| Last 20 replies | 14 generic, all auto-posted | 5 | Switch to drafts; manager approves Mondays |
| Replies with private details | None found | None | None |
| Review requests | Same message to every guest | None | None |
The second row is worth noticing: two AI channels in the same restaurant, set up at different times, following different rules. That's common, and it only shows up when you test every channel with the same booking.
Most restaurants find two or three of the seven. Fix the booking ones first, because they cost covers on the night; the review ones cost you more slowly, but for longer.
The order changes a little with the kind of restaurant. A busy weekend-led bistro loses most to mistakes 1 to 3, because every empty or double-booked table on a Saturday is revenue it can't recover. A special-occasion restaurant, where many bookings are birthdays and anniversaries, loses most to mistake 4, because the evening depends on the team knowing why the guests are there. A tourist-heavy place that lives on its review ratings should start with mistakes 5 to 7, since a run of hollow or defensive replies is what a first-time visitor sees before deciding. Whichever applies, write down the rule that fixes it before changing any software; in most cases the tool you have can already do what the rule needs.
Further reads
- What Are Diners Really Saying? Using AI to Analyse Your Reviews — Use AI to read reviews for patterns instead of just replying.
- AI Phone Answering for Restaurants: What It Costs and Pays Back — What AI phone answering costs a restaurant and when it pays.
- Restaurant AI Tools: 12 Questions to Ask Before You Sign Up — Twelve questions to put to any restaurant AI vendor.
- Your First 30 Days of AI in a Restaurant, Week by Week — A week-by-week plan for introducing AI without chaos.
- How to Get More Google Reviews With Automated Review Requests — Ask every guest for a review, the compliant way.
- How to Handle a Fake or Unfair Review With AI's Help — What to do when a review looks fake or unfair.
- How to Train Front-of-House Staff to Work Alongside AI — Three short sessions, six role-play cards and a one-page counter card for teaching front-of-house teams to work with AI bookings, chat and phone assistants.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Google Maps user-generated content policy (fake engagement; restrictions on Business Profiles), Tripadvisor management response guidelines, OpenTable support (booking policies with credit cards and deposits), SevenRooms AI product pages.