Do we need automatic message parsing to fill the fields?

Not at the start. Filling a draft record that already exists is faster than copying into a sheet, and it produces the data that tells you which fields are genuinely missing. Automatic extraction pays off once the fields and the states are stable, not before.

What do we do when a customer orders through three channels at once?

Merge on the customer identifier, not on the channel. The order is one record with a field naming the channel it arrived on, and events from several channels can attach to it. Duplicating the order per channel produces a double delivery, which is the more expensive mistake.

Can we send a proactive status update at any time?

Not at any time as free text. On the WhatsApp Cloud API, reaching a customer outside the 24-hour window from their last inbound message requires a pre-approved template. That is why order-confirmation and reminder templates need to exist before any process depends on them.

How many states should we define?

Enough that there is a state for every point where somebody is waiting on somebody else. Six to eight covers a typical service business. Beyond that people pick the first state that looks plausible, and the queue stops reflecting reality.

Orders Arriving on WhatsApp - Yehonatan Saadia

A message in a conversation is not an order. It is missing the three things that turn a request into a commitment: an identifier you can search on, an owner who is responsible for it, and a due state you can tell has passed. The answer is not copying it by hand into a sheet, but an intake point that creates a draft record linked to the conversation and asks for what is missing.

The three things a conversation lacks and an order must have

In a chat carrying forty messages a day it is easy to believe everything is handled. Three things are structurally missing, not because anyone is disorganised:

An identifier. You cannot say "Ronit's order" on somebody else's phone. An order needs a number that appears in the chat, on the record and on the delivery note.
An owner. On a shared phone or in a group chat everyone sees it and nobody is accountable. A message that has been read looks handled.
A due state. "We'll sort it tomorrow" is not a date. Without a date field you cannot produce a list of what is late.

The common failure is not a lost message. It is a message that was read, understood, and became nobody's action. Handling volume on this channel and the technical failures that come with it are covered in a high-volume WhatsApp message queue.

The intake point: where a conversation becomes a record

The intake point is one rule: every inbound customer message creates or updates an order record in draft status, linked to the phone number and to the message identifier. The record is created even when the message is only "hi". A queue full of empty drafts is better than an order that exists only in somebody's memory.

Three design decisions determine whether this works:

What identifies a returning customer. The phone number in a normalised format, not the display name on the profile. Profiles change, numbers do not.
What triggers a new draft rather than an update. The simple rule that works: a message arriving while an open draft exists for that customer joins it, otherwise a new one opens.
What happens to images and files. Download and store them immediately, linked to the record. A temporary URL saved as text is a file that will not be there when somebody looks for it.

One real channel constraint matters here: on the WhatsApp Cloud API you can send a free-form text message to a customer only within a 24-hour window from their last inbound message. Outside that window you may only reach them with a pre-approved message template. The design consequence is that a proactive status update is not always sendable as free text, so confirmation and reminder templates need to be prepared and approved before anything depends on them. The build walkthrough is in how to create a WhatsApp bot.

The state machine, and the rule that moves each transition

State	Meaning	What moves it on	What the customer sees
Draft	Created from a message, unreviewed	A rep opens it	Nothing
Awaiting details	At least one required field is missing	The customer supplies it, or a rep fills it	A targeted question about what is missing
Awaiting price	Details complete, price not set	Internal pricing	A note that the request is in progress
Awaiting customer approval	A priced summary has been sent	An explicit customer confirmation	The full summary to review
Approved	A commitment exists	Release to fulfilment	Confirmation with an order number
In fulfilment	Being worked	Completion or a problem	Updates at defined points
Completed	Delivered	-	Delivery confirmation
Cancelled	Closed without fulfilment	-	Cancellation notice with a reason

Two of these tend to disappear in implementation, and they are the important ones. Awaiting details is what stops an order progressing with half an address. Awaiting customer approval separates what the rep understood from what the customer said, which is exactly where disputes are born. General models for managing customers over this channel are discussed in WhatsApp-based CRM for business.

Which fields must be complete before leaving "awaiting details"?

Field	Example	Why it blocks
`order_id`	W-2026-1187	Without it there is nothing to name in a follow-up chat
`customer_phone`	Normalised international format	The key for recognising a returning customer
`items`	2 x pack of 12, 1 x pack of 6	Quantity and item, not free text
`delivery_address`	Street, number, city, floor	A partial address sends the driver back
`requested_date`	2026-05-14	With no date there is no lateness and no queue
`price_total`	486	The basis for customer approval
`owner`	Michal	Who is accountable when it stalls
`source_message_id`	The wamid of the original message	The link back to the conversation

The second field decides more than it looks like it does. A phone number stored once with an international prefix, once without, and once with a dash produces three different customers for one person, and with them three separate histories. Normalising once on the way in removes all of it. I build these for clients - see AI chatbot development.

How do you handle a customer who changes the order in a later message?

You do not edit the row. A change after approval is a logged correction that returns the order to an earlier state and leaves the original readable:

Record the change message as an event on the order, with its message identifier and time.
Return the order to awaiting customer approval when the change touches items, quantity, price or date.
Produce a fresh summary showing the state after the change, not only what was added.
Ask for explicit approval before returning to approved.
Keep the previous version as a readable record, including exactly what moved.

A change arriving after the order has been released to fulfilment is a separate case: it does not roll the state back but opens its own change request, with an explicit decision on whether it is accepted. Without that separation, "can you add one more?" at 16:40 becomes a second pick that nobody priced.

What the work queue has to show at eight in the morning

Orders in awaiting details for more than 24 hours, with the name of the missing field.
Orders in awaiting customer approval sent yesterday and not answered.
Approved orders with today's requested_date, in sequence.
Orders past their due date and not completed.
Conversations with an inbound message that was never read.
Conversations whose 24-hour window has closed, so it is obvious an approved template is required.
Orders with no owner.

The last row is a health check on the process itself. An order with no owner is not a data error; it is a message nobody picked up - precisely what the system exists to prevent. The same approval-queue principle over unstructured input is covered in orders arriving as PDFs by email.

What actually breaks

An employee's personal phone. The employee leaves and the customer history leaves with them.
A voice note containing the order. No field fills itself from it, and it stays a task that requires somebody to listen.
Answering inside the chat without updating the record. The customer got a reply, the queue still says waiting, and nobody trusts the queue any more.
Two people answering one conversation. Two prices for one order and a contradictory summary.
Free text as a line item. "The usual for Tuesday" cannot be priced automatically and cannot be printed on a delivery note.
An unapproved template. A proactive reminder outside the 24-hour window is relied on and simply never sends.

Sources

WhatsApp Cloud API - developer documentation

Orders Arriving on WhatsApp: Turning a Conversation Into a Work Queue Without Losing a Commitment

Key takeaways