This is a tutorial for retail chains doing home deliveries through their store network. As store-assigned assets shift to regional resource pools, and ecommerce orders are assigned to riders on-demand, the role of live location becomes critical in managing dispatch, pickup and delivery.
Live location of riders and orders is used by ops managers, customer support and end customers to get visibility. Operations teams can improve productivity by rewarding top performers, and reduce cost by proactively handling delays and no shows. End customers being able to track orders further leads to better service experience, and reduced customer support costs.
In this tutorial, we consider a delivery business that has a number of stores with a regional pool of delivery riders. Orders are assigned to nearest available riders. Riders receive the orders in the app with details on which store to pick up from, what to pickup, and address/details of customer to deliver to.
We will go through the following components:
- Dispatch: assign order to available rider who is nearest to pickup store
- Rider app: manage rider identity and track distance between app events
- Operations dashboard: embed rider and order views in your ops dashboards
- Exception workflow: proactively handle delays, no shows and delivery retries
When delivering through stores, riders may be available as a regional resource pool or be dedicated to stores. Either way, the busniess goal is to minimize idle time, and maximize time doing pickups & deliveries. Business logic to dispatch orders requires live location of riders to assign orders more efficiently and achieve these goals.
Nearby API returns a list of riders near the pickup location, ranked by nearest first. Please visit this guide to learn more.
Get nearest delivery riders for order dispatch
Please review this payload example for the Devices Nearby API call. In this example, the store is identified as
coordinates whereas you may seek delivery riders that designated to serve a particular area.
As explained in the guide as a result of this call, you will get a list of device ids representing delivery riders. The example below has an example of two delivery rider's device_ids returned to you. You will pick this rider as the one to dispatch an order to.
Create trip with destination for each delivery order
Now that you have a deliery rider available to pick up the order, you can get started with delivery order tracking. Each time a delivery rider picks up a delivery order to go out for delivery, create a Trip with destination.
Use metadata to create a trip for the delivery order. Using trip metadata will allow you to create store level, flexible, embeddable operations views in the delivery app dashboard.
Please see the trip creation payload example below. For more details on how to integrate HyperTrack Trips API with destintion, please visit this section of Track live route and eta to destination guide.
Once HyperTrack receives Trips with destination API call from your delivery app backend, it will reach out to the delivery rider app and immediately start location tracking on the device.
trip_id for each trip must be stored in your delivery app backend and mapped to your internal delivery order identifier.
Create multiple delivery orders per delivery rider
In the use case where a single delivery rider picks up multiple orders from the store, proceed to create trips with destination for each order. For example, in the beginning of the day, the delivery rider comes to the store to pickup multiple delivery orders for the day.
All these trips would have same
route_id indicating them part of single route of delivery rider.
Share live ETA with customer
For each delivery, share live tracking view with customer whenever the delivery rider starts working on the next chosen delivery order. Please review sharing live real time tracking view with customer guide.
The live tracking view can be customized as described in this section of the same guide.
The decision on when to share a live ETA with public share URL with the customer can be done based on understanding when is the next order. Additionally, you may decide to send pubic share URL based on remaining ETA of the current trip for the delivery order.
HyperTrack provides real-time ETA change notifications which deliver remaining ETA time via webhook integration with your delivery app backend.
Please check out getting webhook updates guide section on how to parse webhook payloads inside your delivery app backend.
Once you know when the next delivery order is up, you may decide to share live ETA with the customer once ETA reaches a threshold (remaining time in seconds) that works for your business.
To add location-based automation to your delivery solution, you must add the HyperTrack SDK to your delivery rider app. Please use one of the following options.
Enable location tracking in rider app
Follow these instructions to install the SDK.
Identify delivery riders
In order to embed store-level views in your operations dashboard, you must add stores as metadata for your riders' devices. This would help you filter the views and restrict them to the store's orders and riders.
Review instructions on how to set device name and metadata and make a decision on what works best for your delivery app.
For example, the device name can be a phone number or some other identifier you use in your system with example metadata below:
These metadata attributes can be useful to identify and filter selected store delivery riders in the dashboard.
Get distance and time spent between deliveries
While you use Trips API to create trips with destination and ETA for each delivery order, HyperTrack provides you necessary tools to help understand distance and times between delivery points.
As delivery rider marks orders as done in the app, you can use HyperTrack SDK method to send a geotag from the rider delivery app to HyperTrack platform. HyperTrack will generate
route_to information in webhook notifications for each triggered geotag as explained in this section.
Verify actual delivery location
As mentioned above, delivery rider can trigger geotag to be sent from the delivery rider's app.
HyperTrack will process the geotag event and attach location associated with the marker in the webhook update payload as described below in an example. You can use trip metadata to help associate the geotag data with the trip created via Trips API for the delivery order as described above in trip creation section.
Store managers and customer support teams use dashboards to manage delivery operations. HyperTrack views may be embedded directly into the dashboards they know and love.
Store managers can view the progress through the day in real-time, with drill downs into the progress of each rider in the team, and each order assigned for delivery.
Customer support execs can view the real-time status of each order, with drill downs into the timeline of movement. To achieve role based access, the views may be controlled using metadata.
Orders or riders' days may be replayed in case of an escalation.
Insights may be used to track the productivity, efficiency and behavior of riders, and export reports as CSV.
Embeddable hierarchical dashboard integration
As explained in embed hirerchical views guide HyperTrack enables you to create embedded real-time delivery order tracking in your delivery app operations dashboard. To build such a dashboard, you use inline frames to quickly embed real-time dashboard built by HyperTrack in your application.
Create store manager and customer support dashboards
Store managers can use a real-time dashboard to view all scheduled deliveries for the day in real-time.
Create store manager dashboard for all delivery riders
Use trip metadata to create a store manager dashboard to track all delivery riders.
As mentioned above you can use trip metadata to identify which stores are associated with delivery orders to be displayed. Filtering by trip metadata will allow HyperTrack to merge multiple trips in a single view. As per example above, use
store_id metadata key to group together trip views.
%7B%22store_id%22%3A%22%7Bstore_id_value%7D%22%7D is url encoded string for JSON
Create store manager dashboard for a selected delivery riders
Use device metadata to create store manager dashboard for a single delivery rider. As mentioned [above] you can leverage delivery rider metadata to identify a team of riders and show their real-time location in the dashboard.
%7B%22team_id%22%3D%22%7Bteam_id_value%7D%22%7D is url encoded string for JSON
Create store manager dashboard for a delivery route of a rider containing multiple orders
In cases where a delivery rider picks up multiple orders from a store and deliver all of them as part of a single route, store manager may want to track the progress of this delivery rider on his route.
For this you can use
route_id field set as part of trip metadata for all the trips corresponding to the multiple orders
%7B%22route_id%22%3D%22%7Broute_id_value%7D%22%7D is url encoded string for JSON
Customer support dashboard
If you have a customer support team assigned to work in a region which include multiple stores, you can define metadata that use a customer support team internal id. This id can be used as part of trip metadata.
Thus, you can create a dashboard that with the following code:
%7B%22support_team_id%22%3D%22%7Bsupport_team_id_value%7D%22%7D is url encoded JSON
The primary purpose of an operations team is to ensure that deliveries go about smoothly. When exceptions occur, the team needs to know before the customer does, and proactively handle the situation in a way that solves the issue. For most ops teams, location tracking serves the purpose of discovering these exceptions. HyperTrack reports exceptions through webhooks and views.
Proactively handle delivery order delays
If your business requires timely delivery commitments, such, for example, a delivery order must be made between say 2pm to 4pm window, you must be able to take action early if delivery cannot be made in time.
scheduled_at option when creating a trip with destination via Trips API. In the case above, you can create a trip for this delivery order with
scheduled_at time set towards the end of the timing window. If the delivery rider gets delayed and unable to make the delivery on time, HyperTrack will send you a webhook trip delay notification to your delivery app backend for further action.
Proactively handle delivery rider no-shows at store
Similarly as above, it's important for store managers to expect delivery riders arrive at the store for timely order pickup. In this case, to be proactively notified if the delivery rider is delayed, use
scheduled_at option when creating a trip with destination via Trips API. The store location would be the destination for the delivery rider.
If the delivery rider is estimated to be late to arrive at the store, HyperTrack will send you a webhook trip delay notification to your delivery app backend.
To learn how to create trips with destination and enable ETA delay notification, please read this guide section.
If your business requires package receiver presence upon delivery, you may have a use case of a delivery being retried.
You can handle this use case with HyperTrack as follows:
- Complete the trip for
trip_idfor the unsuccessful delivery.
- Create another trip with destination for the order being retried.
- Once the delivery rider proceeds to re-deliver the unsuccessful delivery, in your business workfllow, you can share the ETA with the customer again for the delivery being retried.
Track deliveries through stores with HyperTrack
In summary, your delivery app will work with HyperTrack as follows:
- A delivery rider receives deliveries assigned by the store manager in the delivery rider app.
- As soon as the delivery rider is assigned new delivery order, a new trip with destination is created via HyperTrack Trips API from your delivery app backend.
- Once the new trip with destination is created, HyperTrack immediately starts location tracking in the delivery rider app if location tracking has not yet started for the rider's device.
- For every new delivery order for the same delivery rider, create another trip with destination via HyperTrack Trips API from your delivery app backend.
- The delivery rider manually creates a route by sorting delivery orders in the app and proceeds to go out for deliveries. Once this is done, share a public share URL link with the current waiting delivery customer.
- Once the delivery is made, delivery rider marks the delivery order as complete in the app. This will notify your delivery app backend.
- Your delivery app backend will in turn complete the trip via HyperTrack Trips API.
Delivery rider will proceed to the next delivery order. Share the link as described in Step 5 above for the next trip with ETA to destination with the next customer. Repeat steps 6 and 7 until all deliveries are completed.
Once delivery rider's marks the last order for the day as delivered, your delivery app backend will complete the last trip for the day. In this case, HyperTrack will stop location tracking for the delivery rider's app.
If you are building a delivery solution at scale just like the one described above, Team HyperTrack is here to help. If you have questions or comments on any of the topics above, please do not hesitate to contact us.