From Spreadsheets to Software: A Digital Transformation Case Study

The Starting Point: 14 Spreadsheets, One Business

The client is a 35-person freight and logistics company based in the Midlands, specialising in time-critical B2B freight movements across the UK. They have been operating for 12 years and have grown organically from a 5-person operation to a team of 35 — but the systems that served them at five people were still in use at 35.

Their operation ran on 14 spreadsheets:

• Quote Tracker: All active and historical quotes, with status, value, customer, and assigned operations contact
• Job Schedule (current week): All active jobs for the week, with collection and delivery details, driver assigned, and status
• Job Schedule (next week): A separate sheet because the current week sheet would get too large
• Driver Allocation: Which driver is on which job, their availability, and hours tracking
• Subcontractor Register: Third-party hauliers used for overflow capacity, with rates and availability notes
• Customer Contact List: Key contacts at each customer, updated manually by different team members
• Pricing Matrix: Rate cards by lane, weight, and customer tier
• Invoice Tracker: Jobs that had been invoiced, payment status, and outstanding amounts
• POD (Proof of Delivery) Log: Tracking which jobs had PODs received and filed
• Vehicle Maintenance Log: MOT dates, service due dates, and defect records for the fleet
• Driver Compliance: Licence expiry, CPC training, digital tachograph records
• Claims Register: Damage and loss claims with status and financial impact
• Customer Reporting: Monthly usage and performance stats compiled manually for each major customer
• Monthly KPI Sheet: Manually compiled management reporting — revenue, volumes, margins, on-time performance

Each spreadsheet was kept in a shared folder. Multiple people edited them simultaneously — which Google Sheets can handle to a point, but which caused constant conflicts when two operations coordinators were updating job status at the same time. The job schedule sheets were the worst: by Thursday of each week, the current week sheet was an unnavigable mass of highlighted cells, crossed-out entries, and manual notes in cells.

The Problems These Spreadsheets Created

What Was Built: The Custom Operations Platform

After a two-week discovery process (interviews with each team member, process mapping, and a review of the spreadsheets), the scope for the custom platform was defined around four core modules:

Technology Stack

The Build and Rollout Timeline

The project ran over six months in total — four months of build and two months of phased rollout.

The Results

Lessons Learned

• Discovery is worth doing properly. The two-week discovery phase added upfront time and cost but prevented scope changes during build. Every requirement we agreed in discovery held; every change request that came in during build was from something not covered in discovery. They were handled quickly because the underlying architecture was designed for them.
• Get end users testing early. The operations coordinators who tested the job management module at Week 6 found issues that the development team would never have found. They tested with real scenarios from their actual working day. Their feedback improved the product materially before it ever went near a customer.
• Phase rollouts are non-negotiable for operations systems. Running operations and spreadsheets in parallel for two weeks felt inefficient, but it provided a safety net that prevented any business disruption. Two issues found during parallel running would have been significant problems without it.
• The driver app was underestimated. React Native development across iOS and Android added complexity that was slightly underestimated in the initial scope. Two additional weeks were needed to resolve device-specific bugs on older Android models used by some drivers. Budget contingency (held at 15% of project cost) absorbed this without impact on delivery.
• The biggest ROI driver was not expected. We expected the biggest benefit to be administration time reduction. The biggest actual benefit was the ability to take on more revenue without more headcount — the 40% revenue growth was enabled entirely by the platform removing the operational bottleneck. This was not in the original business case because the client had not connected the spreadsheet problem to the growth constraint until we pointed it out in discovery.

When Does Excel Stop Being Enough?

Excel and Google Sheets are genuinely powerful tools. They are flexible, accessible, and require no technical expertise to use. The question is not whether spreadsheets are good — it is whether they are still the right tool for the job at your current scale and complexity.

The tipping point comes when one or more of these conditions are true:

• Multiple people need to edit the same data simultaneously and conflicts are causing errors
• Data in the spreadsheet needs to be available in real time to people who are not at a computer (drivers, field staff, customers)
• The spreadsheet has become the only way to run a process — and the person who maintains it is a single point of failure
• You are spending significant staff hours each week maintaining, reconciling, or correcting the spreadsheet rather than using the data in it
• The spreadsheet cannot do something the business needs — like send an automated notification, integrate with an accounting system, or show a customer their current status
• The business could grow faster if the operational process the spreadsheet manages could handle more volume

If two or more of these apply, the ROI case for custom software is almost certainly positive. The question is usually not whether to build — it is what to build, in what order, and how to phase it to minimise risk.

Related Articles