Should a retailer join instant-commerce platforms before rebuilding its store systems?
Conclusion: platform onboarding and store-system improvement should be one staged decision, not competing projects. Most retailers should validate demand with a small set of stores, products and one channel while correcting the few system gaps that directly cause missed orders, overselling, late fulfilment or unexplained settlement differences. Expand only when the pilot proves both customer demand and an operable unit model. If product, stock and order records are already unreliable, stabilise those records before adding traffic.
Who this is for
This framework is for retailers, restaurants, pharmacies, supermarkets and chains that already use some combination of POS, inventory, ERP, membership or store-management software and are considering on-demand delivery marketplaces. It also applies where a marketplace is live but staff still re-key orders, adjust stock manually, process refunds outside the operating system or rebuild settlement reports at month end.
China's National Bureau of Statistics reported in August 2026 that online retail of goods and services grew 4.8% year on year in the first seven months, while online retail of food products grew 16.9%. Among enterprises above the designated size, 28.7% of retail sales were made through the internet. These figures justify evaluating the channel; they do not establish that every store has a profitable local model. A buyer still needs evidence from its own order density, margin, fulfilment cost and repeat demand.
Four decisions before committing the budget
1. Is there local demand that can be measured?
Select one to three representative stores, a limited catalogue and a defined delivery area. Record discovery, orders, cancellations, substitutions, out-of-stock events, basket value, fulfilment and repeat purchase. Marketplace-level growth forecasts are not a substitute for store-level evidence, and a full network rollout should not precede a controlled trial.
2. Can product and stock records support a live promise?
Check product codes, variants, prices, selling units, eligible stores and availability status. When POS, warehouse and marketplace records use different identifiers—or stock updates only after closing—more orders can create more substitutions, cancellations and customer-service work. A pilot may expose only stable products, but it still needs a traceable inventory source rather than staff memory.
3. Can the store fulfil within the offered service window?
Walk through acceptance, picking, weighed-item adjustment, packing, courier handover, cancellation and after-sales handling. Staff need one clear queue, exception ownership and a history of state changes. If peak-hour operation depends on several phones and verbal coordination, improve the store workbench and exception flow before adding stores or marketplaces.
4. Can finance explain each order?
Marketplace GMV is not net cash. Separate merchandise, merchant-funded and platform-funded discounts, delivery, service charges, refunds, compensation and settlement. Finance should be able to move from a total to the source order. If sampled orders cannot be explained, GMV alone is insufficient evidence for expansion.
Three practical starting paths
| Current position | Recommended sequence | Initial scope | Decision being tested |
|---|---|---|---|
| Demand is unproven and core store processes work | Run a controlled marketplace pilot first | Few stores, stable products, reviewed inventory and settlement | Whether the channel and fulfilment model are viable |
| Orders are stable but re-keying and reconciliation consume the team | Build the minimum integration first | Order intake, product mapping, stock, refunds and settlement | Whether automation removes operational friction |
| Product, stock, price and store identifiers are unreliable | Repair the operating ledger before scaling | Master data, inventory movements and order states | Whether the business has a dependable foundation |
“Marketplace first” does not mean an uncontrolled manual launch. “Systems first” does not mean replacing the ERP. The first release needs one complete loop: an order reaches the store, the stock promise has a source, exceptions have an owner and the cash can be reconciled.
A staged implementation scope
Stage 1: map the current operation and reconcile samples
List stores, channels, systems, commercial accounts and owners. Sample successful orders, substitutions, customer and store cancellations, partial refunds, courier exceptions and settlements crossing business days. Decide which system is authoritative for product, stock, order, fulfilment and cash at each point.
Stage 2: complete the loop in one representative store
Connect one marketplace and one store. Deliver product mapping, sellable-stock rules, order acknowledgement, exception alerts, refund state and daily settlement. Human review can remain during the pilot, but every intervention needs an owner and reason; a private spreadsheet must not become a second invisible ledger.
Stage 3: test failure and peak conditions
Exercise duplicate marketplace notifications, network loss, delayed inventory, temporary delisting, weight differences, partial refunds, failed courier pickup and store closure. The system needs retries, alerts, human takeover and a recovery history. A normal order completing once is not acceptance evidence.
Stage 4: expand on evidence
Add stores, catalogues and channels only after the pilot can consistently explain orders, inventory and settlement. Reconfirm product mapping, pricing, store capacity, permissions and finance rules at each expansion; do not copy the first store's configuration blindly.
Cost, value and procurement boundaries
The business case should include marketplace charges, integration and system work, devices and connectivity, catalogue clean-up, training, daily operations, exception handling and ongoing maintenance. Measure contribution after promotions, fulfilment, refunds, waste, marketplace costs and incremental labour—not gross sales alone.
The procurement scope should name the first platforms and stores, the system of record for orders and stock, ownership of commercial accounts and access, exception operations, history migration, monitoring after launch and responsibility when marketplace rules change. Integrate capabilities that the existing estate already performs well; customise missing business rules. One new channel rarely justifies replacing a whole ERP.
Acceptance checklist
- Product identifiers map across marketplace, store and internal systems, with traceable creation and retirement.
- Duplicate order, cancellation, refund and delivery notifications cannot create duplicate stock or cash movements.
- The source, reservation, safety-stock and latency rules for sellable inventory are approved.
- Store staff can work from a clear order and exception queue without monitoring several phones.
- Sample orders reconcile merchandise, promotions, delivery, refunds, charges and cash settlement.
- Outages, timeouts and integration failures have alerts, human takeover and recovery records.
- Head office can analyse by store, channel and period, then drill down to source orders and actions.
- Business, operations and finance jointly approve the conditions to expand, remediate or stop.
Common mistakes
Rebuilding every system before testing the channel. This creates a large design based on assumptions. Establish the minimum reliable loop, then use pilot evidence to decide what merits investment.
Adding marketplaces now and fixing operations after volume arrives. If stock, fulfilment and settlement are already unreliable, traffic magnifies cancellations, complaints and finance differences.
Treating the marketplace console as the retailer's operating system. The marketplace governs its channel. The retailer still needs an accountable view across products, customers, stock, cash and long-term operations.
Accepting the project when an API call succeeds. Sustainable operation depends on exceptions, store execution, data quality and settlement. Acceptance needs a full trading cycle and failure scenarios.
For ownership across several channels, see How should merchants unify customer, order and membership data across livestreaming, deal platforms and mini programs?. For the head-office ledger and store reconciliation, see How should a multi-store system unify data and head-office reconciliation?.
Source
- National Bureau of Statistics of China: Consumer market operation remained stable, January–July 2026 (dated 17 August 2026; accessed 9 September 2026)
This framework supports procurement and implementation decisions. Marketplace availability, charges, operating regions and integration conditions should be confirmed against the relevant commercial account and contract at the time of delivery.