WhatsApp orders for restaurants: from chat to kitchen

Someone sends a WhatsApp message: ‘Two burgers, one without onions, fries to share, and I’ll pay by PSE.’ It sounds like an order. For the restaurant, it still needs to become one.

To take WhatsApp orders for your restaurant, keep the menu current and define how items, address, total, payment and delivery will be confirmed. Your team can start in the app or connect an ordering system through the API. Choose according to the workflow you need to control and the integrations available.

The team must check availability, record the modifier, calculate delivery, validate the address, request payment, confirm approval, send the ticket to the kitchen and notify the customer when it leaves. If one person retypes the conversation at the till and another writes it on a kitchen ticket, WhatsApp has only changed where the work starts. The operation remains disconnected.

A system for WhatsApp orders for restaurants connects that entire journey without losing information. This guide explains what needs to connect, which record governs each step, and how to assess whether the channel works.

1 · An order is more than a conversation

The conversation is the interface. The order is a record with its own identity: reference, customer, location, items, quantities, modifiers, amount, address, fulfilment method, payment status and operational status. Those details matter when the restaurant needs to handle orders without filling the kitchen with screenshots.

The chat may understand ‘no onions’ and respond naturally. The system must turn that request into a structured instruction for the correct station. If the kitchen only receives ‘Laura’s order’ and has to open WhatsApp for the details, the workflow is still incomplete.

2 · Seven connections from message to delivery

1. Current menu, availability and modifiers

The agent needs access to the menu used by the operation, rather than an outdated PDF or a list pasted into a prompt. Each item needs its price, location, hours, availability, options and rules: protein, size, sides, extras and allergens declared by the restaurant.

When an item sells out, that option should close in both chat and on the website. If WhatsApp continues offering it, the team must apologise and renegotiate the order.

2. Cart and unique order reference

Customers change their minds: ‘make it three’, ‘remove a drink’, ‘no sauce on the second one’. The cart keeps the current version and recalculates the total. Once the customer confirms, the system generates a unique reference. Payment, kitchen and support can then identify the same order.

Without that reference, two common problems arise: a payment that nobody can match to an order, and a duplicate order when the customer asks whether the first one arrived.

3. Address, service area and delivery charge

Before requesting payment, the system must establish whether the restaurant serves the address, which location fulfils it and what delivery costs. A neighbourhood name alone is insufficient. A usable address needs a city, full street address, directions and service-area rules the restaurant can maintain.

This check also protects the promised delivery time. An agent should not offer forty minutes when the location is overloaded or the destination is outside its normal area. When it cannot calculate reliably, it should hand over the case with the information already collected.

4. Payment confirmed by the system

Sending a link is not payment confirmation. The order needs a status such as pending, approved, declined or expired. The kitchen receives it when the restaurant’s business rule is met: approved payment, authorised payment on delivery, or an exceptional human check.

With Wompi, for example, a new transaction can begin as PENDING. The backend receives changes through the transaction.updated event and validates its signature before marking the order as paid. Wompi’s documentation recommends completing the integration with server events rather than relying on the customer-facing redirect. See the official event and verification documentation.

A Nequi screenshot can form part of a manual review, but it is not automatic payment confirmation. If the restaurant accepts that method, it needs an explicit review queue so that ‘receipt submitted’ does not become ‘funds reconciled’ by mistake.

5. POS or kitchen display

After the payment condition is met, the order needs to reach the point of sale or kitchen display with items, quantities, modifiers, promised time and fulfilment method. A direct integration may be possible if the POS offers suitable APIs or webhooks. Otherwise, design a safe intermediate step and establish that limitation from the outset.

The kitchen needs a clear ticket rather than the entire conversation. Customer support still needs the history to resolve questions without asking people to repeat every detail.

6. Status updates the customer can see

An order can move through received, awaiting payment, confirmed, preparing, ready, out for delivery, delivered or cancelled. Each change needs a timestamp and an accountable person or system. Only some changes need to trigger a message.

