Multi-Depot Dispatch Software: Coordinating Hubs, Cross-Docks, and Micro-Fulfillment Centers

A logistics network that includes a regional hub, two cross-docking facilities, and six micro-fulfillment centers in urban cores is a qualitatively different coordination problem.

Each node type has different inventory characteristics, different timing requirements, different vehicle mixes, and different constraints on what it can fulfill and when.

Single-depot dispatch software applies one set of rules to one type of origin node. Multi-depot dispatch software must apply different logic to different node types simultaneously, coordinate order allocation across them, synchronize timing between them, and present one operational view of the network to the operations team.

This article explains what that coordination requires and where single-depot tools fail when extended to multi-depot networks.

Why Multi-Depot Coordination Is Different From Single-Depot Dispatch

Single-depot dispatch solves for one origin, a known inventory, and a defined vehicle fleet. The optimization problem is contained: which vehicle serves which stop in what sequence, given the constraints that apply at one starting point.

Multi-depot dispatch multiplies the optimization problem in three dimensions: origin choice (which node fulfills which order), intra-node optimization (how each node builds its own routes), and inter-node coordination (how node-level decisions affect the full network).

Each dimension is manageable in isolation; the coordination between them is where multi-depot dispatch software earns its value.

The three node types and what makes each operationally distinct

Node type	Inventory profile	Typical dwell time	Route type	Primary dispatch constraint
Hub / DC	Full SKU range, deep buffer stock	Days to weeks	Long-haul + last-mile mixed	SLA diversity: multiple delivery windows and carrier types in one plan
Cross-dock	No stock; transit freight only	Hours (inbound-to-outbound)	Outbound last-mile only	Inbound timing: outbound cannot depart until inbound is sorted and loaded
Micro-fulfillment center	High-velocity SKUs, shallow stock	Hours to 1-2 days	Last-mile only, short radius	SKU depth: out-of-stock on a single popular item creates a node-level bottleneck

The Dispatch Challenges Each Node Type Creates

Hub and DC dispatch: Scale and SLA diversity

A regional hub or distribution center typically runs the highest volume and the most diverse SLA commitments of any node in the network. A single day’s dispatch may include same-day last-mile deliveries, next-day B2B deliveries, and 2-day residential shipments, all from the same facility, using a mix of owned fleet, contracted carriers, and on-demand capacity.

The hub’s dispatch challenge is SLA diversity management.

Each order type has a different departure deadline, a different carrier eligibility set, and a different route geometry. A dispatch system that builds routes in a single pass without SLA-segmented planning either over-optimizes for one delivery type at the expense of others or builds routes that are acceptable across all types but optimal for none.

Hub dispatch also generates the highest exception volume in the network. At high order volumes, a 3% exception rate is a large absolute number.

Exception management for the hub must integrate with the rest of the network: an exception at the hub that requires re-routing an order to an MFC needs the MFC’s current capacity to be visible before the re-routing decision is made.

Cross-dock dispatch: Timing is the product

A cross-dock is a pass-through node. It stores nothing. Its entire value is the speed at which it receives, sorts, and re-dispatches freight from multiple inbound sources to multiple outbound destinations. The dispatch problem at a cross-dock is a timing alignment problem, which has two sides:

• Inbound timing: Freight arriving at the cross-dock from hub or supplier shipments must arrive within a defined receiving window. Late inbound arrival compresses the sorting time available before the outbound vehicles must depart
• Outbound timing: Outbound vehicles must depart at a defined time to meet last-mile delivery commitments. If the outbound departs before a late-arriving inbound has been sorted, some orders miss the outbound and must wait for the next cycle

The dispatch management software for a cross-dock must treat inbound arrival times and outbound departure times as linked constraints in the same planning model. Managing them in separate systems, or treating inbound tracking and outbound dispatch as independent functions, produces the gap that causes cross-dock timing failures.

When inbound freight is late, the cross-dock has two options: hold the outbound vehicle and compress the downstream delivery windows, or dispatch the outbound on time and delay the missing freight to the next cycle.

