Last-Mile Dispatch Console

Background

This case study describes a last-mile dispatch capability anchored to TrueLeaf Tech's engagement with a major retail chain operating across India. The client runs one of the country's most operationally rigorous store networks, and their last-mile fulfilment is where operational discipline meets the chaos of real-world delivery.

The problem we were solving

Last-mile delivery is the part of e-commerce where engineering meets the physical world, and the physical world wins more often than engineers like to admit. Traffic, weather, building access, customer availability, returns, cash on delivery, address ambiguity — the failure modes are essentially infinite, and any system that treats them as edge cases is a system that fails in production every day.

The brief was to build a dispatch console for the operations team running last-mile fulfilment across a regional zone. The legacy system was a combination of spreadsheets, phone calls, and the kind of accumulated tribal knowledge that worked but did not scale. The opportunity was to replace this with something that scaled, without losing the operational intuition that the existing process embodied.

What we built

The order intake and assignment layer

Every delivery order entering the system has to be assigned to a driver, with the assignment optimising for distance, current load, time windows, and a dozen other constraints. The naive approach is to optimise globally — solve for the best assignment of all orders to all drivers simultaneously. This is the kind of problem that looks tractable on a whiteboard and becomes computationally expensive in production.

We took a tiered approach. Bulk orders are assigned in batches using a simpler distance-and-load heuristic that produces good-enough results quickly. Edge cases — high-value orders, time-critical deliveries, customer service escalations — flow into a separate queue for operations supervisor review. The combination gives us automated decisions at scale and human oversight where it matters.

The driver companion app

Drivers need software that works in the field, with intermittent connectivity, bright sunlight, gloved hands, and the cognitive overhead of someone whose primary job is driving. The companion app was built with these realities as design constraints, not afterthoughts. Offline-first architecture. Large touch targets. Minimum required taps for the common workflows. Clear status indicators that did not require reading paragraphs of text.

The technical implementation used a local-first state model with eventual synchronisation to the central system. When connectivity returned, the app reconciled its local state with the server's view, surfacing conflicts to the driver only when human resolution was actually required.

The real-time visibility layer

Operations supervisors need to see what is happening in their fleet, in real time, at a level of detail that lets them intervene when things go wrong. The visibility layer aggregated driver positions, delivery statuses, and outcome predictions into a single operational dashboard, updated continuously.

The interesting engineering work here was in the prediction layer: not just showing where drivers are, but predicting whether they will hit their delivery windows. The prediction model used historical traffic patterns, current location, remaining stops, and a small set of contextual signals to generate a confidence-rated estimate. Supervisors used this to triage attention — to focus on the deliveries that were likely to fail rather than the ones that were likely to succeed on their own.

Engineering trade-offs we made

Optimisation completeness versus operational speed

Route optimisation has been an academic subject for decades, and the algorithms that produce theoretically optimal routes are well known. They are also computationally expensive. We chose to use heuristics that produce near-optimal routes in milliseconds rather than optimal routes in seconds. The operational speed was worth more than the marginal route improvement.

Driver autonomy versus dispatch authority

A persistent design question was how much autonomy to give drivers versus how much authority to centralise in dispatch. Pure autonomy produces inconsistent service. Pure centralisation produces drivers who resent the system and find ways around it. The right answer is in the middle, and the calibration shifts as drivers gain experience and as dispatch builds confidence in the underlying tools.

Predictability versus optimisation

A counterintuitive lesson from operations is that predictable routes are often more valuable than optimised routes. A driver who knows their route well — who knows the buildings, the access codes, the customer patterns — delivers faster than a driver running an optimised route they have never seen. We built the assignment system to lean toward predictability for high-volume zones, allowing drivers to develop the kind of local expertise that optimisation models cannot capture.

What we learned

• Field software is hard in ways office software is not. The conditions under which delivery drivers use software are radically different from the conditions under which dispatchers do. We tested the driver app under realistic field conditions early and often, and it was consistently worse than the office-tested version.
• The legacy system encoded real knowledge. The spreadsheets and phone calls we were replacing looked chaotic but encoded years of operational learning. We made a point of understanding why each spreadsheet column existed before we discarded it. Most of them, it turned out, were there for good reasons.
• Operations teams know more than they tell you. The most valuable design input came from sitting with dispatchers during peak operational hours, watching them work, and asking why each decision was made. The written requirements captured perhaps half of what actually mattered.

How this informs our client work

The patterns from this engagement — tiered assignment, offline-first field software, predictive visibility layers — apply to any operational software domain where physical execution and digital coordination meet. We have used variations of these patterns across logistics, field service, and retail operations.

If you are building operational software for a workforce that operates in the physical world, get in touch. The challenges are specific and the patterns travel well between domains.