Enhancing our location data for delivery drivers
COVID-19 has had an enormous impact on all of our lives, and Food Retail is an industry that’s been uniquely affected by this public health crisis. At Sainsbury’s Tech, there’s been a wide range of work we’ve done to try and provide support to our customers, colleagues, and help feed the nation — including expanding our ChopChop bike delivery service, reserving priority delivery slots for our most vulnerable customers, and massively expanding our click and collect locations.
However, we’ve also been working hard to improve some of the less visible parts of our online operations, all of which have had to scale up quickly!
Planning, Scheduling and Routing
I work in a team called Plan, Schedule, Route. We look after, surprisingly, the planning, scheduling and routing of our online deliveries and collections. Part of that work includes something called the Customer Geolocation Service, which provides geographic data for our online drivers so they can accurately navigate to customers and deliver their groceries.
Until recently, we were using a combination of customer postcode data and data from the Royal Mail PAF to send drivers to the latitude/longitude of that postcode. However, this presents a problem.
The Problem
While postcodes are great for routing mail, they cover a wider geographic area than might be expected. The data we were using provides the centre point, or centroid, of this postcode area. As an example:
Sainsbury’s in Nairn, near Inverness, has the postcode of IV12 5QF. The centre of this postcode is here:
However, the store is actually almost 1 kilometre down the road, at this business park:
This is bit of a contrived example, but there are many situations where we have problems with finding locations for our customers due to this inaccuracy:
- Rural areas where postcode areas are much more spread out, and postcode centres can be 100s of metres away from actual delivery addresses
- Unlit streets where it’s difficult to find the actual house address
- Areas which contain a high proportion of houses with names rather than numbers
With our recent increase in delivery volumes, and the focus on prioritising elderly, disabled and vulnerable customers, we are also seeing many people who haven’t shopped with us before and whose addresses the delivery driver may not know. We’re also hiring lots of new delivery drivers, and are being supported by many Argos drivers who don’t know the routes or areas our grocery deliveries fulfil.
If we could cut down some of the time spent finding customer’s addresses, we might be able to deliver more orders within a day and therefore open up more delivery slots to our self-isolating or vulnerable customers.
The Solution
Our existing geolocation service worked like this:
We receive order data on an ActiveMQ bus, which contained a latitude and longitude generated from the postcode centre. This is then stored into Redis against an order number, and exposed to the drivers’ SatNav handset via an API.
We work with an external data address provider, who currently supply the Royal Mail postcode data we use. They also have the ability to supply 1-metre accuracy data from the Ordnance Survey — much better! We also discovered that our Nectar team were already using a lower resolution version of this data to validate customer addresses at registration, and had a service which could look up an address and return latitudes and longitudes.
Over the course of 3 weeks, we:
- Updated the Nectar service to use the new address data, and expose it via a new, freeform address search endpoint
- Amended our Customer Geolocation Service to call this new endpoint, retrieve the 1m-level geodata, and store it against the order number — importantly, this would still fall back to the postcode centre data if no 1m-level data could be found
- Released the new feature into a single store in Kent (Herne Bay) to gather some feedback
Delivering some feedback
Initial testing in Herne Bay showed some really positive results! We had addresses that were being navigated up to 800 metres away from the actual house, and lots of much smaller inaccuracies of between 40 and 100 metres. We noticed a few situations where a customer address was completely off, however, and decided to investigate.
When entering your delivery address into our groceries website, you go through a standard address capture — enter your postcode, pick your house number, and we’ll fill the address in. However, we also allow customers to then override this information and update house numbers, street names and postcode data. Some data is also fairly old, and hasn’t been updated. Some addresses are also quite hard to find! Flats, shared residencies, and business addresses all caused problems.
In these cases, when we went to search for the latitude/longitude of the address, we received data for an address in a completely separate postcode, which then had a very inaccurate location. Given our fallback mechanism, we had a simple fix — if the returned postcode doesn’t match the postcode we were searching on, drop the new geodata and use the existing postcode centre. We made the change for the next day’s deliveries, and saw a great improvement.
To learn a bit more about how the system coped with more complex addresses, we then decided to roll out to another 14 stores, in Devon, Cornwall and Northern Ireland. These areas were chosen because of a high number of addresses using house names, and in Northern Ireland’s case, historically poor accuracy of our address data. After a couple of teething problems with data access, we saw similar results to our initial pilot, and were happy to roll the change out nationally!
Impact
We announced the change to our drivers on our internal social network, and waited to see what the results would be — we learned a few things very quickly:
- Drivers had really low confidence in the existing sat-nav and its results, and in many cases weren’t using it at all
- Lots of drivers were using external, 3rd party tools to help navigate to their final address location. Online maps, mobile apps — some of which involved a subscription that drivers were paying out of their own pockets!
- Our drivers had a lot of valuable feedback and ideas on how we could navigate them better — given they are the people driving the vans to our customers, they’re absolutely best placed to give us this advice.
After a few days usage, the feedback was overwhelmingly positive:
What’s next?
As with all new launches, we learned an absolute ton from this — one thing that’s really clear is where we have low quality address data for our customers. Building out CGS with new functionality allowed us to get really clear visibility of where this data is lacking, and sparked multiple conversations on how it could be improved.
We’d also love to start taking driver overrides into account in a much more streamlined way — currently this is a very labour-intensive process that involves drivers submitting corrections to locations, and those overrides being manually entered into our systems. Automating this would be a big win!
This was a really fun project to turn around quickly, and really showed the power of:
- Teams that can quickly adapt to new requests, and build new products and features with low lead times
- Working closely with stores and drivers to get timely and useful feedback, learning fast from pilot releases and trials.
- Really strong collaboration across teams both inside and external to Sainsbury’s — including PSR, Nectar, our InfoSec and procurement colleagues, and our support desk and service management teams.