Both options have SLA consequences. The dispatch system must surface the trade-off in time for the operations team to make the decision.

Micro-fulfillment center dispatch: Speed and SKU depth

A micro-fulfillment center is designed for speed. It serves a small geographic radius, carries a curated set of high-velocity SKUs, and enables same-day or sub-2-hour delivery for the items it stocks.

Its dispatch cycles are short, its routes are dense, and its vehicle mix typically skews toward small vehicles or delivery bikes for urban environments.

The MFC’s dispatch vulnerability is SKU depth. A shallow stock on any single high-demand item creates a node-level stockout that the MFC cannot resolve without inbound replenishment from the hub. An order placed by a customer in the MFC’s service zone for an out-of-stock item has three possible outcomes:

• The order is re-routed to the hub with a longer fulfillment window, which may breach the customer’s speed expectation
• The order is split: items in stock at the MFC ship today; the out-of-stock item ships from the hub tomorrow
• The order is held until the MFC receives replenishment, which requires the dispatch system to know when the replenishment is scheduled and whether it arrives within the customer’s promised window

None of these options can be executed without the dispatch system having live visibility into both the MFC’s current stock and the hub’s replenishment schedule. An MFC dispatch tool with no hub integration sees only its own stock and cannot evaluate which of the three options is available.

Where the Coordination Failures Occur

Multi-depot coordination failures are predictable. They follow the same patterns across different network configurations and node combinations. The three most common, and most costly:

1. Order allocation without live node capacity

Order allocation in a multi-depot network is the decision that determines which node fulfills which order. In networks where allocation is handled by the OMS from a static availability feed, the decision is made against inventory data that may be hours behind the actual node state.

The failure mode: an order is allocated to an MFC that shows 12 units in stock at the last inventory sync, but the actual stock is 3 after a busy morning’s dispatch. The MFC cannot fulfill the order. The dispatch system at the MFC discovers the problem when the picker tries to locate the item.

By then, the customer’s delivery window may already be compromised, and the fallback to the hub requires a fresh route planning cycle that was not anticipated in the day’s vehicle capacity.

Live node capacity allocation requires a direct connection between the order allocation system and the current operational state of each node, not a batch inventory feed that represents the state as it was at last sync.

2. Cross-dock timing failures

Cross-dock timing failures are among the most expensive coordination failures in multi-depot networks because they cascade. A late inbound arrival at the cross-dock affects every outbound route that was waiting for freight from that inbound vehicle.

The typical failure chain: an inbound truck arrives 90 minutes late. The cross-dock team rushes the sort but the outbound vehicle departs 45 minutes late to minimize the delay. The late departure means the outbound driver runs behind the planned route all day.

By stop 12, the driver is 90 minutes off the planned window. Three B2B deliveries with fixed receiving windows are breached, and each generates a chargeback or SLA penalty.

The cascade was triggered by 90 minutes of delay at the cross-dock, but the financial consequence was incurred at the last-mile level, hours later and miles away. Dispatch software that does not connect cross-dock inbound timing to last-mile SLA risk cannot identify this cascade risk before it materializes.

3. MFC-to-hub fallback without dispatch integration

When an MFC cannot fulfill an order, the fallback to the hub is theoretically simple: re-route the order to the hub, find a vehicle with capacity and the right departure time, and deliver. In practice, this requires the hub’s dispatch system to absorb a new order that was not in the original plan, which requires either spare vehicle capacity or route modification.

When the MFC dispatch system and the hub dispatch system are separate tools, the fallback is a manual coordination event: the MFC dispatcher contacts the hub, the hub dispatcher checks capacity, and if space is available, the order is manually added to a route. This process takes time, requires human availability at both nodes simultaneously, and produces inconsistent outcomes depending on how busy each dispatcher is when the fallback is triggered.

A multi-depot dispatch platform where both the MFC and the hub are visible and manageable from the same system converts the fallback from a manual coordination event to a software-triggered re-allocation.

