The Replacement That Was Not The Problem

Everyone agreed the system was the problem

When we arrived, the diagnosis was unanimous, which is usually a signal worth testing. Dispatchers said the system was slow. Drivers said it was useless. Operations said reporting was unreliable. A replacement had been approved on the strength of that agreement.

Unanimity about a tool is often unanimity about a symptom. We spent the first week sitting with dispatchers during live shifts rather than in a conference room, because what people describe in a meeting and what they do at four in the afternoon on a Friday are different things.

The system was not fast, and it was not the reason the operation was struggling.

What was actually happening on the floor

Every job was being entered twice. Once into the transport system, and again into a separate spreadsheet that dispatch had built years earlier to hold the information the system did not capture: gate codes, difficult access notes, which crews could handle which buildings, and which customers needed a call before arrival.

That spreadsheet was the real operating system. It was where the institutional knowledge lived. Nobody had ever asked why it existed, so the answer had never surfaced, and the platform got blamed for a gap it had merely failed to fill.

Drivers ignored the system for a related reason. Their information arrived on paper because the mobile app required a login that timed out and a data connection that did not exist inside half the buildings they worked in. The office then re-keyed the paper afterwards, which is where the reporting errors came from. Three entries of the same job, and the reports were built from the least reliable one.

What replacement would have actually cost

The approved budget covered licensing and implementation. It did not cover data migration, and six years of job history, customer records, and pricing precedent lived in the existing platform. Losing pricing precedent alone would have been serious in a business where quoting leans on what similar past jobs cost.

It also did not cover the retraining of a dispatch team through peak season, or the near-certainty that the same spreadsheet would reappear beside the new system within a quarter, because nothing about the replacement addressed why it existed.

Priced honestly, the replacement programme came in at roughly three times the integration work we recommended, and carried a real risk of arriving at the same position with a different logo on the screen.

Fixing the gap instead of the logo

The recommendation was to keep the platform and close the three gaps that made it unusable. Extend the job record to hold what the spreadsheet held, so the knowledge moved into the system of record rather than beside it. Replace the driver app with an offline-first mobile capture flow that survives a basement with no signal and does not demand a login mid-shift.

Then remove the double entry entirely, which the first two changes make possible, and rebuild reporting off a single record instead of the least reliable of three.

None of this is exciting. It is also the difference between a dispatch team that trusts the system and one that keeps a shadow copy, and no amount of new software fixes that on its own.

The uncomfortable part of the report

We told the leadership team that the replacement they had approved would probably have failed, and that the spreadsheet would have been rebuilt within three months of go-live. That is not a comfortable conversation with people who have already defended a budget.

It landed because it was evidenced. We were not offering an opinion about their platform. We were showing them three copies of the same job, the report those copies fed, and the gap every one of them was working around.