What it actually costs to serve this customer — not the site average.
A warehouse P&L tells you whether the site made money. It cannot tell you which customer made it, or which one quietly lost it. This is the calculation that separates them.
Cost to serve is the total cost of delivering the service a specific customer actually consumes: the labour their work requires, the space their stock occupies, the equipment and systems their operation uses, and the share of site overhead their presence absorbs.
The word doing the work in that sentence is consumes. Two customers in the same warehouse, paying the same total each year, can consume completely different amounts of the operation. One sends full pallets in and full pallets out. The other sends pallets in and ships thousands of small orders, each one picked carton by carton, packed individually and despatched separately.
They look similar on an invoice. They are not remotely similar to run.
Here is a real demonstration, using the same outer-suburban Sydney warehouse modelled across the rest of this site — roughly 12,700 SQM, a total operating cost of $1,464,210 a year, handling 15,600 pallets in, 245,000 cartons picked, 61,000 orders and 7,800 containers despatched.
Two customers share it:
Between them they are the whole site. Now price them two ways.
| Per year | Customer A | Customer B | Site total |
|---|---|---|---|
| Cost to serve | $612,236 | $852,302 | $1,464,538 |
| Revenue | $703,752 | $979,524 | $1,683,276 |
| Margin | $91,516 | $127,222 | $218,738 |
| Margin % | 13.0% | 13.0% | 13.0% |
Rates are the per-unit costs and charges published in Rate Card Pricing: From Cost Pools to Per-Unit Rates. The $328 difference between the cost total here and the site figure is rounding on the unit rates. The finished card itself — rate types, a sample Australian card and the mistakes that cost margin — is covered on Warehouse Rate Card.
Both customers land at the same margin, because each is charged for the work it actually causes. That is what a properly built rate card does.
Now charge exactly the same total revenue, but through one simple, easy-to-negotiate number: $6.87 per carton. Same warehouse, same customers, same $1,683,276 of revenue, same 13.0% site margin.
| Per year | Customer A | Customer B | Site total |
|---|---|---|---|
| Revenue | $480,936 | $1,202,340 | $1,683,276 |
| Cost to serve | $612,236 | $852,302 | $1,464,538 |
| Margin | −$131,300 | $350,038 | $218,738 |
| Margin % | −27.3% | 29.1% | 13.0% |
The site P&L is identical in both tables. Same revenue, same total cost, same 13.0% margin. But in the second, Customer A is losing $131,300 a year and Customer B is subsidising them. Nothing in the monthly report would tell you. You would renew Customer A happily, and you would probably fight hard to keep them.
That is the entire argument for cost to serve. Not that the average is wrong — the average is perfectly accurate. It is that the average is the one number that cannot inform a commercial decision, because every decision you make is about a specific customer.
The calculation is a chain. Every step is arithmetic; the discipline is in never skipping one and never averaging across a step.
Two steps are where most models quietly fail. Step 3, because a wage is not the cost of an employee — superannuation, payroll tax, workers' compensation, leave loading and long service all sit on top, and the rates differ by state. Step 5, because a cost put in the wrong pool gets recovered on the wrong basis and never reconciles back.
Above them sits the commercial layer — corporate overhead and profit, applied as a mark-up or a margin. Keeping that separate is what lets you show a customer an all-inclusive price without ever exposing where your margin sits.
The most common failure is not getting the number wrong. It is getting it right once.
A cost-to-serve model built during a tender is accurate on the day it is signed and decaying from the next. Volumes land differently from forecast. Order profiles shift as a customer's own business changes. Wage rates move. The productivity you assumed turns out not to be the productivity the site achieves. None of that shows up as a single dramatic event — it shows up as a margin that is two points lower than last year and nobody can say exactly why.
Which means the useful question is not “what is our cost to serve?” but “what is it this month, per customer, measured against what we assumed when we priced it?” That is a systems problem rather than a spreadsheet problem, and it is the problem CostAware was built to solve.
Further reading: ABC Cost Allocation for 3PL Explained covers the allocation method in detail; How to Calculate Warehouse FTE from Volume covers step 3; Catching Margin Drift on a Live Contract covers what happens after signature.
Cost to serve is arithmetic, but the inputs are local. In Australia the on-cost stack includes the superannuation guarantee, state payroll tax, workers' compensation and leave loading, with rates that vary by state — the same headcount costs a different amount in New South Wales than in Queensland. In New Zealand the stack is structurally different again: KiwiSaver rather than superannuation, ACC levies rather than workers' compensation, no state payroll tax, and no modern award system setting the classification floor.
A model that grosses wages up with a single flat percentage will be wrong in both countries, and wrong by different amounts at every site.
The total cost of delivering the service a specific customer actually consumes — labour, space, equipment, systems and their share of overhead. Measured per customer, product or contract rather than averaged across a site.
Start from the customer's real volumes, convert those into activity time using measured productivity, convert activity time into labour, add space, equipment, systems and overhead into pools, then divide each pool by the volume that drives it.
Because a P&L reports the total. As the worked example above shows, a healthy site margin can contain one customer losing money on every order and another subsidising them.
Continuously. A figure calculated once at tender is out of date within months, because volumes, order profiles and wage rates all move.
CostAware builds this calculation from your volumes, your labour agreement and your sites — and keeps it current as the contract runs.