Knowing what you have
A count tells you how many. It cannot tell you which one, or which side of the island it is standing on this morning.
A guest books two kayaks for Saturday at the north shop. Another books three at the south shop nine minutes later. Both bookings were valid against the number each screen was showing, and both screens were showing the same twelve kayaks.
Four of those twelve went to the south shop in a trailer on Tuesday, and the transfer was a text message. Two are in the workshop with damaged skegs. The real availability at the north shop on Saturday morning is four, and two people have sold seven.
Nobody made a mistake in that sequence. The system was asked a question it has no way to answer.
Availability held as a number can say twelve. It cannot say which twelve, where each one is standing, which has a cracked hull, which is promised to a delivery at eight and which came back last night and has not been looked at.
Every one of those facts belongs to an individual unit. A count is what you get when the software was built to sell seats at a time slot, where the thing being sold stops existing at the end of the slot and never has a location or a history.
A rental unit has both. That is the whole difference between the two categories of software, and a double booking across sites is the cheapest way to discover it.
Most operations solve this by holding stock back. Two kayaks at each site are never sold, as insurance against the number being wrong.
On a twelve-unit pool that is a sixth of the fleet earning nothing all season, and it is a buffer sized by anxiety rather than by data. The buffer also hides the underlying error, so the count stays wrong and nobody finds out how wrong.
The second workaround is worse: a phone call between sites before every booking is confirmed. It works, it does not scale past a quiet week, and it stops entirely the moment the person who answers the phone is on a delivery.
Give every unit an identity. A number on a sticker is enough, and it has to be the same number the booking, the transfer and the repair log all use.
Record transfers as events with a date and a destination, in whatever you already have. The failure here is that a unit moved and nothing was written down.
Run one availability board across all sites rather than one per site, and give the sites read access to each other. Most double bookings across locations are two people who could not see one another.
Reservations land against individual units rather than against a pool, and the same unit cannot be sold twice on the same morning by two people in two locations.
Each unit carries its location, its condition and its service state, and a transfer between sites is recorded rather than remembered. Stock idle at one location is visible to a site turning customers away, which is the other half of the same problem.
Multi-location inventory covers the mechanics and the limits.
Eight bikes, two locations, one in the workshop. Book against each model and see which one can tell you which bike the customer is getting.
Where units are commodity and identical, where they never leave the building, and where you hold far more than you sell, a count is cheaper to run and there is no reason to move.
The moment either identity or location matters, and a delivery to an address makes both matter, the count starts costing you units and guests.
Because availability is held as a count rather than as a set of individual units. A number can say twelve kayaks. It cannot say which twelve, where each one is standing after a transfer, which is in the workshop, and which is promised to a delivery at eight in the morning.
Two people at two sites drawing from the same number both take valid bookings, and the second guest finds out at the counter. Holding stock against individual units, with a location and a service state on each, removes the failure rather than buffering it.
No. Adding a location costs nothing, and there are no seat licences. The only charge is 4.5% added to each reservation and paid by your customer at checkout.
Yes, as one live view of every unit with transfers recorded, so stock idle at one site can fill demand at another.
FareHarbor models availability as a count against a time slot, which is what a tour product needs. It is honest about being a tour product; the rental page it publishes covers inventory blocks and cleaning time rather than per-unit location and transfers.
A demo takes six fields and someone who understands rental operations calls you back. Where Bodhisys is the wrong fit you will hear it on that call rather than after three meetings.
