Customer operations · Local n8n build
A WhatsApp request can mean a booking, a menu question, an order update, or feedback. This n8n build classifies the intent, sends it to a named route, and connects payment and order completion to the next operational step.
Inside the automation · Seven webhook routes · one daily schedule
The polished canvas keeps the connected version of each webhook route and groups the work into seven sections. Each node name states its job, from receiving a WhatsApp message to acknowledging a payment event.
01 · Conversation
Receive and normalize a WhatsApp event, ask the Sarvam AI router for an intent, parse its response, and send the request into booking, order, status, feedback, or fallback handling.
02 · Fulfillment
Named routes check availability, create a booking, build an order quote and payment link, look up order status, or save feedback and alert a manager.
03 · Tools
Four separate webhook tools expose availability, booking creation, menu lookup, and order status. Each has its own request, logic, and response chain.
04 · Operations
A payment event confirms an order and notifies the kitchen. An order-completed event requests feedback, while a daily schedule identifies inactive customers for a retention campaign.
In a busy food-service operation, a WhatsApp message can mean a booking request, a new order, a status question, or feedback. Those requests need different follow-up actions. A payment event also needs to reach the kitchen, while completed orders and inactive customers call for later messages. Handling each step by hand makes the handoff difficult to inspect and easy to miss.
I built Customer Service and Orders as a realistic n8n operations scenario for these connected tasks. The polished local copy uses seven square-cornered sections to separate intake, intent routing, customer actions, AI tool endpoints, payment confirmation, post-order feedback, and retention. Node names describe the action at each step so the route remains readable on the canvas.
An incoming WhatsApp webhook normalizes the message, sends it to a Sarvam AI intent router, parses the response, and routes it to a booking, order, status, feedback, or generic reply branch. Booking checks availability before creating a reservation and sending confirmation. An order builds a quote and payment link; status looks up an existing order; feedback saves the response and alerts a manager. The branches converge on one webhook acknowledgement.
Four separate tool webhooks let the AI request availability, create a booking, read the menu, or check order status. A payment webhook normalizes the event, confirms the order, notifies the kitchen, and responds. Another webhook requests feedback after an order is marked complete. A daily schedule finds inactive customers and starts a retention message.
The graph expresses the intended handoffs; it does not yet prove that an AI classification is correct, that a payment is authentic, or that a message reaches its recipient.
I inspected the saved n8n graph and produced a separate, inactive copy from its coherent routes. The copy has 41 executable nodes, 37 connections, seven unique webhook paths, one schedule trigger, and seven square section notes. Every executable node is reachable from a trigger. I removed 36 older duplicate or disconnected nodes, including six duplicate webhook routes and an intent router with no outgoing paths. The original local workflow was preserved.
The local n8n instance records zero executions for this workflow. Its external HTTP integrations are not bound to a tested sandbox in this case study, and no end-to-end delivery has been verified. This is a workflow build and structural review, not evidence of a client deployment, order volume, response-time improvement, or revenue result.
I would run synthetic booking, order, status, feedback, payment, and completed-order events through sandbox services, then inspect both successful and failed responses. Before activation, the webhooks need authentication and event replay protection; payment and booking actions need idempotency checks; external calls need timeouts, retries, and an error workflow. I would also test unknown AI intents, unavailable menu or booking data, failed WhatsApp delivery, and consent rules for retention messages. Only observed runs against an agreed source of truth should be used to report operational results.
Next
