Three versions of the rate card
Sales has a rate card spreadsheet they send to prospects. The courier software has zone rates that were set up years ago. Finance invoices some customers from a different spreadsheet because their deal was negotiated separately. Somewhere in each is a list of postcode areas that attract a surcharge, and they do not quite agree.
A customer questions why a delivery to a Scottish island was charged a surcharge that their contract says is included. Nobody is sure which rate card is right.
Why rate cards drift
Zone pricing is detailed. Postcode areas, districts and sometimes sectors are grouped into zones; weight breaks and pallet sizes add dimensions; remote and offshore areas have surcharges; customers negotiate exceptions. Each change is made in whichever place the person making it has access to.
| Pricing element | Where it goes wrong |
|---|---|
| Postcode to zone mapping | Different lists in different places |
| Weight breaks and size bands | Changed in one system, not others |
| Remote and offshore surcharges | Applied inconsistently |
| Customer-specific deals | Held in a separate spreadsheet |
| Annual rate increases | Applied to some customers and not others |
What drift costs
Undercharging when an old rate stays in the invoicing system. Disputes when quotes and invoices disagree. Surcharges missed on remote deliveries that genuinely cost more to make. And slow quoting, because sales cannot trust the card they are sending.
It also makes rate reviews painful. Increasing prices is harder when you do not know exactly what each customer is paying now.
Postcode changes add slow drift of their own. New postcodes are created as housing estates are built, and a new postcode that is not in any zone list falls back to a default, which may be the cheapest zone. Nobody notices until someone asks why deliveries to a new development far from the depot are priced as if they were next door.
Pallet work multiplies the problem. Pallet networks price by size, weight and zone, and if you pass network rates on to customers with a margin, every network rate change has to flow through to your own card. Done by hand, it rarely happens on the day it should.
The rate engine we build
- One set of zones: postcode areas, districts or sectors mapped to zones, maintained on a single screen.
- Weight breaks, size bands, service levels and surcharges defined once.
- Customer deals as exceptions on top of the standard card, with start and end dates.
- A pricing API used by your quoting tool, website, booking system and invoicing, so every price comes from the same place.
- A history of every change: who changed what, when, and which quotes and invoices used which version.
- Rate review tools: preview what a proposed increase does to each customer's typical monthly bill before you send it.
If your courier software can accept rates by import, the engine can keep it updated rather than replace it.
What changes
One rate card, used everywhere. Quotes and invoices agree. Remote surcharges apply where they should and not where a deal excludes them. Rate reviews start from what customers actually pay. And disputes are settled by looking up the version in force on the day.
Signs your rates need this
- Rate cards exist in more than one spreadsheet or system.
- Quotes and invoices sometimes disagree.
- Remote area surcharges are applied inconsistently.
- Customer deals are held separately from the standard card.
- You cannot quickly see what each customer pays.