A Google Sheets Booking System That Counts Who Actually Turned Up

Someone rings to book six places on Saturday’s second departure. You need an answer in about three seconds, and it has to be right.

That is the question a Google Sheets booking system is usually built to answer. It is also the easy one.

The hard question comes later. Six places were booked. On the day nobody came. At the end of the month you pay commission, plan your staffing and judge your season on one of those two numbers. Most sheets only hold the first.

Every booking is two events

A booking is a promise. Boarding is the fact.

Between the two sits everything that actually happens in an operation. Cancellations. No-shows. People who pay on the day and people who never do.

If your sheet records only the promise, every figure downstream is a forecast dressed as a result. You are not measuring your business. You are measuring your intentions.

So the system needs both records against the same reservation. What was agreed, and what happened. In one table.

What a Google Sheets booking system has to answer in three seconds

One of these we have built runs a boat tour operation. Sixty places on the boat, three departures a day, up to forty bookings on a busy day, and thousands across a year.

On the phone, the only number that matters is places left. For that date, on that departure.

The reliable way to have that number is to never keep it.

Do not maintain a count of places remaining. Count the places taken and subtract them from the boat. A calendar view sitting over the bookings table then shows open places for every departure, day by day. Nobody maintains it, because it is not a record. It is a calculation.

A stored count is a second version of the truth. It drifts the first time somebody is busy. A calculated one cannot drift, because there is nothing to forget.

This is also why bookings are counted in places rather than in bookings. A reservation for six takes six. Count reservations and a full boat looks half empty.

The screen at the door is a view, not a second list

Boarding is a different job from booking, so it needs a different screen.

At the gangway nobody wants the whole season. They want one date, one departure, the names on it, the number of places each name is bringing, and whether the money has arrived.

So the check-in screen is a tab in the same file showing exactly that, one departure at a time. Change the date and everything on it changes.

That has a consequence worth understanding before you build anything. A window can show you Saturday. It cannot remember what Friday looked like.

Which means the check-in screen can never be the source of a total. Ask it to feed your monthly figures and you are asking a window to keep records. The bookings table is the only thing that accumulates, and every number you report has to be built from it.

The two columns that write backwards

Everything on that check-in screen is read-only, with two exceptions. Whether they have paid, and whether they have arrived. Both are yes or no against the whole booking, and the places on it are counted from that. Both are typed at the door, by whoever is standing there, and both have to end up on the right row of the bookings table.

That part is not free. Each editable column needs its own script, watching for the edit and writing it back. Two editable columns, two scripts.

Worth knowing where that cost sits, because it is the one genuinely engineered part of a booking sheet. Everything else is formulas.

A deposit column was added later and shows the difference clearly. It is entered in the bookings table and appears on the check-in screen for reference. Nothing types into it at the door, so it needs no script.

The rule that comes out of this is simple. Decide which fields get edited away from the desk, keep that list short, and let everything else be read-only.

What we deliberately left out

A form front end was quoted and then removed before any work started.

Forms earn their place when something has to happen the moment one is submitted. A confirmation email, a notification, a record created somewhere else. Nothing needed to happen here, so a form would only have added a second place to look. Bookings are typed straight into the next empty row of the table instead, with thousands of rows prepared in advance.

Confirmation numbers went the same way. They could have been generated from the timestamp, the departure and the party size, so that the number itself described the booking. They are sequential instead. A number that a person can read, repeat and find beats a number that encodes things nobody needs to decode.

Neither decision made the system cleverer. Both made it quicker to use, every day, by people who did not build it.

Pay on the arrival, not the booking

The ranking of salespeople was built first on guests booked. It was changed to guests checked in.

That is a small change to write and a large change to the business. Booked guests reward the person who takes the reservation. Checked-in guests reward the person whose reservations turn into people on a boat. Those are not the same skill, and paying for the first while needing the second is a quiet, expensive mistake.

Nothing structural had to move. The figures pointed at a different column of the same table. What it did require was a way to record arrivals at the door, which is what the second script was for.

Two other things mattered in that build. The operation had thirteen salespeople and expected to reach a thousand names, so the ranking sheets were built to handle people who did not exist yet and months that had not happened. And they calculate. Nothing is typed into them, which is why they can be trusted, and why they carry a monthly top twenty-five without anyone maintaining a list.

Both were then locked. Not against dishonesty, against a Tuesday. In a shared file, somebody working quickly clears a column and a season of figures goes with it. That very nearly happened on the check-in screen before the protections went on.

Where this approach stops working

Three limits, and they are all real.

Years of volume. Thousands of bookings a year is comfortable. Several years of them in one file is not, and the load shows. The answer we give is a clean file each season, with the old one archived. It is not elegant. It works, and it costs nothing.

Editing everything from everywhere. Every field that can be edited away from the bookings table needs its own write-back. Ask for all of them and the cross-sheet updates start taking their time, and the limitations pile up faster than the features. We have said exactly that when asked to go further, and named the point where an application built for the job is the better purchase.

Everyone holding the same pen. A spreadsheet gives every person with the link the same power over it. Protection helps and does not solve it. If your operation has enough hands in the file that you are relying on locks, you are already paying for something a booking system would give you by design.

Is this your problem?

Four questions you can answer this afternoon, without hiring anybody.

Can you say how many places are left on a specific departure, from one screen, while the customer is still on the phone? If it takes two screens or a phone call to somebody else, the availability is not calculated.

Is the number of places left something a person maintains? If anybody ever types it, it is already wrong somewhere.

If you pay on performance, are you paying on what was booked or on what arrived? And can you show, in one place, where either figure came from?

Does the person at the door write into the same file the office books into? If arrivals live on a clipboard, or in a second sheet, or in somebody’s head until Friday, your results and your promises will never reconcile.

When a spreadsheet is the right answer, and when it is not

A Google Sheets booking system suits an operation with fixed capacity, a manageable number of departures, and a small team who all know the business. It is quick to change, it costs nothing to run, and you own it outright.

It stops suiting you when bookings come in faster than people can type them, when customers need to book themselves, or when everybody wants to edit everything from wherever they are standing.

If that is where you are, dedicated software is the better answer and we will say so. If it is not, and you are running a fixed number of places against a fixed number of departures, we can help. Tell us how your operation actually works, on paper or in the sheet that has stopped keeping up, and we will tell you what it would take.