Klarnow
Guides

How to manage food orders on WhatsApp without losing the handover

A quick reply is not a confirmed order. Use one shared record to check the details, verify payment and give the kitchen an accepted job.

The Chopiva food-commerce website showing its food menu and order navigation

Use WhatsApp for the conversation, but keep each order in a shared record with a clear status, owner and next action. Confirm what the customer wants, check that you can fulfil it, verify the agreed payment and give the kitchen a complete, accepted job. AI can help organise information; it should not guess whether an order is paid or promise capacity nobody has checked.

Start with the order record

The WhatsApp Business app supports customer conversations and product presentation. Those features make it a useful place to begin a purchase, but they do not establish that your payment provider and kitchen share the same order information.

Start with the tool your team already maintains. Give each enquiry a reference and record the contact, requested items, quantities, date, collection or delivery details, quoted amount, payment status, responsible person and next action. Leave unanswered questions visible.

A chat summary can help populate this record. The approved menu, actual capacity and payment-provider record remain the sources for decisions. A different member of the team should be able to take over without reading every message.

Separate interest from acceptance

Use a few states that everyone understands. These are suggested operating states, not built-in WhatsApp features. Adapt them to the way your business takes orders.

A catering business taking a deposit needs a remaining-balance field. A pay-on-collection order needs an agreed exception to a prepaid process. The important thing is that the rule is explicit before the order reaches fulfilment.

  • Enquiry received — gather the missing details.
  • Awaiting confirmation — check the request and available capacity.
  • Awaiting payment — send the agreed payment request and verify it.
  • Confirmed — the business has accepted the job and its payment condition is met.
  • Kitchen accepted — a named person has acknowledged the approved order.
  • Completed or exception — record delivery, collection or the issue requiring attention.

Verify payment at its source

Stripe documents how to review Payment Link payments in its Dashboard and use payment events for fulfilment. Some payment methods confirm later, so an integration must handle the relevant payment states rather than treating every completed checkout as final payment.

In a manual process, a named person matches the provider record to the order. In an automated process, require the same match and test what happens when a notification arrives twice or a payment is delayed.

A customer's message saying 'paid' should not be the only release condition. Keep uncertain matches visible for review. The aim is to prevent an unresolved payment question from turning into a kitchen commitment.

Give AI one bounded job

A useful first task is converting a long enquiry into a draft with the requested date, items, quantities and missing questions. A person checks that draft before the business commits to the order.

Use approved information for routine replies. Route unusual substitutions, uncertain ingredients, complaints, refunds and unavailable delivery arrangements to the responsible person. A convincing answer is not evidence that the business can keep the promise.

Make the kitchen handover explicit

Consider an illustrative example: a caterer receives an office-lunch enquiry for twenty people on Thursday. The message does not include a delivery time. The operator asks for that detail and records the request as awaiting confirmation, rather than sending it straight to the kitchen.

The operator checks capacity, agrees the details and sends the payment request. Once the agreed condition is verified, the customer receives the order reference, items, delivery window and contact route.

The kitchen receives that same approved version and acknowledges the job. A later change in quantity becomes a revision that needs checking. It must not silently replace instructions the kitchen has already accepted. This example is a proposed workflow, not a reported client result.

Test the exceptions before calling it automated

Test a normal order, missing details, an unpaid request, delayed payment, duplicate notification and a change after confirmation. Use a controlled test that cannot charge a customer or release a real kitchen job.

For every scenario, check the order status, customer message and next person's instructions. Then track unmatched payments, confirmed orders without kitchen acknowledgement and overdue replies. Compare equivalent periods before claiming improvement.

For your next working session, trace one recent order from its first message to fulfilment. Find the first point where someone had to guess. That is the handover to fix first.

Sources & further reading

AI-assisted Klarnow editorial analysis. Product documentation was checked on 14 September 2026. The workflow and catering example are illustrative.