How to Build an n8n AI Agent for Restaurant Reservations and Reviews

A reservation request texts in at 9 PM asking for a table of 6 on Saturday, with a note that one guest has a shellfish allergy, and it sits unanswered until someone opens the phone the next morning. Wire an n8n AI agent into the intake, and it can confirm the booking against your actual availability and, just as important, make sure that allergy note reaches the kitchen instead of getting lost in a text thread.

What can the agent actually confirm about a reservation?#

Party size, date, time, and whether your restaurant can actually seat that party at that time are facts the agent can check against a real availability source, whatever your booking system exposes to n8n. What it should not do is invent availability it has not actually verified, confirming a table that does not exist because the request sounded reasonable.

Treat an unclear request the same way a real estate lead qualification agent treats a form gap: ask the 1 missing detail rather than guessing. A request for "Saturday night" with no time, or "a table for the Andersons" with no party size, needs a quick follow-up question before it can be confirmed against real availability.

Large parties deserve their own rule rather than the same automatic confirmation a table for 2 gets. Many restaurants handle a party of 8 or more differently, a set menu, a deposit, a specific room, so route anything past your normal party-size ceiling to a manager instead of letting the agent confirm a standard table booking for a group your floor plan cannot actually seat together.

Verified facts, not assumptions dressed up as confirmations.

How does the agent handle allergies and special requests?#

Every stated allergy or dietary restriction gets passed through verbatim into whatever field the kitchen actually reads, a note on the reservation, a message to a specific channel, not summarized or paraphrased into the agent's own words at any point.

"Guest has a tree nut allergy, please advise" written by a human and "possible nut sensitivity mentioned" generated by a model summarizing it are not the same level of clear, and the gap between the two phrasings is exactly where a real mistake happens.

Confirm back to the guest that the note was received, not just logged silently. "Noted, thank you for letting us know about the shellfish allergy" tells the guest it will not be missed; a booking confirmation with no mention of it leaves them unsure whether anyone actually saw it.

Route severe allergy notes to a person directly, not just a field on the reservation record. A shellfish or tree nut allergy for a party dining that night is worth a direct message to whoever is running the floor or the kitchen that evening, in addition to whatever gets logged, so it is not something someone has to remember to check for before service starts.

An allergy is a safety issue; a seating preference is not.

How should the agent draft responses to online reviews?#

A review response earns a draft, not an automatic post. Read the review, draft a specific, non-generic reply that references what the guest actually said, and hold it for a human to approve before it goes live, the same human-in-the-loop pattern that gates any customer-facing message elsewhere in this series.

Specificity is what separates a response worth posting from one that reads as an obvious template. A reply that says "thank you for your feedback, we're sorry to hear this" could sit under any 1-star review on the internet; one that references the actual dish, the actual wait time, or the actual issue the guest described shows someone read it. Give the agent the review's actual text to work from, not a summary of it.

A 5-star review deserves a genuine reply too, not just the negative ones. A short, specific thank-you that mentions what the guest praised keeps the response pattern consistent across the whole review stream, rather than only ever drafting something when there is a problem to address.

The allergy-routing step runs alongside confirmation, not after it.

What should the agent never handle on its own?#

Never let the agent issue a refund, a comp, or a specific promise about a future visit in a review response or a reservation confirmation; those are decisions an owner or manager makes, not a byproduct of drafting a polite reply.

A response that promises "we'll make it right next time" commits the business to something the agent genuinely has no authority to guarantee on the owner's behalf.

Negative reviews mentioning anything that sounds like a genuine health or safety concern, not just a bad experience, deserve immediate escalation to a manager rather than a standard drafted response at all. That is a different category of problem than a slow table turn or a disappointing dish, and treating it the same way as routine feedback misses how seriously it needs to be taken.

A generic auto-post risks a promise the business never agreed to.

What breaks, and how do you debug it?#

The most common failure is a booking confirmed against stale availability data, a table that got double-booked because the agent's view of your schedule was a few minutes behind an update made elsewhere. Keep the availability check as close to real time as your booking system allows, and confirm rather than assume when the system's freshness is in question.

Turn on Return Intermediate Steps on the AI Agent node and check exactly what availability the agent saw at the moment it confirmed a booking. The general agent-not-working checklist covers the credential and connection issues that show up the same way across every workflow in this series; for a reservation agent specifically, a stale connection to the booking system is the first thing worth ruling out.

Language and translation are worth planning for if your guests are not all writing in the same language you configured the agent in. A reservation request or a review in a different language should still trigger the same allergy-flagging and human-review discipline; do not let a language the agent handles less confidently become the reason a safety note gets missed.

Is this worth building for a single-location restaurant?#

Build it when after-hours and high-volume requests are genuinely slipping through, a Friday dinner rush generating texts a host cannot answer between tables, or a habit of the restaurant's phone going unanswered after close. A quiet restaurant with a host who reliably answers every call does not need this layered on top.

The honest value is catching what would otherwise wait until morning and making sure a safety note never gets lost in the process, not a better guest experience than an attentive host already provides. Every allergy note gets flagged the same reliable way, every review gets a draft worth reading instead of a stock reply, and a manager still makes every real decision.

Allergies and safety concerns always route to a person; everything else follows a clear default.