Insights & Opinion

The Rivigo pivot did not surprise anyone who was watching the unit economics. What surprises me is that it still surprises people.

The asset-light FTL aggregation model has a structural problem that venture capital enthusiasm cannot fix: the value in road freight is captured by the asset owner, not the intermediary. When you remove the asset, you remove the pricing power. What you are left with is a matching platform in a market where matching is not the problem.

The Myth of the Fragmentation Opportunity

Every FTL platform pitch deck starts with the same slide: "Indian road freight is ₹8 lakh crore and 90% fragmented." Both numbers are probably right. The logic that follows — "therefore, aggregation creates value" — is where it breaks down.

Fragmentation in trucking is structural. Small fleet owners survive because they are embedded in local networks, operate on trust relationships, and have cost structures that a funded platform cannot replicate. Aggregating them does not reduce friction — it adds a margin-hungry layer on top of it.

"You cannot out-relationship a transporter who has been in the same route for 20 years. You can out-technology him, but only if the technology solves his actual problem — which is collections, not bookings."

What Actually Works

The FTL platforms that are building durable businesses are the ones that picked a specific vertical — auto-ancillary, pharma, FMCG — and went deep. They are not marketplaces. They are managed service providers with technology on top. Blackbuck pivoted to fintech because the payments problem is real and the incumbents are weak. Rivigo kept the relay model because it genuinely reduces driver fatigue on long-haul routes. Both pivots were away from pure aggregation.

If you are building an FTL platform, the question to ask is: what problem in this ecosystem can only be solved by someone who controls the full stack? Booking is not that problem. Collections, compliance, and driver welfare are.

In almost every logistics company I have worked with, there is a freight audit process. In almost none of them does it actually work.

The gap between what is invoiced and what is validated costs the average mid-size logistics company between 3% and 5% of revenue annually. In a ₹100 Cr business, that is ₹3–5 Cr walking out the door every year without anyone noticing — because the leakage is distributed, small per instance, and nobody owns the reconciliation end-to-end.

The Three Places the Money Goes

First: rate errors. Contracted rates applied incorrectly at billing. This happens because contracts are stored in spreadsheets, updated manually, and not connected to the billing system. The error rate is small per invoice — ₹200 to ₹2,000 — but at scale, it compounds.

Second: accessorial charges. Fuel surcharges, waiting charges, detention, and route deviation charges that are either applied when they should not be or not applied when they should be. Most 3PLs do not have a clear policy on these, so billing teams use judgment, which is expensive.

Third: POD reconciliation failures. Invoices billed without confirmed delivery. Weight discrepancies never queried. Special handling charges applied for services that were not rendered. None of this is fraud — it is process failure.

The Fix Is Not Software

I have seen companies buy expensive freight audit software and watch the leakage continue. The software identified the discrepancies. Nobody acted on them because the dispute process was broken, the SLAs were not enforced, and the relationship with the transporter took precedence over a ₹500 discrepancy.

The fix is a process — a monthly freight audit reconciliation cycle with a named owner, an escalation path, and transporter performance scorecards that include billing accuracy. The software helps. The accountability structure is what actually closes the gap.

The standard sequence for a logistics technology purchase goes like this: recognise a problem; search for software that fixes it; implement; discover that the problem still exists.

It is backwards. Technology is an amplifier, not a fixer. It amplifies whatever process it is layered on top of — which means that buying a TMS before you have a clean dispatching process gives you faster, more expensive chaos.

What I See in Most Selections

The selection is led by the IT team or a consultant who does not understand operations. The shortlist is built on demos and feature checklists. The operations team is consulted for requirements but not for process design. Nobody asks the fundamental question: what does our process need to look like after implementation, and does our team have the discipline to run it?

A TMS that is 70% of the perfect fit, implemented on a well-designed process with trained users, will outperform the "best" TMS implemented on a broken process every single time.

The Right Sequence

Fix the process first. Document the dispatching flow, the load planning logic, the carrier allocation rules, and the exception handling procedure. Then ask which parts of that process the technology should automate. Now your requirements are real — not a wish list from a demo.

The technology vendors will thank you, because they will have fewer customisation requests. Your operations team will thank you, because the tool will actually reflect how they work. And your CFO will thank you, because the ROI will be real.