---
title: "From WhatsApp to dispatch: how to automate orders without losing control"
description: "An operations map connecting WhatsApp inquiries to orders, payment, inventory, dispatch, tracking, and invoices, with clear systems of record and human review."
author: "Carlos García"
published: 2026-09-10
updated: 2026-09-10
language: en
human_url: "https://kiia.cloud/blog/whatsapp-to-dispatch-order-automation/"
---

> **In 60 seconds:** WhatsApp receives the inquiry and communicates progress; Teams presents alerts and approvals. The ERP, warehouse system, payment provider, and carrier keep the operational records. The workflow validates the customer, creates one version of the order, confirms payment through an authorized source, reserves inventory, releases warehouse work, and communicates dispatch. Suspicious payments, discounts, tax changes, shortages, substitutions, and complaints stop for human review. Start with one measurable segment, use idempotency keys, and send every failure to a queue with an owner and a deadline.

An inquiry that starts on WhatsApp can end up in six places: the chat, a spreadsheet, the ERP, Teams, email, and the carrier portal. Trouble begins when each place tells a different story about the order.

This article uses an anonymous composite case based on patterns common to companies that sell and dispatch physical products. It does not describe one identifiable business or assume that any tool has the required integration. Validate every API, connector, event, and permission against the systems you select.

The scope starts when the customer asks about or confirms a purchase. Prospect follow-up before that point belongs to a separate workflow, covered in our guide to [sales follow-up across WhatsApp and Teams](/blog/automate-sales-follow-up-whatsapp-teams/).

## One system of record for each object

One application does not have to own everything. The team does need to agree which record wins when two screens disagree.

| Object | Proposed system of record | Role of WhatsApp and Teams |
| --- | --- | --- |
| Customer | CRM or ERP customer master | WhatsApp supplies messages and consent; Teams helps staff resolve duplicates |
| Order | ERP or order management system | WhatsApp captures the request; Teams presents exceptions for approval |
| Payment | Bank or payment provider for the transaction; ERP for reconciliation | WhatsApp can deliver a link or receive a receipt, but it does not confirm settlement |
| Inventory | ERP or WMS | Chat reads published availability; warehouse staff resolve physical discrepancies |
| Delivery | TMS or carrier system | WhatsApp communicates confirmed events; Teams alerts staff to incidents |
| Invoice | ERP or authorized accounting system | WhatsApp or email delivers the issued document; Teams does not hold the fiscal original |

This separation prevents a chat reply from changing a commercial state without a trace. WhatsApp and Teams are interfaces that bring the process closer to customers and staff. The primary record needs access controls, history, and a stable way to query state.

## The complete flow, including owners and stop events

Use the following matrix during process design. System names describe functions, not a promise about a particular product.

| Stage | Input | Decision | Output | Owner | Stop or exception |
| --- | --- | --- | --- | --- | --- |
| 1. Identify | Incoming message, phone number, and message ID | Is there one matching customer, and may this channel be used? | Linked customer or case awaiting data | Sales or service | No consent, opt-out, multiple matches, or missing data |
| 2. Confirm order | SKU, quantity, current price, address, and tax data | Do the catalog, terms, and commercial policy agree? | Confirmed ERP order | Sales | Special discount, tax change, ambiguous product, or pending approval |
| 3. Validate payment | Bank or provider event, amount, currency, and reference | Does the transaction match the order and pass controls? | Reconciled payment or pending state | Finance | Suspicious receipt, mismatch, reversal, risk flag, or missing reference |
| 4. Reserve stock | Paid order or approved credit terms | Is usable quantity available in the right location? | Reservation and warehouse instruction | Operations | Shortage, physical discrepancy, restricted lot, substitution, or partial order |
| 5. Pick and dispatch | Released instruction, pick, pack, and label data | Do the parcel and service match the order? | Dispatch with shipment ID | Warehouse and logistics | Damaged item, invalid address, weight mismatch, or unavailable carrier |
| 6. Report delivery | Confirmed carrier event | Is this a new event for the correct shipment? | Customer update and ERP record | Logistics | Conflicting event, failed delivery, return, or complaint |
| 7. Deliver invoice | Issued document linked to the order | Is the approved fiscal version available? | Traceable link or attachment | Finance | Tax correction, incomplete document, uncertain recipient, or delivery failure |

A stop event does not erase earlier work. It changes the state to review, assigns a person, and preserves the reason. The customer gets a careful response, such as an update that the order is being checked, without an invented stock promise or delivery date.

## What can proceed automatically and what needs a decision

Safe automation moves data and executes approved rules. It can validate required fields, look up current prices, create a reservation after the authorized state, record events signed by a provider, update tracking, and send an eligible template containing confirmed operational information. Every action retains its origin and can be stopped.

A person decides when the case changes money, obligations, or the customer relationship: discounts outside policy, suspicious payments, new tax data, inventory discrepancies, substitutions, partial deliveries, returns, and complaints. A person also reviews wording that could become a special commitment. Automation prepares the context and records the resolution; it does not infer the decision from chat.

## How an order would move through the system

### 1. From conversation to a verifiable draft

The incoming message carries a channel identifier. The integration searches for the customer using a stable identifier and presents uncertain matches to sales. It then structures products, quantities, address, and tax data as a draft.

The draft is not yet a confirmed order. Rules can validate required fields and published prices. A person reviews ambiguous language, discounts, special terms, and tax changes. Once the details agree, the ERP creates the order and returns its own identifier.

### 2. From order to reconciled payment

