A routing engine is a machine for turning coordinates into decisions. Feed it coordinates that are 400 metres from the loading bay and it will make confident, precise, wrong decisions all day.
Address data is the least glamorous part of a route software project and the highest-return one. It is also the part nobody is assigned to own.
How geocoding goes wrong
Centroid fallback. The geocoder cannot match the exact address, so it returns the centre of the postcode, street or town. The pin lands somewhere plausible-looking, often hundreds of metres out, sometimes kilometres in rural areas. This is the single most common problem, and it is silent — nothing in the interface says "this is a guess".
Wrong side of a barrier. The pin is 30 metres away but across a motorway, canal or one-way system, so the real approach adds four minutes.
Front door instead of goods-in. Correct for a postal letter, wrong for a 12-tonne vehicle that needs the service road behind the building.
Interpolated street positions. Many geocoders estimate house positions by interpolating along a street. Accurate on regular residential streets, poor on long rural lanes and industrial estates.
Stale addresses. The customer moved. The old address still geocodes fine, so nothing alerts you.
Duplicates. The same physical site under two customer records, planned as two stops on two routes.
In most databases, a small minority of records causes the great majority of routing pain. Rank by measured error and fix the top 5%.
Auditing what you have
Run these five checks before any route software project. All are straightforward with the data you already hold.
- Match-quality distribution. Every geocoder returns a precision level (rooftop / parcel / street / postcode / locality). Count them. Anything below street level should be treated as unverified. Seeing 20–40% below street level on first audit is normal.
- Actual-versus-recorded distance. Compare the recorded location with the average GPS position where drivers actually stopped. Sort descending. The top 5% of that list is your fix queue, and it is usually short.
- Duplicate detection. Cluster customer records within 50 metres with similar names.
- Dwell-without-delivery. Locations where vehicles regularly stop that are not customer records — often the real access point for a customer geocoded elsewhere.
- Failure correlation. Cross-reference failed deliveries and "could not find" exceptions against match quality. The relationship is usually stark and makes the business case for you.
Fixing it
Capture the truth from the vehicles. Your best source of correct coordinates is where drivers actually park. Aggregate the GPS positions of completed stops over 90 days, take the median, and propose it as the corrected location. Many fleet platforms will do this natively; if not, it is a modest data exercise.
Add an approach point, separate from the address. Serious operations store two things: the postal address (for paperwork) and the service point (for routing). Conflating them is the root cause of a large share of geocoding pain.
Capture access notes as structured data. "Gate code 4471, use rear entrance on Mill Lane, no vehicles over 7.5t" belongs in fields the driver app can display, not in a free-text comment nobody reads.
Validate at creation. The cheapest fix is not creating bad records. Address validation at the point of customer setup — with a map confirmation step for commercial accounts — prevents most future problems.
Close the loop from the field. Give drivers a one-tap "location is wrong" action that captures their current position and creates a review task. Drivers know exactly which records are wrong; most systems give them no way to say so.
Keeping it clean
Data quality decays. Build a monthly report showing:
| Metric | Target |
|---|---|
| Records below street-level match | Under 5% |
| Records with actual-vs-recorded error over 150 m | Under 2% |
| Records missing an access note in "difficult" segment | Under 10% |
| Open driver-reported location issues over 14 days | Zero |
| Duplicate candidate pairs unreviewed | Zero |
Assign an owner. Unowned data quality metrics are decoration.
What it is worth
The arithmetic is simple enough to do on a napkin. If 8% of your stops carry an average 3 minutes of avoidable searching and manoeuvring, on 60 stops per route across 20 routes:
`` 60 × 0.08 × 3 minutes = 14.4 minutes per route per day × 20 routes = 4.8 hours per day × 250 days = 1,200 hours per year ``
Plus failed deliveries, plus redeliveries, plus the customer service calls. Against perhaps two weeks of focused data work.
Frequently asked questions
Should I buy an address validation service?
For high volumes of new addresses, yes — validation at entry is cheaper than correction later. For a stable commercial customer base, a one-off cleanse plus driver feedback is usually enough, and you can spend the licence money on the access-point work instead.
Is one geocoding provider better than another?
They differ meaningfully by country and by address type — rural addressing, informal addressing and newly built estates separate them fastest. Test candidates against a sample of 200 of your addresses, weighted towards the difficult ones, and compare match quality rather than reading comparison tables.
What about what3words or similar systems?
Useful as a supplementary access point for locations with no meaningful street address — rural gates, construction sites, large campuses. Treat it as an additional field, not a replacement for coordinates, and check that your driver app can actually display and navigate to it.
How do I handle multi-entrance sites?
Store the service point per delivery type. A supermarket may have a chilled dock, an ambient dock and a front entrance for small parcels, each with different access rules and dwell times. Modelling them as one location guarantees planning error.
Who should own address data?
Whoever owns customer master data, usually in operations or commercial — not IT, and not the routing team alone. The key point is that someone's objectives include the monthly quality report.
