The two layouts
Every booking tool offers an embed code. Where you put it is a design decision with a measurable effect on bookings, and there are two common answers.
The widget everywhere. The booking calendar is embedded on the home page, on each service page, in a sidebar or a pop-up. The client can book from wherever they are.
The booking page. One dedicated page holds the embedded tool. Every other page has a prominent button that leads there.
Intuition says the first converts better: fewer clicks. On a phone, which is where most of your clients are, it is usually the other way round.
What goes wrong with widgets on a phone
They are heavy. A booking widget is a small application. Embedding it on every page means every page loads it, whether or not the visitor wants to book. On a phone on mobile data that can be the difference between a two-second page and a five-second one, and the visitor who left at four seconds never saw the widget.
They fight the page. A widget inside a narrow column on a phone becomes a scrolling box inside a scrolling page. The client scrolls the calendar, the page scrolls instead, the calendar jumps. Frustration, then abandonment.
They are half-styled. Most widgets accept a colour or two. The result is a rectangle that looks like a different website pasted into yours, which reads as untrustworthy at exactly the moment the client is about to enter a card number.
Pop-ups get dismissed. A booking pop-up on arrival is closed by reflex before it is read. Then the client has to find the booking again.
What a booking page gets right
The page loads fast because it has one job. Nothing else competes for the visitor's connection.
The widget gets the full width. On a phone, the calendar and time slots have room, the scrolling is the page's own, and the whole thing behaves like the tool's designers intended.
It has room for reassurance. A line above the widget about deposits, cancellations and what happens next. A note about parking. The confidence a nervous first-timer needs before they commit.
Every other page is lighter. Service pages load fast and end in one button. The button is the call to action, and there is only one.
It is measurable. Visits to the booking page against completed bookings is a clean conversion figure. Widgets scattered across pages are much harder to attribute.
The hybrid that works
The layout we build most often:
- A booking page at
/bookholding the embedded tool, full width, with a short reassurance block above it. - A sticky "Book" button on mobile, visible at the bottom of every page, leading to the booking page. One tap from anywhere.
- Service pages that end in a booking button which pre-selects the service where the tool allows it, so the client lands on the booking page with the right thing already chosen.
- No pop-ups. None.
Two taps from any page to a booking in progress, with a fast page at each step. That beats a widget on every page because the widget on every page made every page slow.
When the widget wins
There are cases. A single-service business, a solo trainer or a one-treatment clinic, where the whole site is effectively the booking. A landing page for a campaign whose only purpose is to book one thing. In those, embedding the widget directly in the hero is right, because there is nothing else on the page for it to compete with.
The rule is: embed the widget where booking is the page's only purpose. Link to it from everywhere else.
Testing your own
Load your site on a phone, on mobile data, and time the home page. Then count the taps from landing to a time slot selected. Then try to book on a screen while the page is scrolling. If any of those is uncomfortable, the layout is costing you bookings, and it is a layout change, not a new site. It is one of the first things we adjust in a booking setup, because it is usually the highest-return hour of the project.