As part of an online delivery experience for a restaurant, one of the most critical parts is to determine whether the customer placing an order is doing so from a location, which can be delivered to.
Delivery radius — circle of delivery
A simple solution to address this problem is to have the latitude/longitude of the store and then define a delivery
radius around it. When the customer enters her address, determine the lat/lng of the address and then use Google's wonderful APIs to determine whether the distance of the customer's delivery address is greater than the delivery
radius defined for the store.
This solution while simple and seemingly correct, has many practical issues, which can translate into a significant operational overhead for the merchant. For example, take the image below:
The store has a deliverable radius of 2kms. However, it’s easy to see that someone placing an order from across the lake would certainly pose a challenge. The route to reach the customer will be way more than 2kms, and the time to deliver will take a hit.
At this point, one might say, why not get the directions from Google and just consider the distance from that. Well, the problem with that solution is like so:
- A direction/route will only tell us whether Point A can be reached from Point B within a certain time. This still won’t allow the merchant to effectively define an area of delivery.
- Traffic conditions can create significant variations in the delivery time, and lead to a patchy experience for the customer.
- The merchant often times has a good idea about local traffic variations, optimal areas for delivery and which areas to exclude — but a direction based approach will take away that freedom from the merchant.
- Last but certainly not the least, the computational overheads of determining an optimal route between Point A and Point B are quite significant. And if a merchant even receives 1000+ orders a day, this can become quite significant.
The next approach is to define a polygonal shape using Google Maps to precisely outline the area where delivery can effectively be done from a store.
This approach has several benefits over the delivery radius approach. It allows a merchant to define a highly accurate polygonal overlay using Google Maps, which returns the bounds for a deliverable area. The points making up the bounds can then easily be used to determine whether the customer is trying to place an order from within a deliverable area.
The computation of determining a point within a polygon (adjusted for geo-spatial co-ordinates) is relatively simple and fast. So, computationally also this approach checks-out pretty well.
The only issue with this approach however, is that it can be a rather tedious effort to first determine and then accurately draw the polygons.
Another approach is to use the ZIP (Postal) codes associated with an area. Google Maps has good support for defining the bounds associated with a particular ZIP code.
The main benefit of this approach is that it provides merchants a trade-off between the accuracy of polygons, while making it less tedious to configure. The trouble however, can result from:
- Badly planned ZIP codes: in this case, the areas bounded by a ZIP code can be fairly arbitrary and of not much use to merchants.
- The lack of control over the area where delivery can be met by a merchant.
However, despite its shortcomings, the ZIP code based approach does provide a very quick configuration alternative to the tedious polygon based approach. Also, people are far more conversant with ZIP codes, and can easily find the codes associated with their stores. On the other hand, knowing the bounds for a polygonal area around a store is based on a bunch of assumptions.
The UrbanPiper platform allows merchants to choose any one of these 3 approaches while defining the deliverable area for a store. We’ve ensured that the task of configuration is as simple as it can get.
We continue to explore ways to make the whole process of cofiguring deliverable area really simple, while at the same time, ensuring the accuracy of the entire system.