Knowing what you have
The spreadsheet is right on Friday night and wrong by Saturday afternoon, and everybody in the building knows it.
The booking platform holds reservations. The spreadsheet holds what is true: which units are in the workshop, which went to the other site, which is being held for the family who come every August, and which was written off in May and never removed from the catalogue.
It exists because the booking platform has nowhere to put any of that. It is a rational response to a gap, and it works until the operation gets busy enough that the person maintaining it is also the person loading a van.
The spreadsheet is updated by a person, after the event, from memory. A unit comes back damaged at 11:40 and the row changes at some point in the evening if the day allows it.
On a quiet day the lag is invisible. On a peak day it runs at four to six hours, which means the sheet describes this morning and the yard is living in this afternoon. Anybody making a promise to a guest from that sheet is quoting history.
The deeper problem is that there are now two sources of truth and neither one wins. The booking system says a unit is available and the sheet says it is not, and the tiebreaker is whoever is standing closest to the yard.
The visible cost is the guest who arrives for a unit that does not exist, and the refund or the substitution that follows.
The invisible cost is bigger. Every unit that sits in the workshop unnoticed, every unit held back as a buffer against the sheet being wrong, and every hour of a Sunday spent reconciling counts is capacity you paid for and did not sell.
Ask how long the weekly reconciliation takes. Two hours a week across a twenty-week season is a working week of somebody's year spent restoring agreement between two documents.
Move the edit to the point of the event. The person who takes the unit out of service marks it, on their phone, at the moment they take it out of service. Latency is most of the error.
Have one sheet rather than one per site, and give it a column for location and a column for who last touched the row. A sheet nobody owns rots faster than a sheet somebody owns badly.
Delete written-off units rather than colouring them grey. Grey rows are the ones that get sold in July.
The state the spreadsheet holds belongs on the unit record: location, condition, service state, who has it and when it is due back. When that record is the same one the booking draws from, there is nothing left to reconcile.
That is the point of a single board. The reason operators keep a spreadsheet is that their platform cannot hold the facts a rental business runs on, and the fix is a platform that can rather than a better spreadsheet.
The nine stages, in order
Nine writes to one row. A platform that needs a second system for any of these stages needs somebody to keep the two of them agreeing.
Reservation 2511-003
Every stage writes one line here. Nothing is exported, reconciled, or keyed in a second time to make that true.
Running underneath all nine
The guest finds you on a site you own rather than through a reseller taking a commission on the way in. The pages that have to rank and the availability they show read from this record, so nothing is edited by hand to stay true.
One location, one person who sees every unit every day, and stock in the tens. Under those conditions the sheet and the yard stay in agreement and a platform migration is not worth your season.
Two locations, or delivery to addresses, and the arithmetic changes quickly.
Because it is updated by a person after the event, from memory, while the yard keeps moving. On a busy day the lag runs to several hours, so the sheet describes the morning while the operation is living in the afternoon.
It also creates a second source of truth beside the booking system, and the two disagree with no way to settle it. Holding location, condition and service state on the unit record the booking draws from removes both problems, because there is nothing left to reconcile.
Yes. Inventory comes across as individual units rather than as counts, and customers, future reservations and booking history import from FareHarbor, Peek Pro and Bike Rental Manager.
Days rather than months for a single-location operator. Longer with multiple locations and a large catalogue. There is no implementation fee and no migration charge.
No. The import runs alongside your existing platform until you switch over, and forward reservations taken up to that moment come across in a final sync.
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.