This avoids both silence and excessive notifications. Customers need to know that payment was approved, the kitchen received the order and delivery has started. The team needs more detail to act when something stops moving.

WhatsApp delivery statuses matter too. API acceptance does not prove that the customer received a message. The system needs to process delivery webhooks and expose failures. Our article on WhatsApp messages that do not arrive (Spanish) explains how an apparently healthy integration can leave the customer without a response.

7. History and permission-based follow-up

A completed order leaves useful information: items, changes, location, amount paid and permission for subsequent communications. That history can help the next conversation start with ‘Would you like to repeat your last order?’.

A purchase is not permission for indefinite marketing campaigns. The restaurant needs to record the relevant consent, honour opt-outs and use personal data for the purposes explained in its policy.

3 · The complete journey

4 · What breaks when the parts operate separately

5 · What the dashboard should measure

Counting incoming messages is insufficient. The dashboard needs to follow orders through stages and show where they drop out.

• Conversations with purchase intent: distinguish questions from actual order attempts.
• Confirmed orders: track how many carts become orders.
• Abandonment before payment: identify friction with the menu, service area or checkout.
• Approved, declined and pending payments: keep transaction handling visible.
• Time to kitchen: measure from confirmation to kitchen receipt.
• Preparation and delivery times: compare the promise with what happened.
• Orders requiring correction, cancellation or refund: surface capture and fulfilment errors.
• Repeat purchases by customer and channel: assess whether the direct channel supports an ongoing relationship.

There is no universal success percentage. Establish a baseline for volume, abandonment, errors, times and repeat purchases, then define a target for each stage. This helps the restaurant assess changes without attributing sales to the system that would have happened anyway.

6 · Introducing the workflow while the restaurant operates

Sequence matters more than feature count. A controlled rollout can begin with one location, a stable part of the menu and limited operating hours.

1. Map the current operation. Follow actual orders from first message to delivery and record each re-entry, wait and human decision.
2. Define the source of truth. Decide where menus, prices, availability, orders and statuses are maintained.
3. Build the minimum workflow. Connect menu, cart, service area, confirmation and kitchen ticket under team supervision.
4. Connect payments. Use unique references, signed webhooks and explicit rules for pending or declined transactions.
5. Integrate kitchen and dispatch. Enable the POS or kitchen-display route and the updates customers need.
6. Measure before expanding. Compare errors, times and abandonment with the baseline before adding upselling, loyalty features or locations.

People remain part of the design. Complaints, unclear addresses, unanticipated allergies and commercial exceptions need a human handover. A sound automated workflow also knows when to stop and pass on the case with context.

Before enabling the channel, verify number ownership, required templates and how delivery will be checked. Our WhatsApp Business API preparation guide separates that preparation from testing the ordering system.

7 · Where Cocina Conectada fits

Cocina Conectada brings together a direct channel, a dynamic menu, a WhatsApp agent, payments, operational integration and a dashboard. Implementation is scoped around the restaurant’s POS and operating rules. If the existing system cannot be integrated safely, identify that limitation during the assessment before promising full automation.

Published MD service prices remain available only to signed-in MD users. The scope and investment depend on the package and additional integrations, such as multiple locations or a proprietary POS.

The next order should only need to be entered once

WhatsApp can be the entry point to a direct ordering channel. Its value grows when a monitored inbox becomes the start of a traceable operation.

Before choosing a system, trace five recent orders. Look for re-entered information, screenshot-based payment checks, reconstructed kitchen tickets and customers asking for updates. That gives you a map of what needs to connect. Start by keeping each order’s information consistent from message to delivery, rather than automating everything at once.

You can also watch the chat-to-kitchen WhatsApp ordering tutorial on YouTube (Spanish audio).

Written by Lic. J. Andrés A. García, founder and strategy director of MD Estudio Creativo. For further context, read the restaurant AI agents guide and our guide to restaurant upselling and average order value.