A busy route and a thin month
One multi-drop route runs every day and keeps a van full. Everyone assumes it is the backbone of the business. The accounts say the month was busy but thin. Nobody can say which runs carried the business and which dragged it down, because revenue is recorded per job and costs are recorded per week, per van or per driver.
When the route's biggest customer asks for a rate cut, the answer is a guess.
Why cost per run is invisible
Revenue is attached to jobs. Costs are attached to other things: owner driver pay per week, fuel cards per vehicle, tolls and charges per registration, mileage in the telematics system. Joining them up per run needs a common key, usually the vehicle and date, and nobody has time to do it by hand.
| Cost | Where it is recorded | How it links to a run |
|---|---|---|
| Driver pay | Pay statements | Driver, date, jobs |
| Fuel | Fuel card transactions | Vehicle, date |
| Mileage and time | Telematics or driver app | Vehicle, date, route |
| Waiting time | Job records, if captured | Job |
| Tolls, congestion and zone charges | Charge notices and accounts | Vehicle, date, location |
What not knowing costs
Unprofitable runs renewed on the same terms. Rate cuts accepted because there was no evidence to push back. Good runs underpriced because nobody could see their value. And no basis for decisions about vehicles, drivers or which customers to chase.
Empty miles are the hidden cost. A run that ends a long way from the depot, with no return load, is costing far more than its invoices suggest.
The multi-drop work that fills vans every day is especially prone to this. Drop rates set years ago may not reflect how much longer each stop now takes, with more flats, more access problems and more customers wanting a signature. The van is full and the driver is busy, which looks like success, and the margin quietly goes.
Owner driver pay adds another layer. If a driver is paid per drop and the customer pays per drop at a similar rate, the run can look balanced while fuel, van hire and the office time behind it are not being covered at all.
The run view we build
- Revenue per job from your courier software or invoicing, grouped into runs by vehicle, driver and date.
- Driver pay per run from your pay records, with pay for multi-run days split by time or jobs.
- Fuel from fuel card data matched by vehicle and date, and mileage and time from telematics or the driver app.
- Waiting, tolls and charges from job records and your charge log.
- A margin per run, per regular contract and per customer, with the method visible.
- Trends over time, and a comparison tool for pricing reviews: what a rate change or an extra drop would do to a run's margin.
All allocations are estimates using rules you agree. What matters is using the same method every week, so changes are real.
What you get
A weekly view of which runs and customers pay. Pricing conversations backed by numbers. Early warning when a regular run's margin slips because of longer waits or extra drops. And a basis for deciding where to grow.
Signs you need this
- You know revenue per job but not cost per run.
- Busy months are sometimes thin months.
- Rate cuts are accepted without knowing the margin.
- Fuel, pay and mileage are in separate systems.
- Empty return legs are not measured.