The Week Before: What We Measured at a Rental Firm
Before touching anything at an equipment rental firm we spent a week measuring. Two of the four numbers we expected to matter turned out not to.
Nobody knows their own numbers
The rental operator we worked with could describe the problem precisely. Bookings were handled by hand, availability lived in spreadsheets, contracts were assembled one at a time, and drivers were arranged by phone. Peak season meant lost bookings and double-bookings.
Every part of that description turned out to be true. None of it was a measurement.
So the first week of the project produced no software. It produced a count, taken from the systems the business already had, of how big each part of the problem actually was. That week is the reason the build took three and not six, because it removed two things from scope that everyone had assumed were central.
What we pulled
Two timestamps per booking, across a full peak month: when the enquiry arrived, and when dispatch was confirmed.
Then three counts that are not timestamps.
- Enquiries that arrived outside working hours
- Enquiries that were never answered at all
- Occasions when a machine physically present in the yard was reported unavailable
None of this needed new instrumentation. It needed somebody to export what was already recorded and count it without flinching.
The average was the least useful number
Booking-to-dispatch averaged around four hours, which is the number that ended up in every later description of the project including ours.
It was also the number that mattered least during scoping.
| What we looked at | What it told us |
|---|---|
| Average time to dispatch | The problem exists |
| Distribution of that time | Where the money is |
| Share arriving out of hours | Why the tail is long |
| Enquiries never answered | What was being lost silently |
| Yard-present but unavailable | Whether the data model was at fault |
Most bookings moved at a reasonable pace. A minority waited far longer than the average suggested, and that minority was where customers stopped waiting and called a competitor. An improvement to the average would have read well in a report and changed nothing commercially, because the customers who left were never in the middle of the distribution.
This generalises past rental. The average is the number most likely to survive into a proposal and least likely to identify the constraint.
Two things we expected to matter and dropped
Weekly booking volume was the first. The annual figure flattened a season that earns most of the year in a few weeks, and scoping against the annual number would have sized the system for a load it never sees when it matters.
The second was contract preparation time. It was real, it was tedious, and it was not the constraint. Document assembly is genuinely slow work, and automating it saves exactly the minutes it takes, which is a small share of the four hours. It stayed in the build because it is cheap once the rest exists. It stopped being the reason for the build.
Removing both from the critical path is most of why the project fit into 3 weeks.
The number that decided the shape
The count of machines standing in the yard and reported unavailable was the one that changed the design.
Had that count been near zero, the honest conclusion would have been that staff were overloaded and the fix was capacity or routing. It was not near zero. The availability data itself was wrong often enough to explain both the double-bookings and a share of the refusals, which pointed at the model rather than at the people.
That is what made the build mostly a data-modelling job with a language model at the front door rather than the reverse, and where the four hours go sets out the resulting split between rules and model in detail.
What happened next
The rebuild took 3 weeks. Booking-to-dispatch went from 4 hours to 3 minutes, double-bookings were eliminated completely, and peak-season capacity rose 2.5x with the team that was already there. The case page carries the full set.
The capacity figure is the one that pays for the project, and it traces directly back to the measurement week. The refused bookings were countable before anything was built, which is why the business case did not depend on believing a forecast.
If you want to run this week yourself
You do not need us to do it, and there is a reasonable argument that you should do it before talking to any vendor at all. Pull the two timestamps, count the three things, and look at the distribution rather than the average.
The measurement is the first stage of the audit we run before agreeing to build anything, and the numbers it produces are the ones that make the four questions that break most ROI claims answerable rather than rhetorical.
If the tail is thin and nothing was being turned away, the answer is that this is not a project worth doing. We would rather tell you that in week one than in month three.
01Why measure for a week instead of just asking the team?+
Because people are accurate about what a task feels like and unreliable about how often it happens and how long it waits. Ask a coordinator how long a booking takes and you get the duration of their own part of it, which is genuinely short, plus an impression of the waiting, which is genuinely long but not something anyone tracks. Neither answer is dishonest and neither is usable for a business case. Timestamps from the systems are different in kind: they show the distribution rather than the impression, they cover the nights and weekends nobody remembers, and they include the enquiries that were never answered, which by definition nobody can recall. The week is also short enough to be affordable and long enough to catch the shape. We would rather spend a week finding out that a project is not worth doing than spend three weeks building the thing that was not the constraint.
02What exactly did you pull, in practical terms?+
Two timestamps per booking across a full peak month, taken from whatever systems already held them: when the enquiry arrived, and when dispatch was confirmed. Then three counts that are not timestamps at all. How many enquiries arrived outside working hours, because those are the ones that sit until morning and are invisible in any average that mixes them with the rest. How many enquiries received no response ever, which is the number nobody wants to look at and the one most likely to contain revenue. And how many times a machine physically present in the yard was reported as unavailable, which is the signal that the availability model rather than the staff is the problem. None of that requires new instrumentation. It requires somebody to export what is already recorded and count it honestly.
03Which of the numbers turned out not to matter?+
The average booking-to-dispatch time and the count of bookings per week. Both were the numbers everyone expected the case to rest on, and both turned out to be nearly useless on their own. The average hid the distribution: most bookings moved reasonably fast and a minority waited a very long time, and it was that minority where customers gave up and went elsewhere. Improving the average would have looked good in a report and changed nothing commercially. Volume was similarly misleading because the yearly figure flattened a season that does most of the earning in a few weeks. What decided the build was the shape of the tail during peak and the count of enquiries that were never answered. This is not specific to rental: the average is the number most likely to survive into a proposal and least likely to identify the constraint.
04What if the measurement says the project is not worth doing?+
Then we say so and do not build it, and that has to be a real possibility for the measurement to mean anything. The rule we work by is that if the audit cannot show a return, there is no build, and it exists because the alternative is a vendor whose diagnostic always concludes that its own product is required. Concretely for a rental operation, the case falls apart when the peak-month tail is thin and nothing was being turned away. In that situation the four hours between booking and dispatch are an irritation rather than a cost, the saved hours would not become capacity anyone sells, and the honest recommendation is to spend the money on something else. Turning that project down costs us a contract and keeps the diagnostic worth trusting, which is the only reason anyone lets us measure their operation in the first place.
