Order & returns orchestration without chaos: one OMS flow for all your channels

When orders from Shopify, marketplaces and physical retail come together in one operational chain, spontaneity rarely emerges – but friction almost always does. Duplicate tickets, delayed deliveries, inconsistent inventory information and returns that remain administratively unresolved for months are not incidents, but symptoms. The problem is not in one single system. It is in the absence of orchestration.

Order- & retour-orkestratie

“Multichannel complexity does not arise from volume, but from missing control.”

Many organisations try to solve multichannel complexity by further expanding their ERP or by stacking separate integrations. That works temporarily, until volumes increase, SLAs become tighter and customer expectations rise. Then what is missing becomes visible: a central, intelligent orchestration layer that controls orders and returns across all channels.

“As soon as multiple systems believe they are leading, nobody owns the chain anymore.”

A lightweight Order Management System (OMS) layer on top of existing systems can do exactly that. Not as a replacement for ERP or commerce platform, but as a director. This article describes how to establish a scalable, controlled order flow in ten working days that brings calm, speed and controllability to a multichannel environment.

Why ERP and commerce platforms cannot solve this on their own

In a multichannel context, three structural tension points therefore arise. First, data models differ per channel. Marketplace orders contain different fields and status logic than webshop orders. Second, fulfilment is often spread across multiple warehouses or 3PLs, each with its own cut-off times and service levels. Third, returns follow channel-specific rules, which leads to inconsistent stock returns and financial settlement.

An OMS layer addresses these tensions by normalising orders into one internal model, centrally managing routing rules and publishing statuses back to all channels as the single source of truth. In doing so, operations shift from reactive correction to proactive control.

The end-to-end order flow as a control process

In a well-designed architecture, orders start as events. Webhooks from Shopify, marketplaces or POS systems are not sent directly to the WMS, but are first processed by the OMS. This is where normalisation takes place: order lines are harmonised, customer data is validated and duplicate events are neutralised through idempotency keys.

The OMS then checks business rules. Think of address validation, payment status control and cut-off logic. Only then is a pick/pack/ship instruction sent to the correct WMS or 3PL. Every status change – from allocation to shipment – is then published again as an event to channels, customers and analytics layers.

Returns follow the same logic in the opposite direction. An RMA request creates an event that is validated by the OMS against channel rules and return windows. Only upon physical receipt and inspection is inventory adjusted and crediting triggered. Not date-driven, but event-driven.

This event-driven approach ensures that one consistent truth is created, regardless of how many systems are involved.

Data model as the foundation of scalability

Enterprise orchestration begins with a tight data model. That does not mean complexity, but discipline. Every order must contain a channel-bound order_id as well as an internal oms_order_id. Order lines must explicitly record SKU, variant information, quantities, price, tax and any bundle relationships. Delivery information such as shipping method, carrier and priority must not be a free text field, but must be interpretable through rules.

The use of idempotency keys is crucial. In a multichannel environment, webhook events regularly arrive more than once. Without idempotency, the risk of duplicate allocations or even duplicate shipments arises. An OMS that recognises events and processes them only once prevents operational damage and reputational risk.

“Idempotency is not technical finesse. It is risk management.”

By storing events in an event store and using relational data for reporting, both real-time control and analytical depth are created. That is not a technical luxury, but a governance requirement at scale.

Orchestration rules as a strategic instrument

The real value of an OMS lies not in forwarding orders, but in the intelligence of routing and prioritisation. Routing can be based on inventory availability, country, service level, logistics costs or margin impact. Prioritisation can be SLA-driven or take VIP customers and backorders into account.

Cut-off rules determine whether an order is still shipped via depot A or automatically shifted to depot B. Bundle rules can combine multiple orders from the same customer when the ETA matches, reducing shipping costs and improving sustainability.

By making these rules manageable – for example through JSON configurations or a simple management interface – operations shift from hard-coded IT dependence to business-driven flexibility. That is essential for organisations that want to respond quickly to seasonal pressure or market changes.

