Orders only become reliable records after someone has worked out what the customer means and what the business can fulfil.
On a screen, an order looks simple: customer, product, quantity, price and delivery. The work behind those fields is less tidy.
A customer may order through WhatsApp using familiar shorthand. A product may have several names. Pack size, substitutions, pricing or delivery arrangements may be understood from earlier orders. Available stock may also differ by batch, processing state, packaging or location.
By the time the order reaches the ERP, a member of staff may already have identified the customer, resolved the products and decided what the business can promise.
The same product may be ordered using a formal SKU, an abbreviation, a Chinese name, a colloquial description or terminology specific to one customer.
Extracting the words from a message is the first step. The system still has to match them to the catalogue and use the customer's context to resolve any ambiguity.
Two units with the same SKU may still differ in ways that matter to the order. Batch, packaging, processing state, location, shelf life and traceability requirements can all affect whether the stock is suitable.
The inventory model needs to preserve the distinctions that staff already use when deciding what can be supplied.
Short stock, substitutions, partial fulfilment, processing requirements and delivery timing all change what happens after an order arrives.
Staff also weigh customer priorities and earlier commitments. These decisions are part of everyday fulfilment, so the workflow has to support them without quietly replacing them with defaults.
An order may arrive in WhatsApp, change during a phone call, be fulfilled through the ERP and then be adjusted by warehouse staff.
The tools can remain separate, but the decisions made in each one need to reach the same operational record. Otherwise the ERP may show a clean order that no longer reflects what the customer and staff agreed.
Design implication
Distribution software has to connect customers, products, inventory and fulfilment while keeping the exceptions between them visible.
Before designing the workflow, Mesograde learns how staff interpret orders, which product and stock distinctions matter, and how the business resolves changes. The system can then connect the customer conversation to the operational record without losing the rules that keep the order correct.
Start with one recurring order type and a handful of real customer messages. Add the product and stock records staff refer to, along with examples of the substitutions or delivery changes they routinely resolve.
This shows where interpretation happens and what a useful first workflow would need to preserve.
Discuss this workflow