Five disciplines for vehicles that leave the network

Location and engine data from a coach can serve very different purposes: telling a passenger when the bus will arrive, investigating a fuel discrepancy and reducing a driver's incentive. I treat each purpose as needing its own standard of evidence. For every device type in our fleet we measure position gaps, impossible jumps and power interruptions, and we publish those rates beside the reports that depend on them. An arrival estimate can tolerate a missing ten minutes; a pay deduction cannot. I agree with the operations director and the safety desk which alerts need human review and what corroboration they require. Some units are fitted partly to meet state requirements for passenger vehicles, and I keep compliance and usefulness as separate tests. A device can satisfy an inspector while producing data that should never decide someone's pay.

Our coaches cross ghat sections, forest stretches and state borders where coverage disappears for an hour or more. The crew handheld therefore treats a connection as a convenience. Boarding manifests, roadside tickets, parcel handovers and fuel slips are recorded on the device first, stamped with device time and a sequence number, and synchronised when the coach reaches coverage. The design question that matters is authority rather than storage: which record prevails when the office and the coach change the same berth or parcel while apart. I write those rules with depot managers and senior conductors, then test them on night runs before release. A conductor at two in the morning should never have to choose between the passenger standing in the aisle and the application in their hand.

Our booking engine sells the same berth through our website and app, online travel platforms, agents and counters. On an ordinary day the load is modest; in the days after Diwali or before a long weekend it can rise fourfold within hours. Preparation starts in June. We load-test at three times the previous peak, freeze non-essential changes for a fortnight, agree request limits with each platform partner and rehearse failover with our cloud provider. Each berth has one authoritative record: partners receive availability, never ownership. When something degrades, I would rather slow every channel slightly than let two channels sell one berth. The revenue team decides which routes receive capacity first, because that choice concerns passengers and income, not servers. My job is to make the trade-off visible early.

Parcels travel in the same holds as passengers' luggage, so a document problem can delay a coach full of people. I treat the parcel booking, the e-way bill where the consignment requires one and the hold manifest as one chain of records. The counter application will not label a parcel until a required document is recorded and valid, and the crew handheld confirms each handover. Toll charges follow similar logic. Each night we match FASTag debits with trip records to find wrong vehicle-class charges, duplicate debits and trips without an expected toll, and the finance team takes disputes forward. In 2025–26 the reconciliation identified ₹46 lakh of charges for review. Recovery is not its only value: a mismatch often reveals a coach that left its planned route or a unit that stopped reporting.

With 61 employees in technology I cannot build everything, and should not try. We build what carries our operating rules or shapes the passenger's experience: seat inventory, the crew handheld and trip records. We buy what a specialist does better under regulation or at scale, including payment gateways, e-way bill and GST invoice services, and messaging. The decision rarely ends at that point. Before signing, I now ask for data export on exit, service levels on peak dates, notice of interface changes and a manual fallback we have rehearsed. I learnt that from the parcel compliance purchase, where we accepted standard terms and later spent months renegotiating them. Every bought service has a named internal owner who understands it well enough to challenge the vendor and explain the dependency to our board.