Workday analytics
Workshift Metrics
is hereBETA
A clear, end-to-end picture of every driver's day. What happened, when it happened, and how it measured up to the plan.
Hi there,
We've been building this one for a long time, and we're genuinely excited to put it in your hands. Workshift Metrics takes the raw activity of a driver's day, every stop, every pause, every kilometre, and turns it into a single, readable story.
Open any workday and you'll see at a glance whether it went to plan: where time was lost, how delivery throughput held up, and exactly how the route unfolded on the map. It's built to help you spot a problem shift in seconds and understand the why behind it, without digging through raw logs.
A quick tour
What you'll see
Every workday opens with a plain-language summary and a set of headline metrics. The example below is an anonymized sample shift.
09:23
km
Below these cards you'll also find the route map, an interactive timeline, and a full journey log of every stop.
Behind the numbers
How we work it out
Every metric is derived by combining the planned orders with the activity recorded by the driver app during the shift, with more data sources on the way.
It starts with the plan
A workshift is the list of orders a driver is meant to complete that day. Every order has a pickup and a delivery location. In most cases the pickup is a single batch run at the depot, with the driver fanning out to drop-offs from there.
One batch pickup at the depot → a sequence of delivery stops.
The driver app records the day as it happens
While the driver works, the Zendera driver app stays online and reports its location at frequent intervals, the same signal dispatch uses to track everyone in real time. At each stop the driver also logs a sequence of actions: arrived, scan the packages, sign, and confirm completion before moving on.
That stream of locations is raw and a little noisy, so we don't use it as-is. We process it through a road-matching system that aligns each point to the actual road network, so distance and travel times reflect the route that was genuinely driven, not a straight line between stops.
GPS pings every few seconds
Continuous location pings between stops; a sequence of timestamped actions at each one.
Bringing the two together
We align the order plan (what was scheduled) with the processed app activity (what actually happened) and derive each metric from there. A few of the key ones:
Actual workshift = first GPS movement → last completed action.
Dwell time at each stop is the gap between the arrived and completed signals. GPS-detected stops (pauses with no scheduled order) are surfaced separately so they never quietly inflate your numbers.
On the horizon
Coming next: the bigger picture
Workshift Metrics shows you one day at a time. We're now building an aggregated view that zooms out, so you can follow a driver, a route, or a location across weeks and months instead of a single shift.
Trends across drivers, routes & locations
Spot the route whose throughput is slipping, the driver whose on-time rate is climbing, or the depot where dwell time keeps creeping up, over any stretch of time you choose.
A preview of the direction, not the final design. We'll share more soon.
Take it for a spin
Open any recent workday and see how your shifts really ran. We'd love to know what you think.