A food distributor can use AI to read restaurant WhatsApp messages into draft order lines, then compare the message time with a delivery cut-off table. It should acknowledge receipt without promising delivery, check product codes and stock, and send a confirmed order only after an authorised person or controlled order system accepts it.
The cut-off belongs to the delivery run, not to the chatbot. A 15:58 message can qualify for a 16:00 cut-off yet still fail because the account is on hold or the requested case size is unavailable. An assistant that replies “arriving tomorrow” before those checks has created an avoidable service dispute.
Draw the boundary around an accepted order
Start with four states that staff and customers can distinguish: message received, draft assembled, order accepted, and order changed or rejected. A message received at 15:57 is evidence of when the customer contacted you. It is not evidence that stock was reserved. A draft is a set of proposed lines, which may contain ambiguities. Acceptance is the moment your order ledger records a version, a delivery date and a responsible checker. A later amendment needs a new version. Put these words in the operational procedure and in customer replies.
The first version of the process can be semi-manual. Staff can copy a day's messages into a controlled spreadsheet, ask ChatGPT or Claude to extract fields, and review them before entry. For a higher volume, a business-specific WhatsApp Business Platform integration can receive messages and write drafts into an order queue. Read the rules before buying an automation. As of November 2026, the WhatsApp Business Messaging Policy allows automated replies inside the 24-hour customer service window, which opens and resets with each customer message, and requires escalation paths that are “prompt, clear, and direct”, such as an in-chat transfer to a person or a phone number. Outside that window a business may send only approved message templates, so a Monday reminder to a restaurant that last wrote on Saturday needs a template.
The AI rule sits in a separate document. Section 4.7 of the Meta Terms for WhatsApp Business Platform bars providers of large language models, generative AI platforms and general-purpose AI assistants from the platform where the AI is the primary function on offer, as Meta decides. A distributor's order assistant that serves only its own customers is a business use rather than a general chatbot, but the same clause says that if you hire an AI company as your solution provider, your WhatsApp data may not be used to train or improve its models (fine-tuning a model for your exclusive use is allowed). Ask any provider how it meets that clause before signing.
Keep the broader choice of app versus platform in the WhatsApp Business app and platform comparison. The operational test here is simpler: can the setup identify the customer's account, attach the original message and time to a draft, show a reviewer what it inferred, and stop a reply that promises delivery too soon? A free-form chat response on an employee's phone may help the employee draft a message. It cannot by itself guarantee that a confirmed line entered the picking queue.
The Complete Excel Course with AI Integration
From formulas and pivot tables to Power Query, DAX, VBA and AI with Copilot, ChatGPT and Claude — hands-on from the first lesson.
By Sagnik Bhattacharya and Virginia Thorn, Primetime Emmy Award winner
Buy nowPut cut-offs in a table staff can correct
Create one row per delivery run and ordering channel. Use the distributor's own operating time zone. The table needs a run identifier, eligible customer group, day of departure, order deadline, exception contact, holiday override and effective date. Store the time zone explicitly in the system configuration. A cut-off of “4 pm” without a time zone, day or exception is not a rule an assistant can apply safely.
| Illustrative run | Order deadline | Eligibility | After the deadline |
|---|---|---|---|
| R1, next-day ambient | 16:00 on the previous working day | Active accounts on route R1 | Offer the next eligible run; staff may approve an exception |
| R2, next-day chilled | 14:00 on the previous working day | Active accounts with chilled capacity | Hold for dispatch review |
| R3, collection | 11:00 on collection day | Collection accounts only | Ask staff for a slot |
The table is an illustration, not a recommended cut-off. Change the entries to your actual routes. Decide whether the deadline applies to receipt of a complete order or to the first message. The fairer and more auditable choice is often the complete order, but publish whatever policy you actually follow. If a restaurant writes “same as last Tuesday” at 13:58 and provides the missing change at 14:05, the assistant must not pretend that a complete chilled order existed at 13:58.
Give staff one controlled way to grant exceptions. Record who approved the exception, which run it affects, the reason, and whether the warehouse and driver have accepted it. Do not let the AI infer an exception from “we normally do this for them”. Conversely, an approved standing-order arrangement can be written into the account record rather than rediscovered from previous chats each week. For a broader look at stock and reorder points, handle inventory logic separately from message reading.
Make the order message easy to parse
A restaurant may send “12 milk, 4 tubs yoghurt, usual eggs” as one line, then a voice note, a photograph of a handwritten list and a correction. Your product catalogue should have item code, customer-facing name, aliases, pack size, unit, availability status and whether substitution is allowed. The account file should say whether “12 milk” usually means bottles, cartons or cases, but past behaviour is a clue for a question, not automatic permission to commit stock. If the customer writes “usual eggs”, the system should surface the last accepted egg line and ask them to confirm the quantity and pack.
Set a required-field rule: customer account, requested delivery run, each product and quantity, unit, any substitution instruction, and the identity of the person who accepted the order. A short acknowledgement can be sent even when fields are missing. The eventual confirmation must name every accepted line and any rejected or substituted line. For perishables, record the requested grade, temperature category and delivery window where those affect fulfilment. The assistant should never improvise a product equivalence from a similar name.
Here is an illustrative before-and-after. The restaurant writes, “Need 3 toms, two cream, same eggs, tomorrow please.” The draft may show “tomatoes: 3 cases; cream: 2 cartons; eggs: unresolved; requested delivery: tomorrow”. The correct next reply is “I have three cases of tomatoes and two cartons of cream as a draft. Which egg pack and quantity do you want? I will confirm the delivery run after checking availability.” A reply of “All set for tomorrow” would be wrong even if two lines were interpreted correctly.
Keep customer language in the raw-message field. Put the assistant's interpretation in separate columns. If a kitchen manager says “one box” and the catalogue has both a 6 kg and a 12 kg box, show both candidates and request a choice. The extra question costs less than a wrong pick, credit note and emergency second delivery. If one account uses a private product nickname, add it as an account-specific alias only after a member of staff confirms it.
A prompt that extracts without accepting
For a manual pilot, provide a small catalogue excerpt, the selected account's aliases and the cut-off table. Ask for structured output with uncertainty visible. The prompt below is designed to produce a draft for staff. It does not grant the assistant authority to message the customer or update the order ledger. If customer data is sensitive, use an approved business account and your data policy; remove unnecessary phone numbers and personal details from a test export.
You are drafting a food-distributor order for staff review.
Use only the supplied catalogue, account aliases and cut-off rules.
Do not infer pack sizes, stock availability, prices or delivery promises.
Return: raw phrase, candidate item code, quantity, unit, confidence reason,
question needed, and proposed run. Mark any missing field UNRESOLVED.
Message time: [timestamp and time zone]
Account: [account reference]
Message: [customer text]
Catalogue: [approved excerpt]
Cut-off table: [current rows]An illustrative output for “three cases of tomatoes, two cream, same eggs” might assign the tomato code T12 with quantity 3 cases, leave cream unresolved because two pack sizes exist, and leave eggs unresolved because “same” has no explicit quantity in the current message. It may mark the requested run as “eligible by time, pending stock and account checks”. Staff should fix any output that treats an alias as a confirmed code without showing the match. Ask the model to quote the exact raw phrase for each line; that makes the review faster.
Do not ask AI to calculate an order total from unverified prices. Customer-specific contract prices, promotions and deposits belong in the order system. An assistant can bring the relevant price row to a reviewer, but the final amount should come from the maintained price file. If prices change between order receipt and acceptance, record the effective version and make the customer-facing policy clear. The related wholesale email order extraction tutorial covers a similar intake problem on a different channel.
A complete cut-off and confirmation calculation
Consider an illustrative distributor with two delivery runs: ambient R1 closes at 16:00, chilled R2 at 14:00. A restaurant's message arrives at 13:52 asking for three cases of tomatoes, two cartons of cream and one tray of eggs for the next day. The catalogue lists tomatoes in 5 kg cases, cream in 1 litre cartons and eggs in 30-unit trays. The account is active and eligible for both runs. The assistant extracts three lines, but the eggs phrase says “one tray” and the account's contract lists two egg grades. It flags the grade for a question.
At 13:56 the restaurant replies “medium eggs”. The complete order is now inside both deadlines. The stock file has three tomato cases and one cream carton available; a second cream carton is due from a supplier but has not been received. The assistant should show staff: tomatoes 3 accepted, cream 1 available plus 1 unavailable, eggs 1 medium tray available. Dispatch confirms capacity on both temperature compartments. Staff offer either one cream carton on the next run or one carton now and one later. The restaurant accepts one now. Only then does the order system reserve stock and issue confirmation number 2184.
The final illustrative confirmation says, “Order 2184 is confirmed for the next eligible delivery: three 5 kg cases of tomatoes, one 1 litre carton of cream and one tray of medium eggs. The second cream carton was not included. Please reply with order 2184 if you need a change; changes after the published cut-off require dispatch approval.” This gives the restaurant an actionable record. A separate “received” acknowledgement at 13:52 should never have looked identical to this confirmation.
Now shift the same scenario: the egg grade arrives at 14:07. R2 chilled has closed under a policy requiring a complete order by 14:00. The assistant can still prepare the ambient lines for R1, but cannot silently split the order. It should present the choice to staff and restaurant: accept ambient items on R1 and chilled items on the later run, or request a dispatch exception. This is why a single “tomorrow yes/no” flag is inadequate for a mixed-temperature basket.
Six edge cases worth rehearsing with real messages
A duplicate after a weak connection: a customer sends the same eight-line message twice, four minutes apart. Compare account, message content and time window, then show staff a possible duplicate. Do not delete either message. The second could be an intentional repeat order, so the customer or reviewer must decide. A useful pilot metric is the number of duplicates caught before order entry and the number of false alarms.
A change after acceptance: “make the cream three instead” arrives after confirmation 2184. The assistant should reference the accepted version, show the difference from one to three, check available stock and cut-off again, and wait for a revised confirmation. It should not edit the original record without a version trail. This preserves the picking team's understanding of which instruction is current.
A standing order with a holiday override: one restaurant normally takes four flour sacks each week, but the upcoming delivery run has moved. The assistant may pre-fill a draft from the standing order and the current calendar. It must display the altered run and request approval if that is your policy. Hard-code the holiday override in the schedule table; a model's knowledge of a public holiday is not a substitute for the distributor's actual operating plan.
A photograph with a crossed-out number: the image appears to say “12” cases, with “2” written over the top. A human must inspect the original. The assistant's output should say “quantity unreadable” and retain the image reference, not pick the number with the highest model confidence. For high-value or short-dated stock, use the same rule on any unclear unit or product grade.
A restaurant asks for an unavailable substitution: it orders a particular oil and writes “any equivalent is fine”. That is not an open-ended licence for the AI to choose. Maintain an approved substitute list with pack size, ingredient and price checks. Staff confirm the exact alternative. An ingredient-related change can affect the restaurant's menu information, so even a familiar substitute deserves an explicit line in the confirmation.
A voice note arrives near the deadline: a recording at 13:59 might be transcribed at 14:02. Your policy needs to specify whether receipt or completed transcription controls the deadline. The safe default is to record the original media timestamp, mark the content pending, and let a person decide an exception if the order was not complete in written form before the cut-off. Explain this policy to customers rather than letting staff make inconsistent promises.
Assign the hand-off before enabling replies
Designate who sees drafts during ordering hours, who covers absences and what happens to after-hours messages. Give the assistant explicit escalation triggers: uncertain product or unit, missing account, unavailable stock, credit hold, price dispute, cold-chain requirement, aggressive or distressed customer, amendment to an accepted order and any cut-off exception. The hand-off should include the full transcript, message timestamps, extracted lines, rules applied and the exact unanswered question. A staff member should be able to act without rereading a long conversation from the start.
Set two clocks. The customer acknowledgement clock measures how quickly a message is received and assigned. The confirmation clock measures when a checked order enters the order system. If the inbox is unstaffed after 17:00, say so in the acknowledgement and give the next review time. Do not conceal a queue behind a conversational “I'm handling it” response. For broader safe-reply design, see the WhatsApp AI reply safety tutorial.
Cost the messages from Meta's developer pricing page, which reflects changes effective 1 October 2026: each business phone number gets 1,000 free delivered service messages a month, Meta charges from the 1,001st, and utility messages sent inside an open customer service window are now charged too. Meta's marketing pricing page still describes service messages as free, so treat the developer page and your provider's quote as the working figures. A quick illustrative sum: 40 restaurant accounts each ordering on 25 days a month, with four replies per order inside the window (acknowledgement, a clarification, a substitution answer and the confirmation), make 4,000 service messages a month, so about 3,000 fall beyond the free tier on one number. If the replies come from Meta's own AI agent, the same page lists $2 per million tokens, which Meta puts at roughly 4–5 cents a message. Budget software and message charges separately from the time spent maintaining catalogue aliases, cut-off rows and exceptions. The WhatsApp Business app and the platform are different operating choices. A low message volume may justify a staff-assisted pilot before any integration purchase.
Test the route from message to pick list
Use a small set of historical messages with permission and remove personal details where possible. Include the six cases above plus ordinary orders. Before using AI, write the expected account, item codes, quantities, units, eligible run and exact customer reply for each. Then compare the assistant's draft to that answer key. Do not measure only whether it extracted a product name. The important errors are a wrong unit, an unearned delivery promise, an omitted line, a duplicate order, or an amendment attached to the wrong version.
Run the pilot with staff review on every order. Count complete orders, clarification requests, correct cut-off assignments, late exceptions, stock rejections and confirmation corrections. A useful acceptance gate might be zero unreviewed confirmations and zero wrong delivery commitments across the pilot set, with any extraction error visible before order entry. That gate is an internal decision threshold, not a claim about what AI products achieve. Recheck the catalogue and route table whenever prices, packs or delivery days change.
The final daily audit is simple: compare WhatsApp conversations that contain an order request with the accepted orders for that day. Every request should be either confirmed, waiting for a named clarification, declined with a reason, or handed to staff. Compare confirmed versions with the warehouse pick list before the vehicle leaves. If an order is present in chat but absent from the ledger, investigate the missing hand-off. If it is in the ledger twice, investigate duplicate detection. That comparison protects customers more reliably than a fluent acknowledgement.
Questions before the first restaurant order
Can the assistant promise delivery when an order arrives before the cut-off?
No. Arrival before the cut-off only makes the order eligible for that delivery run. Stock, account terms, minimum order and vehicle capacity may still prevent acceptance. Use a received acknowledgement first, then send a confirmed order number and delivery date after the checks pass.
What if a restaurant edits an order in a second message?
Link the amendment to the original order reference and show the old and new quantities side by side. If the change crosses a cut-off, changes a chilled item or affects a reserved quantity, hold it for a person. Never silently create a second order from a follow-up message.
Should WhatsApp be the order system of record?
Use it as a convenient intake channel. Keep the accepted order, version, stock allocation, price and delivery commitment in the distributor's actual order system or controlled ledger. The chat transcript helps explain a dispute, but a conversation alone does not reliably show which version was picked.
Further reads
- How to Set Up a WhatsApp AI Chatbot for Your Business — Map a business-specific bot setup.
- How Much Does a WhatsApp Chatbot Cost? Fees, Tools and Setup — Budget for messaging and software.
- WhatsApp Customer Service With AI: Setup, Costs, and Limits — Plan service replies and hand-offs.
- AI for Restaurant Order Management: One Queue for Every Channel — See the restaurant's purchasing side.
- Can an AI Chatbot Handle Order Tracking and Returns? — Separate order intake from status replies.
- AI Agents for Distributors: Answer Stock and Delivery Queries Safely — A controlled stock, price and delivery enquiry workflow with source timestamps, test cases and sales-desk handover.
- Cold Chain Temperature Logs: AI Flags Breaches in Logger Exports — How a small food distributor can use AI on logger exports to find breaches, spot gaps and faulty sensors, and draft the corrective-action note.
- AI Tools and AI Development: The Complete 2026 Guide — the AI hub, including every tutorial in the AI-for-business series.
Sources: Meta Terms for WhatsApp Business Platform (section 4.7, last modified 23 September 2026), WhatsApp Terms for WhatsApp Business Platform and WhatsApp Business Messaging Policy (both 23 September 2026), Meta WhatsApp developer pricing page (changes effective 1 October 2026), all read 5 November 2026. Cut-off, stock and message-volume examples are illustrative.