Returnable containers on a delivery route: how to track them without losing any

On a soda, water or any delivery route built around returnable containers, the order and the drop are almost always tracked. The container that comes back is not. It goes out with every delivery and is supposed to return on the next visit, but weeks can pass between one visit and the next, and nobody writes anything down in between.

The problem does not show up all at once. It builds up slowly, in the gap between the containers actually out on the street and whatever is written down somewhere as belonging to the business.

Why the container goes missing without anyone noticing

Every delivery moves two things: the product being sold and the container left pending return. The product has a natural record, because it is tied to the order and the payment. The container does not, because it generates no income at the time and is easy to treat as a minor detail of the drop.

With a handful of customers, the driver remembers who owes what. With a larger route, that memory fails, and it always fails in the same direction, in the customer's favour. Nobody forgets to chase a container owed to them, but they do forget to chase one owed to the business.

What to log at every drop

The minimum needed is simple: how many containers go out, how many come back, and the resulting balance per customer. Not as a generic daily total, but drop by drop.

• Containers delivered on the visit, added to the customer's balance.
• Containers collected on the visit, subtracted from it.
• Running balance, visible before the next round, to decide whether it is worth chasing or simply not leaving another one without a return.

With that record, "how many siphons are currently out" stops requiring a manual pass through every customer and becomes a sum.

The deposit as an incentive, not a charge

Charging a deposit on the container changes the return dynamic. It is not an extra fee, it is a way to give the customer their own reason to hand it back, instead of relying on goodwill or memory.

The deposit works best when it is clear from the first order, shown alongside the product price the customer already sees, and refunded without friction once the container comes back. A deposit that is easy to charge but hard to get back generates more complaints than it prevents.

Different container types, separate balances

A single customer might be holding a siphon, a 20 litre bottle and some other returnable container at once, and lumping them into one number does not help. A missing siphon and a missing bottle are different problems, with different replacement costs, and it helps to see them separately.

This matters especially when a route sells more than one product with its own container. Knowing a customer owes "three containers" does not say whether that is three siphons or one bottle and two siphons, and the decision on whether to keep delivering without chasing it is not the same in either case.

Customers who keep piling up containers

There is a point where a customer moves from owing one or two containers, which is normal on any active route, to holding a number that already represents a real loss. That point is worth defining in advance, as a limit on outstanding containers per customer.

When the balance gets close to that limit, the useful thing is for it to surface while the next order is being put together, not to depend on someone manually reviewing the whole customer list every so often. The driver goes out already knowing that stop needs a container chased before leaving a new one, and that conversation is far easier to have on time than after months have gone by.

What to check every month

With container control in place, two figures are worth reviewing regularly.

Total containers pending return, tracked month over month. If it keeps growing while the customer base stays stable, there is a leak worth investigating before it becomes expensive.

Customers above the container limit, as a concrete list rather than an abstract figure. That is the difference between knowing there is a problem and knowing exactly where it is.

Where the control comes from

None of this requires complex software, but it does require the container to be logged in the same place as the order, not in a separate notebook nobody updates with the same care. A delivery route software built for water and soda distributors adds and subtracts containers with every delivery the same way it does products, and the balance per customer is available without manual reconstruction.

Without that record, container control runs on memory for a while. The cost shows up later, when someone counts the siphons left in the depot and they do not match what should be there.