> For the complete documentation index, see [llms.txt](https://help.modelreef.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://help.modelreef.io/use-cases/wholesale-distribution-and-b2b-trade/warehouse-capacity-and-logistics-model.md).

# Warehouse Capacity & Logistics Model

This use case explains how to model warehouse capacity, throughput and logistics costs for wholesale, distribution and B2B trade businesses in Model Reef.

You will:

* Represent warehouses, regions and logistics networks in the branch structure.
* Link SKU volumes to inbound, storage and outbound handling loads.
* Model capacity constraints, utilisation and cost structures.
* Connect warehouse and logistics assumptions to P\&L and Cashflow.

Model Reef is not a warehouse management or routing system. It uses operational assumptions to shape financial forecasts and scenarios.

## When to use this pattern

Use this pattern when:

* Warehousing and logistics are material cost or constraint drivers.
* You operate multiple warehouses or fulfilment centres.
* You need to understand capacity, utilisation and cost impacts of growth.
* You want to compare centralised vs regional or third party logistics strategies.

It complements:

* SKU and Margin Forecasting
* Inventory Replenishment Cycles
* Customer Level Revenue Modelling

## Architecture overview

{% stepper %}
{% step %}

### Structure

* Branches per warehouse, region or fulfilment node.
* Optional branches for third party logistics or cross dock facilities.
  {% endstep %}

{% step %}

### Volume and load drivers

* Inbound units or pallets.
* Storage units or pallet positions.
* Outbound orders, lines, units or weight.
  {% endstep %}

{% step %}

### Capacity and utilisation

* Storage capacity per warehouse.
* Throughput capacity per period.
* Utilisation metrics and thresholds.
  {% endstep %}

{% step %}

### Cost drivers

* Fixed warehouse costs.
* Variable handling, storage and transport costs.
* Third party logistics fees.
  {% endstep %}

{% step %}

### Set up warehouse and logistics branches

In the branch tree, create branches that reflect your logistics footprint, for example:

* Region - UK
  * Warehouse - UK North
  * Warehouse - UK South
* Region - EU
  * Warehouse - EU Central
* Third Party Logistics

Each warehouse branch will hold capacity, volume, cost and staff variables. Transport costs can either live in the warehouse branches or in separate logistics branches if you want to analyse them separately.
{% endstep %}

{% step %}

### Link SKU volumes to warehouse loads

From SKU and margin models, obtain:

* Units sold per SKU per region or channel.
* Where possible, allocation of units to warehouses based on service territories or routing logic.

Create drivers such as:

* Units Inbound - Warehouse A.
* Units Outbound - Warehouse A.
* Orders or Order Lines - Warehouse A.
* Pallet Equivalents per Unit or per SKU Family.

Derive load metrics, for example:

* Pallets Inbound = Units Inbound × Pallet Factor.
* Pallets Stored = Average Inventory × Pallet Factor.
* Picks or Lines Per Period = Orders or Lines data.

These metrics will drive capacity utilisation and variable costs.
{% endstep %}

{% step %}

### Define capacity and utilisation

For each warehouse, create drivers for:

* Storage Capacity (for example pallet positions).
* Throughput Capacity (for example pallets or picks per period).
* Labour Capacity (for example shifts, FTEs or hours per period).

Calculate utilisation metrics such as:

* Storage Utilisation = Pallets Stored divided by Storage Capacity.
* Throughput Utilisation = Pallets Inbound plus Pallets Outbound divided by Throughput Capacity.
* Labour Utilisation = Required Hours divided by Available Hours.

You can highlight when utilisation exceeds threshold levels (for example above 85 percent) to indicate congestion or the need for additional capacity or process changes.
{% endstep %}

{% step %}

### Model warehouse and logistics costs

Create cost variables in each warehouse branch, for example:

* Staff - Warehouse Operations - Warehouse A.
* Opex - Rent and Rates - Warehouse A.
* Opex - Utilities, Maintenance and MHE.
* Opex - Inbound Freight.
* Opex - Outbound Freight.
* Opex - Third Party Logistics Fees.

Link these to drivers such as:

* Fixed monthly or annual rent and overhead allocations.
* Cost per pallet handled.
* Cost per order, per line or per kilogram.
* Contracted third party logistics rates per unit or per activity.

This allows you to see total logistics cost per unit, per order or per revenue pound in P\&L and cash.
{% endstep %}

{% step %}

### Use scenarios for footprint and strategy

Clone the model into scenario models to explore:

* Opening, closing or relocating warehouses.
* Moving from own operated to third party logistics, or vice versa.
* Changing service levels or delivery promises.
* Growth that saturates existing capacity.

In each scenario, adjust:

* Warehouse capacity and cost structures.
* Allocation of demand between warehouses.
* Transport and third party logistics rates.
* Staffing levels and productivity assumptions.

Compare scenarios using:

* Total logistics cost and cost per unit.
* Capacity and utilisation across the network.
* Service trade offs and working capital implications when combined with inventory models.
  {% endstep %}

{% step %}

### Connect to inventory and customer models

When combined with Inventory Replenishment Cycles and Customer Level Revenue Modelling:

* Warehouse branches hold the physical and cost picture.
* Inventory models determine stock levels and movements.
* Customer models determine demand patterns and service levels.

Dashboards can show:

* Logistics cost per customer, product or region.
* Capacity bottlenecks under different demand scenarios.
* Effect of SKU rationalisation, pricing or service changes on logistics needs.
  {% endstep %}
  {% endstepper %}

## Check your work

* Warehouse capacity and cost assumptions match actual contracts and operating data.
* Load and utilisation metrics reconcile with historical operational reports.
* Scenario outputs are interpretable for operations, finance and commercial teams.
* Model granularity is appropriate to the decisions being made.

## Troubleshooting

<details>

<summary>Utilisation seems unrealistic</summary>

Check pallet and storage factors, and ensure you are not double counting inbound and outbound volumes when comparing to throughput capacity.

</details>

<details>

<summary>Logistics costs do not reconcile to historical accounts</summary>

Revisit mapping of costs into branches and ensure rate and volume assumptions match recent periods.

</details>

<details>

<summary>Model is too granular for quick decision making</summary>

Aggregate similar warehouses or logistics activities into representative nodes and keep detail only where it significantly changes decisions.

</details>

## Related guides

* [Build a Consolidated Forecast Model](/how-tos/core-modelling/build-a-consolidated-forecast-model.md)
* [Build a Cost of Goods Model](/how-tos/operations-and-unit-economics/build-a-cost-of-goods-model.md)
* [Investing Cashflow](/help/financial-outputs-and-valuation/investing-cashflow.md)
* [Timing Preview](/syntax/timing-syntax/timing-preview.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://help.modelreef.io/use-cases/wholesale-distribution-and-b2b-trade/warehouse-capacity-and-logistics-model.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.