Your Excursion Desk Runs on a Spreadsheet: A Better Way to Take Resort Activity Bookings

Somewhere on your property right now, there is a spreadsheet that decides who gets on the sunset cruise. It has a tab per venue, a column per departure, and a row of names typed in by whoever answered the phone. It is open on the excursion desk’s computer, on a laptop at the dive shop, and — this is the part that matters — in two of those places at the same time. Which is how seat 12 got sold twice last Tuesday, and why two couples in nice clothes stood on the jetty at 17:40 doing arithmetic that didn’t work out.

Nobody chose this system. It accreted. And because every individual failure looks like a one-off — a typo, a busy afternoon, a version mix-up — the spreadsheet keeps its job for another season. So before talking about anything better: here is exactly what the spreadsheet gets wrong. None of it is anyone’s fault and all of it is structural.

How the spreadsheet got the job

The excursion desk’s spreadsheet is a reasonable answer to a real question: five or ten venues — the dive center, the spa, the cruise, the sandbank picnic, the kids’ club — each with limited capacity, each taking bookings from three directions at once. Guests ask at the desk, call reception, and stop staff on the beach. Something has to hold the answer to “is there space on Thursday?” and a grid of names in Excel is an answer.

It’s also the cheapest possible answer, it needs no training, and every property already has it. That’s the case for the spreadsheet, and it’s not nothing. The problem is what it costs once volume arrives — and the costs hide in five distinct places.

The failure modes, named

One truth, many editors. The file lives on a shared drive, or worse, gets emailed around. The excursion desk has one copy open, the dive shop another. Two edits land in whichever order the save button was hit, and the second one silently wins. Every double-booking story starts here: not with carelessness, but with two people being right about two different versions of the file.

Capacity is a formula somebody broke. The cruise takes twenty-two guests, so someone wrote a cell that counts the names and turns red at twenty-two. Then a row got inserted above the range, or a name went into the wrong column, and the formula has been quietly counting nineteen of the twenty-three actual bookings since March. The spreadsheet doesn’t know the boat’s capacity — it knows a formula, and formulas don’t complain when they’re wrong.

The desk is the only door. A guest who wants to book the reef trip has to find the desk while it’s staffed, or call reception, who writes a note, which becomes a row later — maybe. Every booking passes through a human retyping step, which means every booking waits for that human and inherits their typos. Evening and early-morning intent — precisely when guests plan tomorrow — goes unserved because the door is closed.

Declines vanish. When the cruise is full, the guest hears “sorry, fully booked” and the interaction evaporates. No record, no waitlist, no count of turned-away demand. At the end of the season you know what you sold, but you have no idea what you could have sold — which is exactly the number you’d need to decide whether a second departure pays for itself.

The evening reconciliation ritual. Someone — often the person who should be going home — cross-checks the tabs against the reception notebook and the dive shop’s WhatsApp messages, hunting for the booking that exists in one place and not the others. The ritual works, mostly. It’s also an unpaid hour a day spent compensating for a filing system, and it’s the first thing skipped on the busiest days, which are the days it’s needed most.

If you recognize three or more of those, the diagnosis is done. The spreadsheet isn’t badly run — it’s structurally incapable of being the single source of truth it’s pretending to be.

What a booking board actually changes

The alternative isn’t an enterprise reservations suite. It’s a small, specific change of shape: bookings become requests that flow to the venue, and the venue confirms or declines from one board that everyone reads and nobody has to reconcile.

Here’s the worked example, because the abstraction hides how little ceremony is involved. A guest decides at breakfast they want Thursday’s sunset cruise. They open the cruise’s page from their phone, pick the departure, and send a request. On the activity bookings board, that request appears for the venue with the capacity count right beside it — booked seats against the boat’s limit, counted from the bookings themselves, not from a formula someone has to maintain. The venue taps confirm, and the guest has their answer. If the boat is full, the venue taps decline, and that decline is recorded — turned-away demand finally becomes a number you can read at the end of the month.

Notice what disappeared. There’s no retyping step, so there’s nothing to mistype. There’s no second copy of the file, so there’s no version to lose the race. The desk stops being the only door, so booking intent at 21:30 lands as a request instead of evaporating. And “is there space Thursday?” stops being a question for whoever has the freshest copy — the count on the board is the truth, because the bookings live where the count is.

The evening reconciliation ritual goes with them. There is nothing to reconcile when there was only ever one list — the hour at the end of the day comes back, and it comes back first on the busiest days, which is where the spreadsheet used to charge its highest rate.

The guest who never opens their phone

The fair objection: “half my guests won’t book anything on a phone, and honeymooners don’t want to.” Correct — and it’s why the request flow can’t be the only flow.

So the front desk can book on a guest’s behalf. Guest mentions the reef trip at breakfast; the staff member puts the booking straight onto the same board against the same capacity count, attached to the same guest. One system of record either way — the phone-comfortable guest and the tell-a-human guest land in the same list, and the venue confirms both the same way. The board replaces the spreadsheet, not the conversation.

For guests who do use their phone, entry costs nothing: they scan the card in their villa and the page opens in the browser — no app to install, no account to create. That guest page is the property’s whole guest surface, so it also offers a ride request alongside the venues. Most properties start staff-side with on-behalf bookings and let guest self-service grow from there.

What this doesn’t ask of you

Venues need a phone or any browser, not new hardware. Guests need nothing installed. And the booking board runs without dispatch — if you never move a single guest in a vehicle, the request-and-confirm flow neither knows nor cares. It’s the same board-not-paper shape as tracking villa turnover on a readiness board instead of a radio check — the truth moves from a document someone maintains to a board that maintains itself.

This is the lane we built Resort Buggy into: it started with on-demand ride dispatch for spread-out properties, and the activity board runs on the same per-villa platform — each piece works without the other, so the excursion desk can come first and the rest can wait until it earns its way in.

The test costs you twenty minutes: book a demo, bring your actual venue list and your worst double-booking story, and we’ll walk the request-to-confirm flow on a board seeded to look like your Thursday. If your spreadsheet has never sold the same seat twice, keep it — genuinely. If it has, you already know it will again.