WhatsApp AI Agent for Restaurants: Two Live n8n Builds

Both businesses take orders on WhatsApp. The questions repeat: can I see the menu, what does the large one cost, are you open, do you deliver to my area. An order arrives as a few loose messages that someone has to turn into an item list, an address and a payment method.

Both workflows are built to do the same four things. Answer the repetitive questions from the real menu. Take a complete order without staff typing anything. Never guess a price: the prompts forbid answering from anything but the knowledge base. Get out of the way the moment a customer is unhappy or asks for a person.

Every inbound message hits an n8n webhook that Evolution API calls. From there the flow runs in this order:

1. Filter. Messages from group chats are ignored (Client B).
2. Chat state. A sub-workflow reads whether this chat is with the AI or with a person.
3. Who sent it. Messages sent by the business itself go down a separate path, covered below.
4. Customer record. A sub-workflow creates the customer in Postgres if this number is new.
5. Text or voice. Text goes straight through. Voice notes are downloaded and transcribed first.
6. Router. A small classifier agent decides whether the AI should answer or a person should.
7. Main agent. It answers with the tools below and returns structured JSON: the reply text, a message type and an optional list of image URLs.
8. Dispatch. A switch on the message type sends a normal reply, a pre-order summary, or a post-order confirmation.

The main agent has seven tools in each build. A vector search over the knowledge base returns the top 25 chunks, and a Cohere reranker keeps the best 5. Three Postgres tools list the documents, fetch a whole document, and run SQL over rows imported from spreadsheets, which is how price lists stay exact. A Date & Time tool lets it refuse orders outside opening hours. Client A adds a tool that returns the payment QR image, Client B one that sends the restaurant's location, and both have a tool that returns the menu images so the agent can choose which ones to send.

The order itself is a two-step handshake. When the agent has items, sizes, quantities, address, phone number and payment method, it returns pre_order_confirmation. A second agent formats a fixed summary with an estimated total and asks the customer to confirm it (a Confirm button in the café build, a typed yes in the restaurant build). After the confirmation, the main agent returns post_order_confirmation, and a third agent sends the confirmation with the delivery estimate and calls a sub-workflow that sends the order details to the restaurant.

One rule in both prompts matters more than it looks: checking payment is explicitly not the agent's job. It shares payment details and asks for a screenshot, and staff confirm the money.

Customers do not always type, so both builds treat voice notes as a first-class input.

The workflow asks Evolution API for the audio as base64, converts it to a file and sends it to OpenAI's transcription with the language set to Urdu. The transcript goes to the same main agent as a text message would, with a flag saying the customer spoke.

If the customer spoke, a normal reply goes back as a voice note. Order summaries and confirmations stay as text, so the customer can check them. A dedicated formatter agent rewrites the answer for speech: Roman Urdu becomes Urdu script, English menu words stay in English, prices are spelled out as words, and lists become sentences. Uplift AI, a Pakistani voice company, turns that text into audio, and the workflow sends it back as a WhatsApp voice note. Text in gets text out; a question asked by voice gets a spoken answer.

A large share of the nodes in both workflows exist for this part.

Every chat has a status in a Postgres table. The router agent reads the current status and the recent chat history and returns human_chat for three cases: the customer asks for a person in any language, the issue is outside what the AI may handle (complaints, refunds, wrong or missing items, payment disputes), or the chat is already with a person and the customer is just waiting. Anything that looks like an order, even "1 large, 2 cookies", stays with the AI.

On a handoff the workflow:

• sets the chat to human mode through a sub-workflow
• tells the customer a person will reply and that typing ai brings the assistant back
• finds the staff WhatsApp group by its name and posts the customer's message there, quoted, so staff can jump in

Two more details make it work in practice. First, when a staff member replies from the WhatsApp app on the business phone, Evolution API reports a message sent by the business itself, and the workflow marks that chat as human-handled. Staff never have to tell the bot to stop. Second, a schedule runs every 30 minutes and returns any chat that has sat in human mode for more than 30 minutes without an update to the AI, so nobody gets stuck in a dead handoff.

Client B added a middle state. When the router flags a handoff, the customer is first asked whether they want a person and told to type yes to confirm. Only a yes moves the chat to staff; anything else goes back to the AI. The point is to stop sending chats to staff that a rephrased question would have solved.

We build on both Meta's official WhatsApp Cloud API and unofficial gateways, and recommend one per project. For these two clients we recommended Evolution API, an open-source gateway that links to a WhatsApp number the way WhatsApp Web does. For these builds it gave three things: the business number and the phone app keep working as before, the staff escalation group is an ordinary WhatsApp group, and Meta charges no per-message fees on this connection.

The trade-off is account risk. A WhatsApp Web connection is not Meta's official Business Platform, and WhatsApp's terms prohibit automated and bulk messaging on accounts that are not authorized for it and allow suspension. These agents only reply to customers who message first and never broadcast, which keeps the setup away from the behaviour those terms target. The risk is still not zero. We cover the full comparison, with Meta's own rules and prices, in Evolution API vs WhatsApp Cloud API.

The second build started from the first and changed the following:

• Model provider. The café runs on GPT-4.1 mini. The restaurant runs its text agents on Gemini 3 Flash (preview). Both canvases keep the other provider's model nodes in place, unwired, so switching means rewiring, not rebuilding.
• Confirmation step. The café's summary uses a WhatsApp Confirm button. The restaurant asks for a typed Yes instead.
• Safer JSON parsing. Models occasionally wrapped the JSON in code fences or printed it twice. The second build strips fences and parses only the first complete JSON block.
• Pending transfer. The confirm-before-handoff state described above.
• Welcome back. When a chat returns to the AI, the customer gets a short greeting before the agent resumes.

Reply, image, order summary and confirmation sends retry up to 5 times with a 2 second wait, and the main agent retries the same way, because a customer who gets no reply assumes nobody is there.

Neither workflow has an n8n error workflow set, so a failure that survives the retries is only visible in the execution log. A global error workflow that pings the staff group is the next change. The router and the main agent also share one memory key, which lets the router's short answers appear in the main agent's history. Separate keys are cleaner, and the template in our build log already uses them.

Taken from the workflows themselves:

• Replies 24/7. The agent answers customers day or night, in English or Roman Urdu. A voice note gets a voice note back.
• Answers from the real menu. Prices come from the knowledge base and imported price rows, and the prompts forbid quoting them from anywhere else. The agent sends menu images, plus the payment QR (Client A) or the restaurant's location (Client B).
• Takes complete delivery orders. Items, sizes, quantities, address, phone number and payment method, confirmed by the customer before the restaurant is notified.
• Alerts staff on handoff. Requests for a person, complaints, refunds and wrong orders go to a staff WhatsApp group with the customer's message quoted, and the agent stays quiet while staff reply from the phone.
• Returns stale handoffs. A chat left in human mode for 30 minutes goes back to the agent.

Staff step in only for the conversations that need a person.

If you want to see how we build these step by step, read the n8n WhatsApp AI agent build log. For pricing, see what a WhatsApp AI agent costs, or go straight to the WhatsApp AI agent service.