Returns orchestration as margin control

Returns are not a side issue, but a direct margin factor. Without central orchestration, returns are processed administratively, but ignored strategically.

Channel-specific return windows are managed centrally. Automated label generation and tracking create transparency for the customer. Crediting takes place based on receipt and inspection events, not on preconfigured calendar rules.

By linking return data to SKU and channel reporting, insight into structural problems is created, such as disproportionate return rates per product variant. That enables marketing and procurement to implement targeted optimisations.

Status synchronisation as reputational protection

A common problem in multichannel environments is the “ghost status”. A marketplace shows “shipped”, while the warehouse still has to pick. Or a customer receives no delay notification because systems do not inform each other.

When the OMS publishes every status change as the central truth, this noise disappears. Customers receive consistent ETAs via e-mail or other notification channels. Marketplaces remain synchronised, preventing penalties and reputational damage. Analytics dashboards receive the same event data, making reliable reporting possible.

This consistency is not an operational detail, but a brand promise.

KPIs that are enterprise-relevant

Instead of focusing on superficial metrics such as total shipped orders, it is useful to measure p95 order throughput time – the time between placement and shipment for 95 percent of orders. This metric makes exceptions visible without being distorted by outliers.

In addition, fulfilment accuracy, on-time shipping percentage and cost per shipment are strategic indicators. By including bundling effects and return impact in cost calculations, a more realistic picture of channel profitability emerges.

Return rate per channel or SKU can also reveal structural product or expectation problems. Combined with OMS data, this creates an integrated view of logistics performance and commercial profitability.

Architecture: lightweight but enterprise-proof

An effective OMS architecture does not need to be heavy. Webhooks form the primary ingest, with fallback polling where external parties require it. A message broker such as SQS or RabbitMQ ensures reliability and asynchronous processing.

Small services for routing, RMA processing and notifications make the system modular and scalable. Observability through structured logging, trace IDs and a dead-letter queue prevents errors from going unnoticed. Without a DLQ, exceptions disappear into nothing and operational debt accumulates.

This architecture enables rapid iteration without compromising reliability.

Implementation in ten working days: from proof of concept to control

A pragmatic implementation starts by connecting one webshop and one marketplace. Mapping and idempotency form the basis. Routing rules and cut-off logic are then linked to one WMS or 3PL.

The status flow back to channels and customers is then configured. Only when the outbound flow is stable is a first RMA type added. Dashboards for p95 throughput time and return rate make performance transparent.

Edge cases and load tests ensure that the system remains stable under peak pressure. By first running in shadow mode – in which all events are logged but not yet actively forwarded – operations can validate with low risk. Only then is the switch made to active write modes.

This phased approach minimises disruption and maximises learning capacity.

Common mistakes in OMS implementations

One of the biggest mistakes is wanting to centralise all logic in ERP. ERP must remain financially correct; orchestration belongs in a separate layer. A second mistake is ignoring idempotency, which leads to duplicate shipments. Equally problematic is the absence of a dead-letter queue, which makes errors invisible.

In addition, hard-coded business rules are often chosen. That limits agility and increases dependence on IT. Finally, communication to the customer is set up too late or too narrowly, while proactive ETA communication is precisely what creates trust.

Conclusion

Multichannel fulfilment does not become complex because of the number of channels, but because of the absence of central control. A lightweight OMS layer on top of existing systems brings structure without requiring ERP or commerce platform to be rebuilt. By normalising events, centrally managing routing rules and strategically orchestrating return flows, control over speed, costs and customer experience emerges.

“An OMS does not add complexity. It removes hidden complexity.”

Those who start with a controlled proof of concept, measure on p95 throughput time and expand in a scalable way are not building a technical extra layer, but an operational control instrument. In a market where delivery reliability and return control have a direct impact on margin and brand perception, that is not an optimisation project – but a strategic necessity.