B2B Commerce
B2B Orders on WhatsApp: From Messages to a Controlled Workflow
An operating model for structuring orders, preventing duplicates, validating price and stock, and tracking every status through reconciliation.
Decision supported
WhatsApp should remain the entry and conversation channel, not the order system of record. Once a customer expresses purchase intent, create a structured order with a unique ID; verify customer, items, quantities, price, and stock; then track explicit statuses through delivery and reconciliation.
Executive summary
- Separate the original message, interpreted intent, and approved order.
- Use both the message ID and an internal order ID to neutralise duplicates.
- Do not confirm price or availability before checking the system of record.
- Audit every author, correction, approval, and status change.
Separate conversation from the operational record
WhatsApp supports free text, images, voice notes, and successive corrections. That flexibility helps sales, but does not create an order that stock, fulfilment, delivery, and finance can execute.
Meta provides a unique message ID and webhook status events. Use them as channel evidence, not as a substitute for the internal order ID, approval lifecycle, or business rules.
Verified channel capability
WhatsApp Business Platform provides message IDs and status events. Atlas treats them as transport evidence, not the complete order state.
Use an explicit order lifecycle
Make the difference between what the customer sent and what the company accepted visible. Keep cancellations and rejections as states, never as deletions.
| Stage | Decision | Evidence retained |
|---|---|---|
| Received | Create intent without commitment | Source message, author, date, channel ID |
| Clarification | Request missing information | Question and linked response |
| Approved | Accept customer, items, quantities, and terms | User, tariff version, corrections |
| Reserved | Allocate stock | Warehouse, quantity, expiry |
| Confirmed | Communicate an executable promise | Order number, price, quantity, lead time |
| Fulfilled | Prepare, ship, and deliver | Movements, discrepancies, delivery proof |
| Reconciled | Link delivery, invoice, and payment | Expected and received amounts, variances |
Control model
GS1 separates order, response, dispatch, receipt, invoice, and stock messages. Atlas applies the separation of responsibilities without forcing every SME into EDI.
Define the minimum order contract
Do not confirm until every field that commits the company is determined. Automation may propose values, but uncertainty must be shown to the user rather than silently converted into data.
| Data | Control | Response to ambiguity |
|---|---|---|
| Customer and delivery point | Match customer master data | Controlled selection or creation |
| Item and unit | SKU, pack, selling unit | Request confirmation |
| Quantity | Positive value and pack multiple | Suggest, do not force, the rule |
| Price | Applicable tariff, date, customer, volume | Submit a commercial exception |
| Stock | Availability and reservation rule | Offer partial, delay, or rejection |
| Delivery | Address, slot, constraints | Keep in clarification |
Neutralise duplicates at every boundary
Webhooks can be replayed, customers can resend messages, and operators can double-click. Protect creation, approval, reservation, and confirmation with both channel and internal idempotency keys.
Idempotency means repeating a request produces the same business effect as one execution. Implement it in the service that owns the decision, while also checking current order state and version.
Replay semantics
RFC 9110 defines idempotency by the intended effect of repeated identical requests, enabling safe recovery when the first outcome is unknown.
Automate data entry, not commitment
Extraction may identify a likely customer, items, quantities, and requested date. It must not invent a SKU, choose an ambiguous pack, or promise unreserved stock.
| Situation | Recommended treatment |
|---|---|
| Unambiguous customer, SKU, quantity | Pre-fill and run automatic controls |
| Several possible item matches | Require human selection |
| Price outside policy or margin below threshold | Require commercial approval |
| Insufficient stock | Offer options; do not auto-confirm |
| Contradictory or edited message | Retain versions and request clarification |
Atlas decision
Automation reduces re-entry. Pricing, stock, credit rules, and authorised roles retain responsibility for commitment.
Measure control, not message volume
Compare pilot results with the previous flow on the same scope. Atlas does not claim a gain percentage without a measured customer baseline.
- Time from message receipt to structured order.
- Share of cases requiring clarification and main causes.
- Duplicates neutralised before creation or reservation.
- Variance between proposed, approved, and invoiced prices.
- Confirmed orders later changed for insufficient stock.
- Time and value of reconciliation variances after delivery.
Evidence rule
Less re-entry matters only if errors, post-confirmation changes, and stock variances also decline.
Decisions to make now
Recommended actions
- 01Map the real journey from message to delivery and payment.
- 02Define the minimum record, statuses, and owner of each decision.
- 03Add deduplication keys for messages, orders, and reservations.
- 04Connect price, stock, and credit before customer confirmation.
- 05Pilot with one channel and team, a baseline, and mandatory exception reasons.
Watch points
- An order confirmed in chat but absent from operations.
- An automatically proposed item with no proven SKU match.
- A stock reservation repeated after webhook or request replay.
- Post-approval spreadsheet corrections missing from the audit trail.
Frequently asked questions
Must WhatsApp be replaced?
Not necessarily. Keep the channel customers use, but connect it to a structured record that owns approval, stock, price, and status.
Can AI create the order automatically?
It can pre-fill low-ambiguity fields. Business rules must still validate customer, SKU, unit, price, stock, and authority before confirmation.
How should a post-confirmation change be handled?
Create a change request linked to the order, rerun price, stock, and delivery controls, and retain both versions and the new approval.
Sources and verification
Last editorial verification: 29 August 2026. Links point to the source texts, authorities, and reference guides consulted.
- 01WhatsApp Business Platform: Messages
Meta. Accessed 29 August 2026.
- 02WhatsApp Business Platform: Webhook Payload Reference
Meta. Accessed 29 August 2026.
- 03RFC 9110: HTTP Semantics, section 9.2.2 Idempotent Methods
RFC Editor. Accessed 29 August 2026.
- 04GS1 Electronic Data Interchange standards
GS1. Accessed 29 August 2026.
- 05What kind of messages does GS1 EANCOM provide?
GS1 Global Office. Accessed 29 August 2026.
Related decisions
Continue with briefs that share the same operational, technical, or governance context.
B2B Commerce
B2B Distribution Pricing: Build Explainable and Auditable Rules
Read the briefField Operations
Offline-First Field Software: A Decision Protocol for Reliable Operations
Read the briefCybersecurity
What Algeria's 2025-2029 Cybersecurity Strategy Means for Businesses
Read the briefPractical application
Turn conversations into executable orders.
Atlas CRM connects capture, validation, status, delivery, and reconciliation in one controlled flow.