What breaks in a fleet operation when you open the third city

A fleet operation in one city runs on a WhatsApp group and a spreadsheet, and it runs surprisingly well. The founder knows every supervisor. Exceptions get resolved by someone shouting across a room. The spreadsheet is wrong in places, but the person maintaining it knows where.

Two cities is uncomfortable but survivable. The third is where it stops. Not gradually — five things break within about a quarter of each other, and they turn out to be the same underlying problem wearing different clothes: the operating system was a person, and a person does not shard.

One: nobody knows where the vehicles are

In one city, vehicle location is a question you ask a supervisor. Across three, the answer takes an hour of phone calls and is out of date by the time it arrives. Utilisation becomes unknowable, and unknowable utilisation means you buy vehicles you did not need while a hub two hundred kilometres away has idle ones.

The fix is not just GPS hardware. Tracking gives you dots on a map; what an operator needs is the derived layer — which vehicles have not moved in three days, which are with a rider whose subscription lapsed, which are due for service, which hub is short tomorrow. Raw position without that layer just moves the phone calls into a browser tab.

Two: cash stops reconciling

This is the one that does real financial damage and it is almost always underestimated. If riders pay in cash — deposits, weekly rentals, damage recovery — then every hub is a small, informal cash office. In one city the founder counts it. In three, the gap between what was collected and what reached the bank becomes a number nobody can explain.

A security deposit is a liability, not revenue. If it is recorded as income when collected, the books are wrong from the first week and nobody notices until a refund.

Two design decisions prevent most of this. Record the collection at the point and moment it happens, on the collector's phone, with the rider and the vehicle attached — not typed up later from a notebook. And model deposits as a double-entry ledger with a liability account, so a deduction, a partial refund and a forfeiture are all ordinary postings rather than a spreadsheet adjustment.

Three: the supervisor WhatsApp group becomes the bottleneck

Forty supervisors in a group, several hundred messages a day, and inside them: breakdowns, no-shows, vehicle swaps, complaints, and a photograph of a damaged mudguard with no vehicle number attached. Nothing is searchable, nothing has a status, and anything not answered within twenty messages is gone.

The instinct is to ban WhatsApp. That fails, because it is genuinely faster than any app for the sender. The workable version is to accept the messages and structure them: a shared inbox where each message becomes a ticket with a category, a hub, an asset and an owner. Where a language model earns its place here is in classification — turning free text into a structured record — with a human confirming anything consequential. That is a small, well-bounded use of AI, not a moonshot.

Four: maintenance turns reactive and expensive

With one city, someone remembers which scooters are due for service. At three, servicing happens when something breaks, which is the most expensive possible schedule. Vehicles go off the road at the worst moment, spares get bought at retail prices in a hurry, and warranty claims lapse unnoticed.

This does not need a predictive model, and we would push back on anyone selling you one at this stage. Scheduled maintenance on odometer readings or engine hours, breakdown tickets raised from the driver app, spares consumption recorded against the vehicle, and a cost-per-vehicle number is enough to change behaviour. Get that running for a year and you will have the data a predictive model would need — but you will also have most of the benefit already.

Five: onboarding a hub takes as long as the first one did

This is the clearest signal that the operation is not yet a system. If opening hub number twelve requires the same founder attention as hub number two, growth is linear in the founder, and the third city is where that becomes obvious.

The test is whether a new hub manager can be productive from a checklist and a login, without a week of shadowing. That means roles, permissions, handover procedures and daily routines encoded in software rather than in the culture of the first location.

What to build first

Not all of it. In our experience the sequence that produces value fastest is: the money first, then the assets, then the exceptions.

• Collections and the deposit ledger. It stops financial leakage immediately and it is the piece that is hardest to reconstruct retrospectively.
• The vehicle register with custody — who has which vehicle, since when, at which hub. Everything else attaches to this.
• The driver or rider app, offline-first. If it needs signal or takes more than a few taps, it will not be used and the data will be wrong at source.
• Hub operations: allocation, shift rosters, handover checklists. This is what replaces the founder's attention.
• Live tracking and the derived operational layer on top of it.
• Exception triage from the messaging channel your supervisors already use.

A note on sequencing that we argue about with clients regularly: live tracking is usually what an operator asks for first, because it is the most visible. It is rarely the thing that is costing the most money. The deposit ledger is unglamorous and will not demo well, and it is where the leak is.