From spreadsheets to a system the team trusts

A 40-person operations team at a regional distribution business had run its dispatch and scheduling on shared spreadsheets for the best part of a decade. It worked right up to the morning a stale formula quietly double-booked half the fleet, and nobody could say who had changed what, or when. Teams rarely call us when the spreadsheet breaks; they call when they stop trusting it.

01Why the spreadsheets won, and what to keep

It is tempting to cast the spreadsheets as the villain. They were not. They won because they asked nothing of anyone: no procurement cycle, no ticket queue, no waiting on a developer to add a column, so when a customer needed something odd at 4pm someone had a workaround by quarter past. Any replacement that loses that quality loses the team. Before designing anything, we wrote down what the spreadsheets did well and treated it as a requirement to preserve:

• Instant change: a person close to the work could adjust it without raising a request
• Total visibility: the whole state of the day fit on one screen they already understood
• No gatekeepers: nobody needed permission to try a different way of working
• Forgiving structure: half-finished and messy data was allowed, not rejected

02Map the real workflow before you write code

We spent the first fortnight not building but watching. We sat with dispatchers, with sales, and with the two people everyone quietly relied on to repair the file when it broke. The documented process and the real one had drifted years apart, and the real one was full of sensible improvisation that nobody had ever written down: colour codes that meant something, a tab that existed only to catch jobs in limbo, a phone call that always preceded a particular kind of booking. If we had built from the official version, we would have shipped something correct and useless.

The spreadsheet was not the system. It was where the team kept the system that lived in their heads.

03Start with the process that hurts most

We resisted the urge to replace everything at once and asked a blunt question instead: which single task causes the most rework and the most after-hours phone calls? For this team it was the daily allocation of jobs to vehicles, the exact place the double-booking had happened. We built that one workflow properly: a single view of the day's jobs and the fleet, allocations that could not silently collide, and a record of every change as it was made. We deliberately left the rest on spreadsheets. A narrow tool that is genuinely better earns more goodwill than a broad one that is merely adequate, and it gives you something real to learn from before you commit to the harder parts.

04Import the old data, and earn trust with it

Nothing kills adoption faster than asking people to re-key a decade of records, or worse, dropping them onto an empty screen that makes their history vanish. We wrote importers for the live spreadsheets and ran them daily, so the new tool held real, current work from the first login. The messy data was the point, not a nuisance: every malformed date and duplicated job was a question the old system had been silently swallowing, and surfacing those honestly did more for trust than hiding them ever could.

05Build for the team you have, not an idealised one

The strongest temptation in a project like this is to design the process the way it ought to be and then expect people to conform. We did the opposite. The software modelled the team's actual behaviour, awkward exceptions included, and only nudged towards a cleaner path where the nudge was obviously worth it. Where a rule would have blocked a legitimate edge case they handled every week, a regular customer who always booked late or a driver who covered two patches on a Friday, we let the action through and flagged it rather than forbidding it. Software that argues with the people using it loses, every single time.

If the tool and the team disagree about how the work is done, the team is usually right.

06Make adoption part of the build

Change management was not a phase bolted on at the end; it was a constraint on the design from the start. We ran the new tool alongside the spreadsheets for weeks, until people chose it on their own, rather than flipping everyone over on a fixed date and hoping. Nobody was told to stop using the file. The things that actually moved adoption were unglamorous:

• We trained the informal experts first and let them champion the tool to their peers
• We kept an audit trail, so 'who changed this' finally had an answer the team came to value more than any new feature
• We shipped small fixes within hours, so requests felt heard rather than filed away
• We judged success by whether people stopped reaching for the old file, not by counting features

Months in, the change that mattered was not on any roadmap. The double-bookings that started the project stopped. The morning allocation that used to eat a frazzled hour settled into a few quiet minutes, and when something did go wrong, the audit trail meant the conversation was about fixing it rather than finding someone to blame. The team stopped reaching for the old file, which is the only adoption metric we have ever fully trusted.