WhatsApp and Direct Order Capture
A restaurant taking direct orders through WhatsApp, phone calls and Instagram messages, alongside two delivery aggregators, with each channel handled by a different person on a different device.
The problem
Direct orders are the restaurant's highest-margin business — no aggregator commission — and they are the worst-handled. Orders are missed, addresses are lost in scroll, and repeat customers are re-asked for details the restaurant already has.
In scope
- One inbound queue for direct orders
- Structured capture
- Customer records with saved addresses
- Repeat-order shortcut
- Order confirmation
- Handoff to kitchen and delivery
- Channel reporting
Out of scope
- The kitchen display
- Stock
- Payments beyond recording the method
- Delivery dispatch and rider management
- Also out: building a consumer ordering app, which this restaurant's customers will not install, and any automation of a personal WhatsApp account — see the trade-off.
What this would cover
Grouped by module — open the ones you want to read.
Inbound queue
- Direct orders from every channel in one list, each tagged with its origin
Structured capture
- Turning a free-text message into an order with items, modifiers, address, delivery time and payment method, in a form designed for speed by someone typing while reading a chat
Customer record
- Built from direct orders: phone, saved addresses with landmark notes, order history, preferences
Repeat order
- A known customer's last order recalled in one action, which is where most of the time saving actually comes from
Address notes
- Free text against a saved address, because "the blue gate after the transformer" is more useful than a street name and is currently in a rider's head
Confirmation
- Order summary and total sent back to the customer before it goes to the kitchen, which removes most disputes
Handoff
- Order passed to the kitchen and, where relevant, to delivery
Reporting
- Order volume and value by channel, repeat-customer rate, and direct versus aggregator mix with commission modelled, which is the number that justifies the whole engagement
Data model
- InboundMessage → Order → OrderLine
- Customer → SavedAddress
- Channel
- Confirmation
- PaymentMethodRecord
Invariants
- Every order carries its channel, permanently.
- A customer is identified by phone number as the primary key, because that is the only identifier consistent across channels.
- Saved addresses are versioned rather than overwritten — a customer who moves should not lose their history.
Offline behavior
Order capture should queue locally so a counter can keep taking orders through a brief outage.
Hard trade-offs
The difficult decisions, stated plainly — not trimmed for length.
Automating a personal WhatsApp account is against the platform's terms and gets numbers banned, usually at the worst moment.
Legitimate integration requires the WhatsApp Business Platform, which means an approved business account, per-conversation messaging costs, and a rule that the business can only message a customer freely within a window after the customer messages first. Outside that window, only pre-approved template messages are allowed. Any vendor offering to automate a normal WhatsApp number is offering a system that will fail. The honest options are the official platform with its costs, or a human-assisted capture screen that speeds up a person reading the chat — which is cheaper, fully compliant, and what this concept defaults to. [FILL: confirm current WhatsApp Business Platform pricing and messaging-window rules at time of scoping; these change.]
End state
What would be true about their day once this is running.
- Every direct order lands in one queue regardless of which app it arrived through.
- A repeat customer's order and address are recalled rather than re-asked.
- A confirmation goes back before the kitchen starts.
- The restaurant can see what its direct business is worth against its aggregator business, net of commission.
This is a deliberate first step toward Restaurant Operations & Channel Control Platform — its data model is designed as a genuine subset, so growing into it later doesn't mean starting over.
Let's map how your operation actually runs.
One session. We look at what's breaking, and what we'd build around it — whether or not you hire us afterward.
Start the operations review