Booking management in Excel: how to build it, and where it breaks

It's Friday evening. You open the booking sheet while you're still on the phone, see Thursday 14:00 sitting empty, and confirm it out loud. You put the receiver down, look again, and there is already another name in that cell. A colleague typed it five minutes ago.

The reason this happens is not the one almost every guide gives — "Excel can't be edited by two people at once". It can. What it cannot do is arbitrate two people reaching for the same slot. This article builds a booking sheet that actually works — the column design and the overlap formula — then checks what happens when you share it, using Microsoft's own documentation, and ends with the point where a spreadsheet stops being the right place to take bookings.

For the wider set of scheduling problems solo operators and small teams run into, see the solo and small teams resource hub.

The columns you need, and the one decision to make first

Decide one thing before anything else: is a row a booking, or is a row a day? Everything else can be added later; this cannot.

A grid with times across the top and dates down the side is easy to read when it's printed and pinned to a wall. As data it is unusable — a whole booking lives inside one cell, so you cannot filter it, total it, or test it for overlaps. Keep one booking per row, stacked as a ledger, and every later job becomes a formula. If you still want the wall chart, generate it on a second sheet from the ledger.

Ten columns is enough to start. Adding more later is easy.

Column	Field	How to fill it
A	Booking ID	A serial number — what you quote back when someone calls
B	Taken at	When it was entered. Settles which of two entries came first
C	Customer	—
D	Contact	Phone or email
E	Service	Pick from a data-validation list
F	Staff	Keep the column even if you work alone
G	Starts	Date and time in one cell: 2026/8/18 10:00
H	Ends	Same. You can derive it from a duration
I	Status	Confirmed / cancelled / moved is enough
J	Overlap check	The formula in the next section

The one rule worth insisting on is that G and H hold a date and a time together in a single cell. Split them into a "date" column and a "start time" column and the comparison breaks on anything crossing midnight, and on the same clock time on different days. If you only want it to look tidy, set the display format to yyyy/m/d h:mm.

A formula that finds overlaps, ready to paste

Two bookings overlap under one condition, and it fits on a line: the other one starts before mine ends, and ends after mine starts. That is the whole test.

The part people get wrong is the equals sign. A booking that ends at 10:00 and one that starts at 10:00 do not overlap. Write the test with <= or >= and those two are flagged as a clash — which is exactly why "only the boundary times get coloured in" is the most common way this goes wrong.

With the columns above, put this in J2 and fill down.

It counts rows with the same staff member, an overlapping time, and a confirmed status. Your own row matches all three, so subtract one. Zero means no clash; anything higher is the number of bookings you are colliding with. Rows that aren't confirmed return blank, so cancelled bookings stop raising warnings.

Then colour it. Select A2:J1000, add a conditional formatting rule with the formula =$J2>0, and fill the row pale red. The 1,000-row limit is deliberate: whole-column references (F:F) make recalculation heavier as the sheet grows. When you outgrow it, widen the range or start a sheet per year.

At this point clashes between bookings already in the sheet are caught automatically, and the same ledger gives you per-staff counts and monthly totals through a pivot table. If you work alone and enter every booking yourself, this is genuinely enough.

"Excel can't be edited simultaneously" is no longer accurate

Most guides to spreadsheet booking say Excel cannot be edited by several people at once. A workbook on OneDrive or SharePoint can be co-authored. The problem sits somewhere narrower.

Microsoft's own documentation says that when the same cell is changed at the same time, the last change saved — by the save button or by AutoSave — is the one that "wins". The way it tells you to avoid conflicts is to assign each person their own area or sheet (source: Microsoft Support, "Collaborate on Excel workbooks at the same time with co-authoring", as of August 2026).

A booking sheet is the one use where that advice cannot be followed. Split it by staff member and Thursday 14:00 is still a single slot shared by everyone; split the staff and the room or the chair is still shared. When two people reach for it, what survives is not the correct entry — it is the one saved second.

The same page carries a second warning that tends to get skipped: changes made offline are not merged until you are back online. A booking typed on a phone between appointments joins the file whenever the signal returns, and by then the other entry has been made too.

None of this appears as a conflict dialog. It shows up the next morning as "the booking I entered yesterday is gone".

Share it the old way and conditional formatting locks up

Plenty of offices still run an .xlsx from a file server through Review → Share Workbook. That is an old feature that has been replaced by co-authoring, and its list of unsupported operations includes "adding or changing conditional formatting" (source: Microsoft Support, "About the shared workbook feature", as of August 2026).

