Blog on BunnyCal Blog

How to Let Customers Book Appointments Online

Sun, 16 Aug 2026 00:00:00 +0000

If you run a small business, you know this conversation:

“Are you free Tuesday?” “Tuesday’s full. Wednesday afternoon?” “Can’t do Wednesday. Thursday morning?” “Thursday morning works — 10 or 11?”

Four messages, two days, one appointment. Multiply that by every client, and you are spending hours a week doing calendar arithmetic instead of the work you actually get paid for.

Online appointment booking replaces all of it with one link. You share the link, the customer sees the times you are genuinely free, they pick one, and it lands on both of your calendars. No back-and-forth, no double bookings, and nobody has to be awake at the same time for it to work.

The outbox pattern and the crash in between

Sat, 08 Aug 2026 00:00:00 +0000

When you build a calendar application, creating a booking is rarely just a database operation.

Imagine this simple flow:

Bob creates a calendar booking with Alice.

When the booking is created, we need to do at least two things:

Save the booking in the database.
Notify Alice that she has been invited.

At first glance, this sounds straightforward.

But once these operations cross system boundaries, things get surprisingly interesting.

What happens if the booking is saved successfully, but the application crashes before the email is sent?

What shipped in July

Sat, 25 Jul 2026 00:00:00 +0000

A month of work that mostly amounts to removing steps from things you already do more than once a day.

Multi-account calendars

You can now connect more than one calendar account per provider — two Google accounts, or a Google and a Microsoft account side by side. Every connected calendar can be marked as a conflict source, while exactly one stays the write target for new bookings.

This also fixes a long-standing sharp edge: connecting a second account used to overwrite the first. Each connection is now independent, with its own disconnect.

Round-robin that actually balances

Wed, 22 Jul 2026 00:00:00 +0000

Every scheduling tool with a team plan claims to do round-robin. Most of them implement the same thing: keep a pointer, hand the next booking to whoever is next in the list, advance the pointer. It demos beautifully. It falls apart in the second week.

Why a rotating pointer drifts

A pointer only counts offers, not outcomes. Consider a three-person team where everyone is nominally equal:

Priya works Tuesdays through Fridays.
Marco is on Pacific time; the team’s booking page is mostly booked by European prospects in the morning.
Dana has back-to-back internal meetings every Monday.

The pointer doesn’t know any of that. It offers Marco the 9am CET slot, finds he has no availability, and skips to the next person. Skipping doesn’t cost Marco his turn — so he stays at the head of the queue and gets skipped again. By Friday, Priya has taken sixteen calls and Marco has taken three, and nobody touched a setting.

Every timezone bug is really a calendar bug

Wed, 15 Jul 2026 00:00:00 +0000

Scheduling bugs cluster around two moments in the year, and they are the same two moments for everyone: the second Sunday in March and the last Sunday in October — give or take, depending on which hemisphere and which government.

The assumption that breaks

The bug is almost always this: storing a meeting as a wall-clock time plus an offset rather than as an instant plus a timezone.

{ "startsAt": "2026-10-24T09:00:00+01:00", "recurrence": "WEEKLY" }

That looks unambiguous, and for a single meeting it is. But the recurrence rule has to answer “when is the next one?” — and on 25 October, +01:00 stops being the correct offset for Europe/London. Naively adding seven days gives you 2026-10-31T09:00:00+01:00, an instant that renders as 8:00am to the host. Their weekly standup silently moves an hour earlier, and only for the half of the team in a country that just changed its clocks.

Booking pages that convert

Wed, 08 Jul 2026 00:00:00 +0000

A booking page has exactly one job, and the gap between a good one and a bad one is mostly about how much work you ask the guest to do before they see a time.

1. Show times before you ask for anything

The single biggest drop-off is a form that appears before the calendar. A guest arrives wanting to know whether you’re free Thursday. Asking for their name, company, and reason for meeting first inverts the order — they’re paying a cost before receiving any value. Put the slots first and collect details on the confirm step, when they’re already committed.

Multiple calendars, one source of availability

Sat, 27 Jun 2026 00:00:00 +0000

Most people don’t have a calendar. They have a work Google account, a personal one, maybe an Outlook calendar from a client engagement — and meetings booked against any of them are equally real when someone asks if you’re free at two.

Read from everything, write to one

BunnyCal separates the two operations, because they want opposite defaults.

Conflict checking should be greedy. Every connected calendar you mark as a conflict source is queried when computing availability. A dentist appointment on your personal calendar blocks a work booking, and nobody outside sees why — the slot is simply gone.