Most warehouse operations teams plan labour against a sales forecast they don’t control but that forecast doesn’t translate directly into warehouse labour demand.
The board commits to revenue targets. Finance builds the forecast. And operations are expected to deliver on it.
Fair enough. But there’s a problem.
A sales forecast tells you what the business expects to sell. It doesn’t tell you where the work will actually hit the floor inside the warehouse.
And those two things are very different.
This was one of the first gaps we wanted to solve with our product.
We Don’t Forecast Sales
One of the earliest product decisions we made was actually very simple:
We weren’t going to build a sales forecasting tool.
Most companies already have one. And whether it’s right or wrong, it’s the number the business has committed to.
Operations don’t get to change it. They have to plan against it.
So instead of asking:
“How do we forecast demand?”
We asked a different question:
“What work will that forecast actually create inside the warehouse?”
Because selling 100,000 units doesn’t really mean anything operationally. It sounds impressive. But it doesn’t tell you how busy your pickers are going to be at 11am on a Tuesday.
Orders Create Work… Just Not in the Way You Expect
Every order kicks off a chain of activity inside the warehouse. Nothing surprising there.
But the important bit is this:
The work behind those steps can vary massively.
For example:
- 10,000 single-item orders → lots of picking, fairly simple packing
- 10,000 multi-line orders → more packing, more sorting, more complexity
- A promotion on a fast-moving SKU → suddenly replenishment goes through the roof
Same volume. Completely different workload.
This is where a lot of labour planning starts to break down. Because if you plan using just units or orders, you miss how the work actually behaves.
So We Built Task-Level Demand Prediction
Instead of predicting demand at a high level, we focused on predicting how work spreads across the tasks that actually run the warehouse.
We use historical operational data to learn how demand has behaved in the past.
Things like:
- WMS activity history
- When work actually happens during the day
- How long tasks really take (not how long we wish they took)
- Promotions and seasonal spikes
- Real productivity patterns
Then we use that to predict how future demand will flow through the operation. Not just how much demand there is. But where the work will actually hit the floor.
Turning Work Into Warehouse Labour Demand
Once you understand the work, turning it into labour demand becomes much more straightforward.
For example, if the system predicts:
- 12,000 picks
- 4,000 replenishments
- 8,000 packing tasks
…and we know roughly how long those take, we can estimate:
- how many labour hours are needed
- which departments will need people
- where bottlenecks are likely to appear
This is the point where the forecast finally starts to look like something operational teams can actually use.
It Gets Better Over Time (Because Reality Always Wins)
One thing we learned quite quickly is that no model gets it perfect first time. Operations are messy. Things change. So the system constantly compares what it predicted with what actually happened.
For example:
- Did picking take longer than expected?
- Did replenishment spike earlier than planned?
- Did order profiles shift?
Those signals feed back into the model. So over time, it gets better at understanding how your operation actually behaves. Not how it looks on paper.
Bridging the Gap Between Forecast and Reality
What we’ve really built is a bridge between two things that don’t naturally connect very well:
Business demand forecasts and the operational work required to fulfil them.
Instead of planners staring at a sales number and trying to reverse-engineer what it means, the system helps answer:
- Where will the work show up?
- How will it spread across tasks?
- What does that mean for labour?
The Simple Way We Think About It
We don’t forecast sales.
We take the forecast as a given.
And we answer the question that actually matters to operations:
“What work is this going to create and how many people do we need to handle it?”
Because that’s the bit that turns a plan into something you can actually run.