Details in this account are generalised and figures are omitted where they would identify the client. The value is in the decisions rather than the specifics.
The situation
A regional logistics operator running a mixed fleet, working for a small number of substantial customers plus a long tail of occasional ones.
The business ran on a spreadsheet. Jobs were entered when booked, updated as they progressed, and used to produce invoices at the end of each month. It had grown over about eight years and contained several tabs whose purpose only one person could explain.
The trigger was not a failure. It was that the person who maintained it was approaching retirement, and nobody else could operate it confidently.
What the discovery found
Three things that shaped everything afterwards.
The central record was a movement, not a customer. A job had a collection point, a delivery point, a vehicle, a driver and a date. The customer who paid was frequently not the party at either end, and sometimes an agent was involved as well.
Standard CRM products model a company with contacts and opportunities. Forcing this shape into that structure would have required a translation that nobody in the business would have recognised.
The pricing had rules nobody had written down. Rates varied by customer, by route, by vehicle type and by whether it was a return leg. Several long-standing customers had arrangements that existed only in one person's memory.
Capturing these took two days of sitting with them and going through past invoices asking "why is this one different?". That exercise was the most valuable part of the project, and it produced a written rate structure the business had never had.
Invoicing at month end was costing them cash. Work completed on the third of the month waited four weeks to be invoiced. Nobody had questioned it because that was how the spreadsheet worked.
What we built
A system organised around jobs, with vehicles, drivers and the parties involved attached to each.
The first release covered: booking a job, allocating it, recording completion, calculating the charge from the rate rules, and producing an invoice. Nothing else.
The pricing rules were encoded, which meant a job's charge was calculated rather than looked up. Where a customer had an arrangement, it was recorded as a rule with a start date rather than as something somebody knew.
Invoices went out on completion rather than monthly, which changed the cash profile materially and was the single change the directors noticed most.
What we deliberately did not build
Three things were requested and postponed.
Vehicle tracking integration. Genuinely useful and not necessary for the first release. Adding it would have extended the project by weeks before anybody had used anything.
A customer portal. Requested early. We argued for waiting until the internal data was trustworthy, on the grounds that showing customers unreliable information is worse than not showing them anything. It was built later, once the job records had been accurate for six months.
Elaborate reporting. The business asked for a dashboard. We built three reports they had described actually using, and left the rest until they had opinions based on real data.
Most of the value in this project came from writing down pricing rules that had lived in one person's head. The software was the reason to have the conversation.
What went well
Parallel running for six weeks. Every job was entered in both the spreadsheet and the new system, and the invoices compared. Several differences emerged, and in two cases the spreadsheet had been wrong for some time.
Involving the office staff in the design. The people entering jobs shaped the entry screen, and as a result it is quick — a routine job takes seconds. That is why it gets used.
Releasing narrow. Something useful was in daily use within a few months, which meant the later requests were informed by experience rather than imagination.
What we would do differently
We underestimated the historical data. Bringing eight years of jobs across took longer than planned, because the spreadsheet had changed shape twice and older rows had columns meaning different things. We should have profiled the data properly in week one — the lesson in migrating without losing history.
We should have addressed invoicing timing separately and first. Moving from monthly to on-completion invoicing did not need a new system. It could have been done in the spreadsheet, delivering the cash benefit months earlier.
That is a general lesson: some of what a system project delivers is process change that did not require the system.
Where it stands
The system is in daily use, the pricing rules are documented rather than remembered, and the retirement that prompted the project happened without incident.
If your business runs on a spreadsheet that one person understands, our CRM team works with UK companies on exactly this. Start a conversation.