Restaurant booking system with AI, WhatsApp and n8n

One of the systems I have built inside NexaVision AI is a restaurant booking automation. The idea was to solve a very concrete problem: many bookings arrive through conversational channels, especially WhatsApp, but the restaurant needs those conversations to become real reservations that are validated, registered and easy to cancel.

I am not publishing the repository or the code because it belongs to NexaVision AI internal workflows. But I can explain the architecture, product approach and technical decisions that make the system work.

The problem

Booking a table sounds simple, but once you look at it from inside a restaurant, a lot of details appear:

• the customer writes naturally, not through a perfect form,
• the day, time, party size, name or email may be missing,
• there are lunch and dinner service windows,
• there are closed days,
• there is a maximum capacity per time slot,
• some large groups need manual review,
• the restaurant must avoid duplicated or overlapping bookings,
• the customer needs a clear confirmation,
• the booking should be cancellable later through the same channel.

The goal was to turn all of that into an automated system without making it rigid. A restaurant does not need an AI that sounds impressive; it needs an AI that does not break operations.

The solution

The system works as a booking assistant connected to WhatsApp, n8n and Google Calendar. The customer can write something like:

Hi, I want to book tomorrow for 4 people at 21:00.

The workflow interprets the intent, extracts structured data, validates whether the reservation is complete, checks availability and creates the Calendar event if there is capacity.

If information is missing, the assistant does not invent data. It asks only for what is needed:

• day,
• time,
• party size,
• name,
• email to send the Calendar invitation.

That part matters. In business automation, a good AI is not the one that writes the longest answer; it is the one that reduces friction without losing control.

General architecture

The architecture is divided into several blocks:

• WhatsApp input: receives customer messages from an instance connected to n8n.
• Message normalization: filters invalid messages and prepares useful data such as phone, text, chat and context.
• Restaurant configuration: name, timezone, booking duration, capacity per slot, maximum party size, closed days and opening blocks.
• AI interpretation: turns natural language into intents such as checking availability, booking, cancelling or answering a general question.
• Google Calendar: reads events, calculates conflicts and creates bookings.
• Internal SQLite: stores conversational history and reservations.
• Email / Calendar invite: sends confirmation and adds the customer as guest.
• WhatsApp response: sends a clear answer back to the user.

The code and endpoints remain private, but the architectural pattern is the important part: conversational channel, interpretation layer, validation layer, availability layer and confirmation layer.

Availability logic

The system does not simply ask whether there is an event at the exact requested hour. It calculates availability with restaurant-specific rules.

For each day, it checks:

• whether the restaurant is closed,
• which opening blocks apply,
• whether the requested time falls within lunch or dinner service,
• how many events overlap with the requested slot,
• whether concurrent reservations exceed the configured capacity,
• whether the party size exceeds the automated limit.

That makes it possible to separate three cases:

1. There is availability: the booking is created.
2. There is no capacity: the assistant suggests looking for another time.
3. The case needs review: large groups or out-of-policy requests are escalated to the team.

This distinction prevents the assistant from forcing bookings that a human should review.

Validation before confirmation

Before touching Calendar, the system validates fields. It is not enough for the user to say "book for four"; the system needs day, time, name and email.

Email is especially important because the booking can also be confirmed with a Google Calendar invitation. If the user writes an invalid email, the system detects it and asks again before confirming.

It also validates:

• bookings on closed days,
• times outside service hours,
• groups above the automatic limit,
• ambiguous dates,
• incomplete reservations.

This validation layer is what turns the flow from a "nice chatbot" into an operational tool. Without validation, an AI can promise things the restaurant cannot actually fulfill.

Creating the booking

When the data is correct and there is capacity, the system creates the event in Google Calendar. The booking is registered with:

• customer name,
• phone,
• email,
• date,
• time,
• party size,
• status,
• event identifier.

Then it returns a confirmation through WhatsApp and sends the invitation to the customer's email. That way, the restaurant does not depend on a lost chat message: the reservation ends up in the calendar the team already uses.

Cancellations through WhatsApp

I also implemented cancellation of active bookings. The customer can write that they want to cancel, and the system searches for reservations associated with their phone. If it finds an active booking, it cancels the Calendar event and updates the internal record.

This is important because incomplete booking automation usually solves only the entry point, but not real life. In real life, people change plans, make mistakes or need to cancel.

History and context

The workflow stores conversational history and reservations in internal SQLite. This helps maintain context between messages instead of treating every sentence as a brand new conversation.

For example, if the user first asks:

Is there a table for 2 this Friday night?

and then answers:

Ok, at 21:30.

the system needs to understand that the second sentence belongs to the previous query. History is not there to make the AI look smarter; it is there to make the flow useful.

Why n8n fits this system

For this kind of system, n8n fits very well because it combines existing pieces:

• WhatsApp,
• AI,
• Google Calendar,
• email,
• lightweight database,
• business rules,
• automated responses.

It could have been built as a custom backend from scratch, but for a first commercial version n8n allows faster iteration, visible executions, node-level debugging and rule adjustments without redeploying a full application.

The key is not using n8n as a chain of nodes without judgment. The key is designing the flow as a system: clean inputs, clear states, validations before actions, predictable outputs and human escalation when needed.

What I learned

This project reinforced several ideas about AI automation:

• AI should interpret, not decide everything. Important decisions go through explicit rules: opening hours, capacity, required fields and escalation conditions.
• A booking is transactional. It is not enough to answer well; the system must register, confirm and be able to undo.
• The channel matters. WhatsApp is natural for the customer, but the business needs structured data at the end.
• Good automation knows how to ask for missing data. If something is missing, it asks specifically.
• The human is still part of the system. Large groups, unusual cases or ambiguous requests should be escalated.

Future improvements

If I evolved it into a more complete product, I would add:

• a visual panel to configure opening hours and capacity without touching the workflow,
• automatic waiting list,
• pre-confirmation a few hours before the booking,
• no-show detection,
• CRM or customer database integration,
• demand analytics by day and slot,
• multilingual support,
• embeddable web version connected to the same calendar.

The base is ready for that because the system separates conversation, rules, calendar, persistence and notifications.

Conclusion

This booking system summarizes quite well how I understand NexaVision AI: it is not about placing a chatbot on top of a business, but about turning real conversations into reliable processes.

For a restaurant, that means fewer manual messages, fewer scheduling errors, clearer confirmations and a better customer experience. For me as a developer, it was a strong exercise in applied architecture: AI where it adds value, rules where precision matters and automation only when the result can be verified.