In other words, in that mode you cannot add the clash colouring from the previous section, and you cannot edit it if it is already there. "We made the file shareable and now the colour rules are greyed out" is not a fault — it is the specification. If that is how your sheet is shared, the first move is to put the workbook on OneDrive or SharePoint and switch to co-authoring.

Formulas only protect what has already been typed in

Everything above reliably catches clashes between rows in the sheet. What it cannot see is the booking nobody has typed yet.

Bookings are created during a phone call or a message thread; the row appears afterwards. For the length of that gap the slot looks free to everyone. Say two staff take bookings for eight slots a day, a call runs three minutes, and it takes another two to enter it. Both of them holding a phone at the same time is not a rare event — it happens repeatedly in a day. What overlaps is not the bookings, it is the taking of them, and no formula operates in that window.

The second constraint is where the sheet can be opened. Smartphones are in 90.5% of Japanese households against 66.4% for PCs (source: Ministry of Internal Affairs and Communications, "2024 Communications Usage Trend Survey (household edition)", published 2025; household ownership as of end-August 2024). Both the person booking and the person checking between appointments are holding a phone, and a wide ledger carrying formulas and conditional formatting is not something you fill in accurately on that screen.

Whether to carry on is decided less by volume than by how many channels bookings arrive through.

Your situation	Verdict	Why
You are the only person taking bookings	Carry on	Nothing to collide with
One person taking them, but high volume	Carry on	More typing, but the formula catches clashes
Two or more people answer the phone separately	Move the intake	The entry gaps overlap
Phone, email and social all take bookings	Move	Every channel waits on "let me check the sheet"
Customers change or cancel often	Move	Every correction is another chance to lose an entry
Staff check and enter bookings while out	Move	Offline changes merge after the fact

Make the slot close at the moment the booking is taken

There is one way to remove the entry gap: let the customer pick the slot themselves, and have the slot close the instant they pick it. Four things decide whether a booking tool does that properly.

1. Does the slot close on booking? — the moment it is taken it stops being offered. This is a different mechanism from detecting clashes afterwards.
2. Two-way calendar sync — anything booked outside the tool blocks the slot, including a personal calendar you keep separately.
3. Does it work on a phone? — for the customer booking and for you checking, in a browser, without installing anything.
4. Can customers change and cancel themselves? — if you are still editing entries by hand on request, one source of lost data remains.

What follows is one tool that meets all four: SailLab.

SailLab

SailLab is a Japan-built booking system covering published availability, taking the booking, and confirmation and reminder emails in one place.

• Double booking cannot happen: the slot closes the moment a booking is confirmed. Rather than finding clashes later, the second booking is never accepted.
• Two-way calendar sync: connects to Google Calendar and Microsoft Outlook, so anything booked outside SailLab blocks the slot, and you choose which calendars are checked for conflicts.
• Nothing for the customer to install: they open the link and pick a time. Booking pages are shared as a link or QR code — there is no embeddable website widget.
• Customers reschedule and cancel themselves: from the confirmation email, and the slot returns to available automatically.
• Ask what you need at booking time: custom form fields collect what you were writing into the ledger by hand.
• Group slots: for classes and events, set a capacity per slot with a waitlist.

Two links is usually the easiest way to move over.

• A link for new customers: publish only open slots, and bookings through it confirm themselves. The existing ledger stays exactly as it is.
• A link for regulars: let them choose the service and duration, so what you used to ask on the phone arrives with the booking.

Plan	Monthly (annual billing, ex-tax)	What matters here
Free	¥0	1 booking link, Google / Outlook sync, confirmation and reminder emails, self-service reschedule and cancel
Light	¥800	Unlimited links, capacity-based slots, custom URL, SailLab branding removed
Standard	¥1,200	Service-menu bookings, upfront payment, booking analytics

Taking one service through one link fits inside the Free plan (as of August 2026). Details are on the pricing page. Bookings cannot be taken inside LINE, so if LINE is your main channel you would point people from there to the booking page.

It suits small operators where more than one person takes bookings, or bookings arrive through more than one channel.

A migration order that doesn't throw the sheet away

The ledger does not have to go today. Keeping it while you move only the intake is the safer order.

1. Take new bookings through the link — existing customers keep phoning, and you keep typing those into the sheet. One link is all it takes, and undoing it is just as easy.
2. Count two numbers for two weeks — bookings that came through the link, and clashes or missed entries in the same period. That is enough to decide on.
3. Start entering phone bookings into the link's calendar too — once both sides read the same availability, the sheet can stay as your record rather than your source of truth.

If you are attempting the same thing with Google Forms, see where Google Forms breaks as a booking system; if you would rather build from the calendar side, see taking bookings with Google Calendar. There is also a use case for solo operators.

SailLab's Free plan can be tried without a credit card — create an account.