The system can send approved instructions or a payment link. The move to "paid" must come from an authentic bank or payment provider event, or a reconciliation approved by finance. A screenshot sent through WhatsApp is evidence for review, not an instruction to release goods.

The workflow compares the order, amount, currency, reference, and status. Partial payments, duplicates, reversals, and discrepancies remain pending. Finance decides whether to reconcile, reject, or ask for more information.

### 3. From payment to warehouse work

An explicit policy decides whether inventory is reserved when the order is confirmed, credit terms are approved, or payment is reconciled. The ERP or WMS checks quantity, location, unit, and restrictions. When the values agree, it creates a reservation and a picking instruction.

A shortage should not trigger a silent substitution. Operations evaluates partial delivery, a different product, a new date, or cancellation. Sales confirms the choice with the customer when required.

### 4. From parcel to documentary delivery

The warehouse confirms picking and packing. The shipping system returns a label and tracking identifier. Only then does the order move to dispatched and the customer update become eligible.

Carrier events update tracking when they advance the last valid state. Failed delivery, a return, or a complaint pauses routine updates. The invoice comes from the accounting system and is delivered once the correct version is available. Chat never creates an invoice or changes its data on its own.

## Idempotency, retries, and incomplete states

Duplicates appear even in a simple workflow. A customer forwards the same request, a webhook arrives twice, or a service responds late and the platform retries.

Every action with a side effect needs an idempotency key. Order creation could combine the business identifier, message or request ID, and action type. For payments and shipping events, retain the unique identifier provided by the external system. Before repeating an action, the workflow checks whether that key already produced an order, reservation, update, or document.

Persistent states are equally important. One vocabulary might be `received`, `needs_data`, `manual_review`, `confirmed`, `payment_pending`, `paid`, `stock_exception`, `ready_to_pick`, `dispatched`, `document_pending`, `closed`, and `manual_hold`. Every transition records its time, actor, origin, and reason.

Retries handle transient failures. They need increasing delays, a maximum attempt count, and the same idempotency key. A validation error, suspicious payment, or incomplete address will not improve through repetition. Those cases go to an exception queue containing:

- a readable reason and the missing data
- links to the order and original event
- an owner, priority, and response deadline
- an action to resume, cancel, or keep the hold
- attempt history without unnecessary sensitive data

The dashboard should expose incomplete states as they age. An order left in `document_pending` for hours may need attention even when dispatch succeeded.

## Current WhatsApp rules that affect the design

The [WhatsApp Business Messaging Policy](https://business.whatsapp.com/policy) requires the person to have provided their phone number and opted in to subsequent messages. The business must also honor opt-out requests. Store the source, date, and scope of consent in the customer record.

On the WhatsApp Business Platform, a business may only initiate conversations using approved message templates. It may reply without a template within 24 hours of the user's last message; outside that window, it may only send approved templates. The same policy allows automation within the window when prompt, clear, and direct paths to a human are available.

An order update therefore needs channel eligibility, the right template and language, and a confirmed operational event. A complaint should pause routine messaging and offer human support. We checked these rules against the official policy on September 10, 2026, but Meta may update them. Check again with Meta and the selected provider before publishing or enabling the workflow. The business case should not depend on a fixed messaging price.

## A staged pilot

Before choosing tools, apply the method in [what to automate first](/blog/what-to-automate-first-in-a-business/) to this chain. Select the segment with reliable data, clear rules, and an available owner.

1. Map ten to twenty recent orders, including duplicates, shortages, and complaints. Define states, systems of record, permissions, and owners. Measure the current process.
2. Automate from confirmed order to warehouse instruction. Keep suspicious payments, inventory exceptions, and outbound messages manual.
3. Add verified payment and dispatch events. Test duplicates, retries, outages, and reversals before increasing volume.
4. Add WhatsApp updates with approved templates and human escalation. Begin with one update type and a narrow customer group.
5. Deliver the already issued invoice or document and measure pending cases. Expand only when the exception queue has enough capacity and a named owner.

Measure median and 95th percentile time from confirmed order to warehouse release, and from release to dispatch. Add the percentage of duplicate orders, cases entering the exception queue, retries recovered, human review time, dispatches with tracking delivered, and orders with invoices delivered. Monitor opt-outs, blocks, and complaints related to messaging as well.

Processed volume alone says little. The pilot works when it reduces waiting without increasing incorrect orders, false promises, or invisible work. If one stage produces too many exceptions, narrow the workflow and repair the data or policy before continuing.

## What Kiia would build first

Kiia would start with the state map, one system of record for each object, and the segment between confirmed order and warehouse release. The payment event, dispatch, and customer communication would follow, each with an audit trail and manual holds.

A useful first version does not need to decide on people's behalf. It needs to give them enough context for sensitive cases while letting routine work move without losing traceability.

## Frequently asked questions

### Can WhatsApp be the system of record for an order?

No. WhatsApp holds the conversation, while the confirmed order belongs in the chosen ERP or order management system. A message may trigger an action without replacing that record.

### Can an order be marked as paid from a receipt sent in chat?

Not automatically. Paid status must come from the bank, payment provider, or an approved reconciliation. A suspicious receipt, mismatched amount, or missing reference needs human review.

### Which decisions should keep human approval?

Discounts outside policy, suspicious payments, tax changes, stock exceptions, substitutions, special delivery commitments, and complaints.

### How does the workflow avoid creating two orders from one message?

Each operation uses an idempotency key, stores the channel and ERP identifiers, and checks the previous result before retrying. Ambiguous cases go to an exception queue.