AI-driven micro-fulfilment in logistics: making a small node pay

Stage 1 is not the absence of local fulfilment — it is local fulfilment without a node. The orders get picked, the customers get served, and the operation works right up to the volume where it doesn't. What is missing is a dedicated place for online stock to live, which means online demand and store demand compete for the same shelf, the same replenishment cycle and the same staff hours, with no way to tell afterwards which of them consumed what.

The tell is what happens to a short line. Because the pick face is the sales floor, availability is whatever the shelf happens to hold at the moment the picker reaches it, and a gap becomes a substitution decided on the spot by whoever is holding the trolley. There is no fill rate to measure because there is no defined assortment to measure it against, and no substitution policy to compare the picker's judgement with. The customer finds out at the door.

This is a cheap stage to occupy at low volume and an expensive one to stay in as volume grows, because the cost curve has the wrong shape. Every additional order adds a full picker walk of roughly the same length as the last one, so unit cost is flat where it should be falling. Operators usually notice at the point where online picking starts colliding with the busiest trading hours, which is exactly when the store can least absorb it.

Stage 2 feels like the decisive step and frequently is not. Separating online picking from the trading floor is a genuine gain: pick times stabilise, shoppers stop being obstructed, and the node acquires a manager. What has not changed is the thing that governs the node's economics, which is the list of SKUs inside it. That list is nearly always inherited — the store's range, minus whatever did not fit — and it was chosen by a process optimised for a completely different question.

The node's job is unlike a store's. A store range is chosen to maximise choice and category margin across a full shopping mission. A node's range must hold the smallest number of lines that completes the largest share of local orders on its own, because anything it cannot complete becomes a split. Those two objectives point at different SKUs: the node wants the high-frequency, high-co-occurrence core of the local basket, and it wants to be ruthless about the long tail that a store carries for range perception.

Time at stage 2 is expensive in a quiet way. The node's cost lands in a store P&L or a central 'online' cost line, the split premium is spread across couriers and second picks nobody attributes, and when the finance review comes the honest answer to 'what does this node cost per order?' is a shrug. Programmes that stall here usually stall for a full budget cycle, because the case for the next investment cannot be built from numbers that do not exist.

Stage 3 is the first stage where the node can be managed rather than merely operated. The change is measurement joined to a decision: order lines from the OMS are matched to pick confirmations in the WMS, so the operation can finally say what share of each order the node completed itself, what the rest cost, and how both move by daypart. Once that number exists it becomes very hard to unsee, because it reorders the priority list — pick-rate projects drop, assortment projects rise.

The model that matters here is unglamorous: a demand forecast at node-SKU-day granularity, feeding two things. First, replenishment suggestions, so the node refills against what its catchment will order rather than against levels set at commissioning. Second, an add/drop list on a fixed cadence, so the assortment is revised deliberately instead of drifting. A category owner still approves every line, which is correct at this stage — the approval log is what later sets the bounds for doing it automatically.

The constraint that emerges at stage 3 is that the node has been optimised alone. Its fill rate is up, its purge is down, and it is still handed whatever orders the routing rules send it, at whatever times a fixed slot grid published. When the catchment has a bad hour, the node absorbs it and the promise does not move. Operators notice this the first peak after the assortment work lands, when a node that is now genuinely good spends a Saturday behind.

At stage 4 the unit of optimisation stops being the node and becomes the catchment. The sourcing engine chooses, per order, which node should fulfil it — weighing what each node holds, how long each will take given its current queue, and what the delivery leg will cost from each. Walmart describes its own 30-minute service in these terms, running on an algorithm that considers basket size, driver availability and distance from the store. That is a fulfilment decision taken at order capture, before a picker has touched anything.

The second half of stage 4 is the promise. A published slot grid is a commitment made in advance of knowing whether it can be kept; a capacity-aware grid closes windows when the node behind them is at its limit and reopens them when it is not. This is the change that stops a good node having a bad Saturday, and it requires an unglamorous feed — pick queue depth and courier availability out of the WMS and the dispatch platform, into the storefront, on a cadence measured in minutes rather than days.

The remaining constraint at stage 4 is human throughput on the decisions around the edges. Assortment changes still wait for a category meeting, sourcing overrides still route to a planner, and capacity thresholds are still set by hand each season. That is often the right place to stop: the returns from removing those approvals are real but modest, while the consequences of removing them badly are not. Moving further should be a deliberate risk decision rather than a technical inevitability.

Stage 5 is narrower than the phrase suggests. It is not an autonomous network; it is an enumerated set of decisions that execute without approval inside written bounds — add or drop a line below a stated volume and margin threshold, re-source an order between two nodes inside a cost band, withdraw a delivery window when queue depth crosses a limit. Anything outside those bounds escalates. Decisions with regulatory, safety or significant commercial exposure are correctly held at stage 4 indefinitely, and saying so out loud is part of the design.

By the time an operator arrives here the engineering is largely a solved problem and the artefact under scrutiny is the policy. It needs the same treatment as code: versioned, reviewed, with a record of who changed which threshold on what date and why. The reason is prosaic — someone will eventually ask why a particular customer's order was re-sourced eight months ago, and the answer has to be reconstructable from logs rather than from memory. The operational patterns for this are borrowed almost wholesale from site reliability engineering.

Stage 5 is also the stage most likely to regress, because the conditions that made the bounds valid keep moving. A catchment gentrifies, a competitor opens two streets away, a courier partner changes its coverage, a new store format changes the substitution set. The escalation rate — the share of decisions falling outside the policy — is the cheapest early warning available, and a rising one should trigger a policy review long before it triggers an incident.