Skip to content
PRSINDIA

Turant Logistics

Cutting order-to-dispatch by 62% for a 400-truck 3PL

A fleet, ePOD and route-optimisation platform built offline-first for drivers in low-connectivity corridors — because the two off-the-shelf TMS products they tried before assumed a live connection at the moment of delivery.

Client
Turant Logistics
Industry
Logistics & Supply Chain
Location
Gurugram, India
Duration
22 weeks

0% faster

Faster order-to-dispatch on the ops floor

0% shorter

Shorter POD-to-invoice cycle (8.4 days to 19 hours)

0% lower

Fewer empty-run kilometres in the first full quarter

0M/day

GPS pings ingested daily, off the transactional database

01

The challenge

Turant Logistics moves roughly 1,100 consignments a day across nine hubs with a mixed fleet of 400-odd trucks — about a third owned, the rest attached vendors. When we met them, the dispatch desk ran on three WhatsApp groups and a shared Excel workbook that one supervisor in Gurugram owned and everybody else screenshot.

What was actually broken

  • Nobody knew where anything was. Vehicle location came from calling the driver. The ops floor had a wall of phones and a whiteboard, and the customer-facing answer to "where is my load" was a callback promise.
  • Paper PODs were eating the cash cycle. The signed delivery challan travelled back to the hub in the driver's dashboard, got couriered to Gurugram, and was keyed in by hand. Median time from delivery to invoice was 8.4 days. On a business running on 30-day credit, that is 8.4 days of working capital lit on fire, every single load.
  • Route planning was folklore. Multi-drop runs were sequenced by whichever supervisor was on shift, from memory. Nobody could tell us what an empty-run kilometre cost them because nobody was measuring empty runs.
  • Disputes were unwinnable. With no timestamp, no geotag and no photo, a "short delivery" claim from a consignee was the consignee's word against a driver's. They wrote off a meaningful slice of revenue every quarter rather than fight.

The hard constraint — the one that killed the two off-the-shelf TMS products they had already tried — was connectivity. A large share of their line-haul runs pass through corridors where a phone has no usable data for hours at a stretch. Both products they had piloted assumed a live connection at the moment of delivery. Drivers responded the way drivers always do: they stopped using the app and went back to paper, and the pilot was declared a failure of "driver adoption". It was not. It was a failure of architecture.

02

What we built

We built three things that had to work together: an offline-first driver app, a route optimiser, and a telematics pipeline that would not fall over. Each one turned on a decision we want to be explicit about.

Offline-first, not offline-tolerant

The driver app (Flutter, single codebase for a fleet running everything from a 2019 Redmi upward) treats the network as an optional resource. Every action — arrival, unloading start, ePOD capture, exception — is written to a local SQLite write-ahead queue first and acknowledged locally. Sync is a background worker with exponential backoff. The driver never sees a spinner and never sees "no internet".

That design forces two things most teams skip. First, every mutation carries a client-generated idempotency key, because a retry over a flaky link will deliver twice — this is not a risk, it is a certainty at 400 trucks. Second, consignment status is a server-authoritative state machine, so a stale offline event that arrives an hour late cannot drag a delivered load back to "in transit". Late events are applied only if they are legal transitions; the rest go to a review queue with the ops team, which turns out to be about 40 rows a week.

ePOD is a geotagged photo plus an on-glass signature, compressed to WebP on-device (~120 KB) before it ever touches the upload queue, because the whole point is that it has to survive a 2G handshake.

We did not write our own route optimiser

Multi-drop routing with vehicle capacities and delivery time windows is a capacitated VRP with time windows — NP-hard, and a solved problem. Hand-rolling a nearest-neighbour heuristic would have cost us two months and produced worse routes than a mature solver produces in twelve seconds. We stood up Google OR-Tools in a small Python service, called from Laravel over a dedicated queue with a hard 20-second solve budget, and cached the plan. Laravel owns the domain; the solver is a function.

Telemetry that does not poison the transactional database

400 trucks pinging every 10 seconds is ~3.4M rows a day. We kept those out of the operational MySQL entirely: pings land in a day-partitioned store, Redis holds only last known position per vehicle, and the live ops map is fed by Server-Sent Events rather than a polling loop that would have had every ops browser hammering the API every three seconds. Reporting runs off a read replica so a regional manager's month-end export cannot slow down a dispatch.

03

The outcome

The app went to two hubs first, ran there for five weeks, then rolled to the remaining seven over a month. Drivers were trained in Hindi by their own hub supervisors, not by us — a detail that mattered more than any feature we shipped.

Where the numbers landed

  • Order-to-dispatch fell 62%. The dispatch desk stopped being a phone bank. Loads are now assigned against live vehicle availability, and the supervisor's job changed from finding trucks to approving exceptions.
  • The POD-to-invoice cycle collapsed from 8.4 days to under 19 hours — a 91% reduction. The ePOD hits the server the moment the driver reaches signal; invoicing is a queued job that fires off the POD event. The finance team did not get faster. The information got faster.
  • Empty-run kilometres dropped 18% in the first full quarter, straight out of the OR-Tools sequencing and backhaul suggestions. This is the line item that paid for the project.
  • 3.4M GPS pings a day are ingested without the ops database noticing, and the live map holds sub-second freshness for a full fleet on a single modest instance.

The parts we care about more

Crash-free sessions on the driver app sit at 99.6%, and — the metric we actually watch — the offline queue has never lost a POD. Not one, across a run of over 300,000 deliveries. Short-delivery disputes are now settled by opening a geotagged photo with a timestamp, which ended the write-offs almost overnight and is quietly the outcome the CFO talks about.

The system has since absorbed a fourth region and a 40% fleet increase with no architectural change and no re-platforming, which is the only real test of whether the original decisions were right.

Under the hood

How it's built.

Technology

  • Laravel
  • MySQL 8
  • Redis
  • Laravel Horizon
  • Flutter
  • SQLite (Drift)
  • Google OR-Tools
  • Python / FastAPI
  • Mapbox GL
  • Server-Sent Events
  • AWS
  • Docker

Services used

  • Custom Software Development
  • Mobile App Development
  • Cloud & DevOps
  • API Integration
  • UI/UX Design

The last two vendors blamed our drivers when the pilot failed. PRS spent a week riding in the trucks and came back saying the problem was their software, not our people. That was the moment we knew.

Devansh Kalra Chief Operating Officer, Turant Logistics

Same problem?

Let's build something that ships.