Bookings on your site, or in the booking tool?

A question that turns up in our inbox often enough to be worth a post: is there software that does the website and the scheduling in one go?

Short answer, yes, several. Longer answer, that's usually not the question the person means. What they actually want to know is whether the booking should live on their website or somewhere else, and whether the somewhere else looks like a downgrade.

There are three arrangements. They cost wildly different amounts of effort and the gap between them matters less than people think.

One: send people to the tool

The booking button on your site is a link. It opens Calendly, or Cliniko, or Square Appointments, or whatever runs your diary, on that tool's own domain. The customer books there and comes back, or doesn't come back, because they got what they came for.

This is the arrangement most people are slightly embarrassed about and it's the correct answer far more often than anyone admits. It takes an afternoon. Nothing can break in an interesting way. The booking tool's own flow is, in almost every case, better tested on mobile than anything we'd build for you in a week.

What it costs you is the seam. Your site is one colour and the booking page is another, and a certain kind of customer notices and hesitates. Some drop-off happens at that jump. Not much, and less than you'd guess, but it's real.

For a business taking a handful of bookings a week, take the seam. Spend the effort on the page that convinces people to click the button, which is where the actual loss is.

Two: embed the widget

The booking tool gives you a snippet, the snippet goes on a page of your site, and the booking calendar appears inside your own layout. This is the default choice and it's the one I'd push back on hardest, because the costs are invisible until they aren't.

An embed is third-party JavaScript, loaded from someone else's server, running inside your page. Google's guidance on third-party JavaScript puts it plainly: any significant amount of JavaScript can slow a page down, and third-party code brings extra problems precisely because it's outside your control. You can't minify it, you can't defer the parts you don't use, and when the vendor ships a heavier version one Tuesday your page gets slower without anyone touching it.

That matters more than it used to, because the booking page is often the page with the highest intent on the whole site. If you want to know what that slowdown looks like in numbers, reading a speed test covers which figures to trust.

The second cost is that embeds have a habit of being bad on phones. The widget was designed for a wide container and yours isn't, so you get an iframe with its own scrollbar inside a page that already scrolls. Everyone has met one of these. Nobody enjoyed it.

Embeds are worth it when the booking flow is short, the widget is genuinely responsive, and you've checked it on an actual phone rather than a narrow browser window. Check it on an actual phone. Please.

Three: build the booking into the site

The site talks to the booking tool's API directly. Availability comes from the tool, the form is yours, the confirmation is yours, and the booking lands in the same diary it always did. No seam, no third-party script, and full control of what happens either side of the booking.

This is the most work by a distance, and it only earns its keep in two situations. Either you take enough bookings that a few percentage points of drop-off is real money, or your flow is unusual in a way the tool's own interface handles badly. Multi-practitioner clinics with rules about who can do what. Anything where the price depends on answers given during the booking. Trades doing site visits where the slot length isn't fixed.

If neither of those is you, this is a lot of money for a slightly nicer experience. We'd say so. The mechanics of connecting a site to a scheduling tool are covered in online bookings and scheduling if you want the detail before deciding.

The thing that actually goes wrong

None of the above, usually. What goes wrong is the account.

Whoever set up the booking tool owns the login, and the booking tool holds your customer list, their contact details and their history. Three years later that's one of the most valuable things your business has, and a surprising number of operators find out who controls it at the worst possible moment. This is the same problem as the domain and the hosting, which we've written about in who actually owns your website, and the fix is the same: the business holds the account, in the business's own email address, and anyone helping gets invited to it.

Second thing that goes wrong: nobody decides what happens after the booking. A confirmation email that looks like a receipt, no reminder, no way to reschedule without ringing. The no-show rate in most service businesses is mostly a reminder problem, and reminders are a setting in every one of these tools that someone has to turn on.

Third, and this is the quiet one: the booking tool becomes a second place your customer data lives, separate from wherever else it lives. Worth being deliberate about, rather than discovering it during a tidy-up. The range of things worth connecting is the wider version of that argument.

How to choose

Count the bookings you take in a month. Under about twenty, link out and stop thinking about it. Between twenty and a couple of hundred, embed if the widget behaves on a phone and link out if it doesn't. Above that, or if your scheduling has real rules in it, build it in properly and expect it to take a while.

Then go and check who holds the login.