The platform evaluates whether the hub has capacity, identifies the optimal route for the order, updates the route plan, and notifies the customer of the adjusted delivery window automatically.

What Multi-Depot Dispatch Software Does Differently

Multi-depot dispatch software addresses coordination failures by treating the full network as a single optimization problem, not as a collection of independent node-level dispatch systems.

Network-level order allocation

Network-level order allocation evaluates every incoming order against the full set of eligible fulfillment nodes, simultaneously, using live capacity data from each node.

The allocation decision accounts for:

• SKU availability: Which nodes actually have the required items in stock at the moment of allocation?
• Fulfillment speed: Which node can fulfill within the customer’s committed delivery window, given that node’s current vehicle capacity and departure schedule?
• Cost to serve: What is the total cost of fulfilling from each eligible node, accounting for carrier type, route distance, and any premium carrier required to meet a tight window?
• Network load balance: Does the allocation distribute order volume across nodes in a way that prevents one node from being overloaded while another has capacity?

The allocation outputs a node assignment and a departure window for each order. That window then becomes a constraint in the node’s route planning cycle, ensuring the route plan is built to honor the committed time.

Cross-dock timing coordination

Multi-depot dispatch software connects inbound freight tracking to outbound dispatch planning at the cross-dock. The connection works in both directions:

• Inbound delay detection: When an inbound carrier’s ETA at the cross-dock is later than the planned arrival, the system calculates the impact on outbound departure times and surfaces the trade-off to the operations team before the outbound was scheduled to depart
• Outbound departure adjustment: If the inbound delay is small enough that a brief outbound hold can recover without breaching downstream delivery windows, the system evaluates whether holding the outbound is preferable to cycling the delayed freight to the next departure
• Downstream SLA alert: When the cross-dock delay is significant enough to affect last-mile delivery commitments, the system identifies which specific deliveries are at risk and surfaces proactive customer notification options before the SLA breach occurs

Unified visibility across node types

A track and trace layer that aggregates status from all nodes, hub dispatch activity, cross-dock inbound and outbound events, MFC pick and dispatch events, and in-transit carrier status into one operational view eliminates the manual aggregation that multi-node networks typically require.

An operations manager can see whether a specific order has been picked at the MFC, whether the outbound vehicle has departed the cross-dock, and whether the last-mile carrier is on schedule for delivery, from the same interface.

The operational value of unified visibility is exception detection across node boundaries. A delay that starts at the cross-dock inbound, affects the outbound departure, and ultimately risks a last-mile delivery SLA can be detected and surfaced as a single, connected risk signal, not as three separate events in three separate systems.

The operations team sees the full impact before it is distributed across the network.

How Locus Coordinates Multi-Depot Operations

Locus is the world’s first Decision-Intelligent, Agentic TMS. Its multi-agent architecture is specifically designed for the type of coordinated decision-making that multi-depot networks require, where a decision at one node immediately affects the constraints and options available at others.

Three of Locus’s eight specialized AI agents are most relevant to multi-depot coordination:

Hub agent

It manages hub-level operations including consolidation processing times, departure window scheduling, and the timing coordination between inbound freight arrival and outbound dispatch.

When cross-dock inbound timing changes, the Hub Agent evaluates the impact on connected outbound routes and surfaces the adjustment options before the departure window closes.

Dispatch agent

It coordinates network-level order allocation across all active node types, using live capacity and SKU availability data from each node.

When an MFC cannot fulfill an order, the Dispatch Agent evaluates hub fallback options and initiates the re-allocation without requiring manual dispatcher intervention at either node.

Orchestrator agent

It maintains coherence across all agent decisions in the multi-depot network.

When the Hub Agent adjusts a departure window and the Dispatch Agent re-allocates three orders, the Orchestrator Agent ensures these decisions are consistent and that the affected routes and customer notifications reflect the combined update.

One orchestration layer, multiple node types

DispatchIQ provides the dispatch intelligence layer that connects order allocation, route planning, and carrier management across all node types from one platform.

