Cost per trip needs to know the trips. Carbon per trip needs to know the trips. Whether your fleet is big enough needs to know the trips. It is the most referenced number in reusable packaging and the least often measured.
Why it is hard
A trip is not an event you naturally record. Nothing in the process counts it: the spool gets filled, shipped, emptied, returned, and none of those steps necessarily touches a system that logs anything per-spool.
Add that most fleets have no per-spool identification at all, and the honest position in most operations is that trip counts are estimates dressed as facts.
Three levels of rigour
Estimated. Derive from throughput: total product shipped divided by spool capacity, divided by fleet size. Crude, ignores dwell time entirely, and gets the wrong answer systematically if anything about the loop is uneven. Still better than nothing, and adequate for rough modelling.
Modelled. Estimate from the flow described in our fleet sizing article — working through where spools sit at each stage. Meaningfully better, particularly if you have real transit and dwell figures rather than assumptions.
Counted. Per-spool identification scanned at defined points. The only version that produces actual data, and the only version that tells you about the distribution rather than the average.
Why distribution matters more than average
This is the argument for counting. Average trips per year tells you the fleet turns over at some rate. The distribution tells you something more useful — typically that a minority of spools are doing far fewer trips than average, and that they cluster.
The cluster is the actionable finding. It is usually a specific customer, a specific route, or a specific handling point where spools disappear or get damaged. Knowing that changes what you do. Knowing the average changes nothing.
What you need for counting
- Per-spool identification. RFID where volumes justify it, durable markings or barcode otherwise. Discussed in general terms in our markings article.
- Scan points. Realistically two: despatch and return receipt. Adding more increases data quality and operating cost, roughly in step.
- Somebody doing it. The single point of failure. If scanning depends on someone who is busy, it stops.
Minimum viable version
If real counting is out of reach, do this:
- Batch-identify rather than per-spool — a batch reference marked on the spool when introduced
- Log introduction date, which lets you derive age-based estimates later
- Count at return even if you do not count at despatch — one-sided data still reveals which routes return poorly
- Tally retirement reasons, per the argument in our records article
Two years of that produces better numbers than most of the modelling done from first principles.
What the data typically reveals
Three findings recur:
- The realised trip count is lower than planned. Almost always.
- Losses concentrate at specific handover points rather than distributing evenly.
- A substantial tail of spools do very few trips and are effectively single-use despite being reusable.
The third one is usually the biggest lever available, and you cannot see it without counting.
How this connects to everything else
Trip count is the denominator in our cost per trip analysis, and it determines whether the recycled content trade-off is worth making. Both articles are honest that the conclusions depend on it.
Our suggestion
Do not attempt full tracking on day one. Batch-mark the next order, log introduction dates, and start counting returns. That is a very small amount of work and after a year you will have real numbers for our spools in your actual loop — which is worth considerably more than any figure a supplier gives you.