Transportation
One Trip Record: Why Fleet Software Fragments
Rider app, driver app, operator console. When each keeps its own state, the disagreements surface as disputed fares and phantom vehicles.
Transportation platforms are three products wearing one name: an app for riders, an app for drivers, and a console for the people running the operation. The failure mode is letting each hold its own version of the truth.
How the disagreements surface
It shows up as small discrepancies with expensive consequences. The rider app says the trip ended at one time, the driver app at another, and the fare is disputed. The console shows a vehicle as available while the driver considers themselves off shift. Support cannot resolve any of it, because there is no single record to point at.
One record, three views
Our approach is that the three surfaces share one trip record, one fleet roster and one payment ledger. Each application is a different view onto the same state, not a separate system that reconciles later. Reconciliation is where discrepancies are born.
The client reports, it does not decide
This constrains the mobile clients in a way that is worth being explicit about: they are not free to invent state offline. A driver app that loses signal queues its intent — trip started, passenger collected, trip completed — and the server remains the authority on what those events mean for the fare. The client reports; it does not decide.
Every fare dispute is two systems that were each certain they were right.
