Free tool
Four vans, four bookings, one problem
Van 3 is in for a service on days 4 to 6. Add bookings and watch where they land - then see what a system that stores "4 vans" as a number would have done with the same requests.
Day 1
Day 2
Day 3
Day 4
Day 5
Day 6
Day 7
Day 8
Day 9
Day 10
Van 1
Van 2
Van 3
Van 4
Solid = booked · dashed = in for a service · empty = free
Add a booking
Being straight about this page. Counting is not wrong by itself: with
identical, always-available vans, counting each day's overlaps gives the same answer as
assigning them. The gap opens when a unit is off the road, which a fleet-size number
cannot express. And this grid is a model of that one rule, not the booking engine -
the real one works from your data and also handles turnaround time, pickup and
drop-off times and locations. The demo sites run that.
Questions
Not by itself, and it is worth being precise. If every van is identical and always available, counting the overlaps on each day gives exactly the same answer as assigning vans: the number you need is the busiest day. The gap opens the moment a unit is not available - a service, a damaged door, one van out on a long-term hire. A single fleet-size number has nowhere to put that, so it keeps selling the van that is on a ramp.
Every unit is a row of its own, so a booking is given a specific van and a service is booked against one too. Availability is then answered from what is actually free. The real engine also handles what this page leaves out: turnaround time between hires, pickup and drop-off times, and locations.
No, and saying otherwise would be easy to disprove. The engine works from your database and your settings; this page runs a small model of one rule so you can try it without an account. The demo sites run the real thing.
Block that unit for the days it is off the road, and the bookings sitting on it are the ones to move - by name, rather than by hunting through a diary. That is the practical reason to track units rather than a total.