When an order is allocated to the hub, DispatchIQ builds the route around that order’s departure window. When the same order needs to be re-allocated to an MFC because of a hub capacity event, DispatchIQ rebuilds the affected route at the MFC without requiring the dispatcher to initiate the change at both nodes separately.

The Fireworks Routing Engine builds route plans that can span multiple node origins in the same optimization cycle. A mixed-origin day, where some deliveries originate from the hub and others from two MFCs in the same metropolitan area, is planned against the same constraint set simultaneously.

Routes are sequenced to minimize overlap between node-origin zones and to maximize coverage efficiency across the full delivery area.

ShipFlex coordinates carrier selection across node types, applying the same carrier performance data and capacity visibility to hub dispatch, cross-dock outbound, and MFC last-mile deliveries.

Carrier allocation rules can be configured per node type: the hub may use long-haul contracted carriers for inter-city freight and local couriers for last-mile; the MFC may use only local couriers and captive fleet within its service radius. ShipFlex applies the correct carrier selection logic per node without requiring separate carrier management configurations in separate dispatch systems.

Locus has been recognized in Gartner research on last-mile delivery and supply chain execution technologies for seven consecutive years, including in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies and the 2025 Market Guide for Last-Mile Delivery Technology Solutions.

It serves 360+ enterprise customers across retail and e-commerce and FMCG and CPG verticals in 30+ countries, with $320M+ in collective logistics cost savings and 99.5% on-time SLA adherence.

In October 2025, Ingka Investments, the investment arm of Ingka Group, acquired Locus, providing long-term institutional backing to a platform that continues to operate independently.

Building a Multi-Depot Network: Practical Considerations

Organizations adding node types to an existing single-depot network benefit from addressing the dispatch coordination layer before the physical network is fully operational.

The software integration work between node types is the longest lead-time item in a multi-depot rollout, and running cross-dock or MFC operations on separate, unconnected dispatch tools creates coordination problems that become harder to resolve as each node scales.

Four practical considerations:

• Phased integration: Connect the highest-volume or highest-risk node type to the dispatch coordination platform first. A cross-dock integration that goes live with the cross-dock facility eliminates timing coordination failures from day one and avoids discovering them after the outbound operation is running at full volume
• Allocation rules before launch: Define the order allocation logic, including the fallback sequence from MFC to hub and the conditions that trigger cross-dock cycling, before the first order is processed through the multi-depot network. Allocation rules established in software are executed consistently; allocation rules documented in a process manual are applied inconsistently
• Cross-dock timing buffers: Build the inbound-to-outbound processing time into the dispatch planning model explicitly. A cross-dock that needs 60 minutes of sorting time should have a hard 60-minute constraint between the last inbound cutoff and the first outbound departure, not a soft guideline that gets compressed under volume pressure
• MFC replenishment as a dispatch event: Replenishment shipments from the hub to the MFC should be treated as dispatch events in the same platform as outbound customer deliveries. When replenishment is planned through a separate inventory system and executed by a separate logistics team, the MFC dispatch system has no visibility into when stockouts will be resolved and cannot make accurate order allocation decisions during the replenishment window

Effectively Coordinate Across Delivery Nodes

A multi-depot network that includes hubs, cross-docks, and micro-fulfillment centers is more than the sum of its individual node operations.

The coordination between nodes, specifically the order allocation decisions, the cross-dock timing constraints, and the fallback logic when a node cannot fulfill, is where the network creates or destroys operational efficiency.

Dispatch software built for single-depot operations extends poorly to multi-depot networks because it lacks the inter-node coordination logic that the network’s most common failure modes require.

The investment in multi-depot dispatch software is justified by the reduction in manual coordination events, the elimination of cross-dock cascade failures, and the consistent execution of node fallback logic that otherwise depends on individual dispatcher judgment.

Schedule a demo with Locus today to see how the Hub Agent, Dispatch Agent, and Orchestrator Agent coordinate multi-depot dispatch from a shared operational layer.

---