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.
Top comments (0)