Back to blog
September 4, 20265 min read

Common mistakes when setting up a per-customer price list for delivery routes

In any delivery route that grows, the first discount shows up sooner or later. A customer who buys a lot of volume, one who always pays in cash, one further out who gets a special rate to avoid losing them. Each exception, on its own, makes sense. The problem shows up once there are twenty or thirty of them and nobody holds all of them in their head at the same time.

The price that only exists in someone's memory

The most common way to handle differential pricing is also the simplest: someone remembers. The owner, whoever answers WhatsApp, the driver who has known certain customers for years. It works as long as that person is always available and their memory never slips, two conditions that rarely hold for long in a growing business.

The day someone else takes the order, or the customer reaches out through a different channel than usual, the price applied is the list price, and that is where the complaints start. Not because the business wants to overcharge, but because the discount was never written down anywhere except in someone's head.

Fixed price vs. percentage discount

There are two ways to store a price exception, and the difference matters more than it looks.

  • Fixed final price: "this customer's 20 litre bottle is $X", regardless of the list price. Simple to understand, but it goes stale on its own. When the base price goes up, that customer is left on an old price until someone notices and corrects it by hand.
  • Percentage discount on the base price: "this customer gets 10% off list". It updates itself whenever the base price changes, because the discount keeps applying to the new number.

Neither one is wrong in every case: a fixed price makes sense for a closed deal that should not move even if the list price goes up. But mixing both without keeping track of which is which, in the same spreadsheet, is where control gets lost.

Updating prices with exceptions on top

This is the moment where the most money slips away unnoticed. The product price goes up, the general list gets updated, and the per-customer exceptions stay exactly as they were.

If those exceptions are fixed prices, the result is a group of customers still paying the old price, sometimes for months, until someone cross-checks the numbers and spots the gap. With enough volume, that accumulated difference is more money than anyone would guess at a glance.

The fix is not to stop making exceptions, it is knowing, at the moment the base price changes, which exceptions are fixed (and need reviewing) and which are percentage based (and already adjusted on their own).

Categories instead of loose exceptions

Once exceptions stop being isolated cases and start repeating in groups (every wholesale customer at the same rate, a whole zone with the same distance surcharge), it makes more sense to think in price categories rather than customer-by-customer exceptions.

The practical difference is this: with loose exceptions, adding a new wholesale customer means copying another wholesale customer's price and hoping nothing gets typed wrong. With a defined "wholesale" category, the new customer gets assigned to that category and inherits all its prices at once, without loading them again.

This also solves the update problem: if the price changes for the wholesale category, it changes for every customer in that category at the same time, without reviewing them one by one.

Zone pricing, another source of mismatch

When price varies by distance or neighbourhood, it is common for the exception to be loaded per customer instead of per zone. A new customer in an already known zone with a surcharge should inherit that surcharge automatically, but if the system does not treat zone as its own concept, every new customer in that zone depends again on someone remembering to set the right price.

Over time, the result is a spreadsheet with the same zone carrying three or four different prices for different customers, with no reason behind it other than when each one happened to get loaded.

What to check before it becomes a problem

Three simple questions help spot whether a price list has already gotten out of hand:

  • Are there customers with the same profile (same zone, same volume) paying different prices for no reason anyone can explain today?
  • Did the last price increase reach every exception, or only the general list?
  • Can someone put together, right now, without digging through several places, the full list of who has a discount and why?

If any of those three is hard to answer, the price list has already stopped being a control tool and turned into a source of silent losses.

Where the order comes from

None of this requires giving up special pricing, which is usually a valid tool for keeping large customers or offsetting a more expensive zone. What it takes is for every exception to be recorded as what it is (fixed or percentage, per customer or per category) in one place, not scattered across a spreadsheet, a notebook and whoever happens to be taking the order. A delivery route software built for water and soda distributors applies the right price to each customer the moment the order is taken, without depending on someone remembering the particular deal for each one.

Without that record, the price list works fine for a while. The cost shows up later, when a price increase does not reach everyone it should, or when two customers with the same profile compare what they pay and nobody has a clear answer.

Frequently asked questions

How do I avoid overcharging or undercharging on an order by mistake?

Each customer's price needs to be set in advance and applied automatically when the order is taken, not decided on the spot based on what someone remembers. If the price depends on whoever is handling the order that day, sooner or later a customer ends up paying the wrong amount.

Is it better to have one price list or several, by zone or volume?

It depends on how many real exceptions you manage. If there are only a few, a base list plus one-off customer prices is enough. If the business already has clear categories (wholesale, zone, volume), it makes more sense to build price categories and assign each customer to one, instead of loading the exception customer by customer.

What happens if I update a product's price and I have per-customer discounts on top of it?

If the discount is stored as a percentage on top of the base price, the update carries through automatically. If it is stored as a fixed final price, every exception needs to be checked by hand each time the base price goes up, and that is where updates most often get missed.

ShareLinkedInWhatsApp

Questions about applying this to your delivery route?

Talk on WhatsApp