The Decision That Shaped a Three-Week Rental Build
Three plausible options were on the table and two of them would have taken months. What made the difference was deciding where the truth lived.
What the measurement left us with
The week of counting had produced one finding that changed the project: machines physically standing in the yard were being reported as unavailable, often enough to explain both the double-bookings and a share of the refusals.
That is a sentence about data rather than about people. Had the count come out near zero, the honest conclusion would have been that staff were overloaded and the answer was capacity or routing. It did not, so the answer was somewhere in how availability was recorded.
Three options followed. Two of them were months.
The three options
| Option | Time | Why it was rejected or chosen |
|---|---|---|
| Replace the rental system | Months | Fixes one field by migrating everything, during the season |
| Put a model over the spreadsheets | Weeks | Answers the wrong data faster and less traceably |
| Make one record authoritative, give assets real states | 3 weeks | Fixes the specific thing that was wrong |
The first is the option most often proposed when a data model is at fault, and it is usually the wrong scale of response. A replacement migrates history, retrains everyone, and runs two half-trusted systems in parallel, all to correct one field. In a seasonal business, doing that during the months when the operation is already straining is not a detail.
The second is the option that would have been easiest to sell. A model reading the existing sheets and answering availability questions demos well and fails in the exact way the measurement had already predicted: the data says a machine is unavailable while it stands in the yard, and the model repeats that with more confidence and less traceability than the spreadsheet had.
Why the model did not get that job
There is a general rule underneath this particular choice, and it is worth separating from the specifics.
An availability check has to return the same answer to the same question every time, and it has to be explainable afterwards when a customer asks why they were refused. A probabilistic answer to a deterministic question is a defect, and no improvement in the model changes that.
So the model got exactly one job in the finished system: reading enquiries that arrive as free text at eleven at night, naming a machine in the customer's own words with dates in a format no field expects. That is genuinely hard for a rule and genuinely easy for a model. The split is set out in full in where the four hours go.
What the chosen design changed
Two things, and the second mattered more.
Availability stopped being one true-or-false field and became seven explicit states, so a machine returned but awaiting inspection, a machine in transit, and a machine reserved but unconfirmed all stopped reporting as free.
Then one record became authoritative about what is reserved, and the check moved to the moment of commitment rather than the moment of enquiry. That second change is what ended the double-bookings, because the conflicts had been living in the window between somebody looking at a shared sheet and somebody promising a machine.
Neither change is exotic. Neither needed new technology. Both needed a decision that somebody had to make and nobody had made.
The cost that appears in no proposal
Making one record authoritative means somebody has to stop keeping their own copy.
Every operation of this kind has one or two people running a private spreadsheet, and they are not being obstructive. They started keeping it because at some point the official system was wrong and their sheet was right, and it has been quietly holding the business together ever since.
Asking them to trust a system that previously let them down is the real work, and it lands very differently depending on whether their objection was listened to first. This is the part that most nearly derailed the project. It appears in no proposal we have ever seen, including our own earlier ones, and it is why the source-of-truth decision is now named explicitly at the start rather than discovered in week two.
What it produced
Booking-to-dispatch went from 4 hours to 3 minutes. Double-bookings were eliminated. Peak-season capacity rose 2.5x with the team that was already there, and the build fit in 3 weeks. The full set is on the case page.
The three weeks are a consequence of the decision rather than of speed. The two rejected options were not slower versions of the same project; they were different projects, and one of them would have been finished around the time the season ended.
The transferable part
Before agreeing to anything, find the fact that two of your systems disagree about, and decide which one wins.
That decision costs nothing, takes an afternoon, and determines the size of every project that follows it. The measurement that surfaces it is described in the week before, and it is the same reason contradictory data is the one kind you should not automate around until the question has an answer.
01Why not replace the rental software, since the data model was the problem?+
Because the data model was wrong in one specific way rather than wrong throughout, and replacing a system to fix one field is a months-long project carrying risks that have nothing to do with the original problem. A replacement means migrating history, retraining everybody, and running two systems in parallel for a period during which both are half-trusted. It also puts the whole operation on a new tool during the exact months when it is already struggling, and in a seasonal business the timing of that is not a detail. The narrower fix was to leave the existing system holding what it held correctly and to make one record authoritative about the single thing it was getting wrong, which is reservations against assets. That is weeks of work instead of months, and it leaves the option of replacing the system later open rather than spending it now.
02What was wrong with putting a language model over the existing spreadsheets?+
It would have answered the availability question faster and just as wrongly, which is a worse outcome than answering it slowly. The measurement had already established that the underlying data reported machines as unavailable while they stood in the yard, and a model reading that data reproduces the error with more confidence and less traceability. There is also a subtler problem worth naming, because it recurs in most projects where a model is proposed as a shortcut: an availability check must return the same answer to the same question every time, and must be explainable afterwards when a customer asks why they were refused. A probabilistic answer to a deterministic question is a defect regardless of how good the model is. The model earned a place in the finished system, but at the front door on unstructured enquiries, which is work a rule genuinely cannot do.
03What did the chosen design actually change?+
Two things, and the second is the one that mattered. First, availability stopped being a single true-or-false field and became an explicit set of states, so that a machine returned but awaiting inspection, a machine in transit, and a machine reserved but unconfirmed all stopped reporting as available. Second, one record became authoritative about what is reserved, and the availability check moved to the moment of commitment rather than the moment of enquiry. The second change is what eliminated double-bookings, because the conflicts were living in the window between someone looking at a shared sheet and someone promising a machine. Neither change is exotic and neither required new technology. They required a decision that somebody had to make and that nobody had made, which is the usual shape of these projects.
04What did that decision cost?+
Somebody had to stop keeping their own copy, and that is a political cost rather than a technical one. In practice every operation of this kind has one or two people running a private spreadsheet, usually because at some point the official system was wrong and their sheet was right. Those people are not being obstructive; they are holding the workaround that has been keeping the business functional. Making one record authoritative means asking them to trust a system that has previously let them down, and that request lands very differently depending on whether their objection has been listened to first. This is the part of the project that most nearly derailed it, it appears in no proposal we have ever seen including our own early ones, and it is why we now name the source-of-truth decision explicitly at the start rather than discovering it in week two.
