Warehouse Management Systems were designed for a warehouse that was simpler than the ones we operate today. The original WMS problem was tracking: knowing where inventory was, directing workers to the right location, maintaining accurate records. Inventory tracking remains essential, but complex sites also need coordination across resources. The problem that has replaced it is harder: coordinating dozens of resource types, workers, AMRs, conveyors, sorters, dock doors, against thousands of simultaneous orders, each with different SLA profiles, in real time.
Traditional WMS architecture was not designed with real-time orchestration across automation, labour and systems as a primary requirement. It was designed to manage. The emerging category, Warehouse Orchestration System, is designed to orchestrate. This article explains the distinction, what orchestration requires, and where the market is going.
Traditional WMS manages inventory records and workflow logic. It knows what is in the warehouse, where it is, and what workflow should be applied to each transaction. It allocates orders to waves, directs picks to locations, and records the completion of each task.
This is necessary and valuable. But it is not sufficient when the warehouse includes automation that needs real-time task coordination, when orders have mixed SLA profiles that require continuous priority recalculation, or when operational conditions change mid-shift in ways that require dynamic resource reallocation.
Some legacy WMS architectures, built around batch processing, wave planning and static workflow logic, make real-time orchestration difficult to achieve by adding modules alone. Modern WMS products, however, may include or integrate execution capabilities; Manhattan, for example, documents WES built into its WMS. The practical test is how a given platform behaves under load, not the category label.
Orchestration is the real-time coordination of all physical resources, human and automated, toward the optimal execution of the current order queue, with continuous adaptation as conditions change.
Four capabilities define genuine orchestration:
Real-time task allocation across all resource types. Every available resource, worker in zone C, AMR completing a delivery, pick-to-light station clearing, draws from a unified task queue. Task assignment considers the current state of every resource and every pending task simultaneously. This is different from wave planning, which allocates tasks in bulk at fixed intervals.
Continuous priority recalculation. SLA pressure changes throughout the shift as orders arrive, as pick progress is recorded, and as resource availability fluctuates. An orchestration layer recalculates order priority continuously and adjusts resource allocation accordingly. Priority can be configured so that the highest-risk order is elevated across eligible resources, subject to capacity and safety constraints.
Proactive exception management. The orchestration layer monitors all operational metrics in real time and flags deviations before they become failures. A throughput rate that is falling below the trajectory needed to hit SLA is an alert at 9:30am, not a miss discovered at end of shift.
Predictive and adaptive optimisation. Beyond responding to current conditions, an advanced orchestration system uses historical patterns and current trajectory data to anticipate likely constraints, such as a zone that is trending toward congestion given the current task distribution, and adjusts task allocation to reduce the risk before it materialises. These are probabilistic estimates, not perfect foresight.
Stackbox WOS is Stackbox's framing for a warehouse system built around these orchestration principles, combining WMS inventory and order management with WES real-time execution and orchestration in a single platform. The WOS framing is Stackbox's own product positioning; it is not an established industry-standard category term, though the capabilities it describes (real-time multi-resource orchestration) represent a genuine evolution from traditional WMS architecture.
The unified platform means that the system managing inventory records is the same system making real-time task allocation decisions. There is no middleware required between the WMS and the execution layer, which reduces the data latency that middleware can introduce and reduces the integration maintenance overhead of multi-system architectures.
Stackbox reports 2x throughput of automation hardware. This is a Stackbox-reported figure, not an independently audited result, and actual results will depend on the operation's starting configuration, the degree of automation in place, and the quality of the implementation.
If your operation is currently evaluating WMS and you have automation today, or plan to add it within 3 years, the relevant evaluation question is not whether the WMS has an automation integration module. It is whether the platform can orchestrate automation alongside human workers in real time, from a unified task queue, with continuous SLA prioritisation.
A WMS that handles automation through a third-party middleware layer can introduce latency and coordination gaps depending on integration architecture and update frequency. Middleware can also add cost, an additional vendor relationship, and another component to maintain. How much this matters depends on measured response time and the specific architecture.
For operations without automation and without near-term automation plans, a traditional WMS that handles your workflow complexity and integrates cleanly with your ERP is likely the right choice. Orchestration capability is most valuable when there are multiple resource types to coordinate.
Moving to a WOS does not replace ERP. ERP manages the financial record, procurement, supplier relationships, and customer order management. WOS manages physical execution within the warehouse. These are complementary systems, not competing ones. The integration between ERP and WOS is a standard requirement, not a choice.
Hardware compatibility does not require vendor lock-in. Stackbox WOS integrates with AMRs, ASRS, conveyor systems, pick-to-light, and sortation systems from multiple vendors through standard protocols. Existing hardware can often be retained and integrated into the orchestration layer where the interfaces and required performance are confirmed, rather than replaced.
WOS is Stackbox's product framing. The capabilities it describes, such as unified WMS and WES in a single platform, real-time multi-resource orchestration, and continuous SLA prioritisation, represent a direction of evolution for warehouse software. Similar capabilities are sometimes described with terms like "next-generation WMS" or "unified execution." The underlying capabilities are real; the WOS label is Stackbox's own positioning, not a claim to exclusive ownership of the term.
No. ERP manages the financial and commercial record, procurement, supplier management, order management, customer billing. WOS manages physical execution within the warehouse. They are complementary. The WOS receives order data from the ERP and returns fulfilment confirmations, inventory updates, and GRPO data to the ERP. Integration is a standard requirement.
It depends on your current WMS architecture. Some modern WMS platforms can have WES capabilities added through modules or middleware. The question is whether the result can perform real-time task allocation from a unified queue across human and automated resources, or whether the WMS layer and the execution layer remain architecturally separate systems that communicate through batch updates. Integration performance depends on the architecture, event flow and workload rather than on middleware alone; native components also communicate internally. Compare measured response time, recovery behaviour, maintenance ownership and operational behaviour under load. Whether to retain or replace the existing WMS is a separate architecture decision from adding orchestration capability.
Stackbox WOS integrates with AMRs, ASRS, conveyor systems, pick-to-light, and sortation systems from multiple vendors. Integration is through standard protocols. Operations considering WOS should confirm their specific hardware vendors and models with Stackbox during the evaluation to verify integration support.
Existing hardware may be retained where supported interfaces and required performance are confirmed. Validate each model, controller and integration scope. Where interfaces are supported, the transition is primarily a software and integration change; the time and cost depend on the number of automation systems to integrate and the availability of standard APIs on the existing hardware.
To discuss whether Stackbox WOS fits your operation's orchestration requirements, visit stackbox.xyz/product/sbx-wms.
