The target
A guest lands on a room, table or tour page, taps Book, picks a date and a party size, sees a price that matches the page, pays or holds the booking, and gets a confirmation. The reservation appears in your system with the guest attached, the availability updates everywhere, and nobody re-keys anything. All of it happens on your domain, so no marketplace takes a cut of a guest who came looking for you.
Here is the setup, in the order it should be done.
Step 1: pick the engine for your kind of business
The system is chosen for how the business operates, not for the website. Broadly:
Restaurants and cafés: OpenTable, ResDiary, SevenRooms, Tock or Quandoo. Table plans, covers, shifts, deposits on large parties, no-show handling.
Accommodation: SiteMinder, Little Hotelier, Cloudbeds, Mews, eviivo, Freetobook, Beds24, Lodgify, Hostaway, Smoobu or Sirvoy, depending on size and type. What matters is the channel manager underneath, because the calendar has to be one calendar.
Experiences: FareHarbor, Bookeo, Rezdy, Bokun, Peek, Xola, Resova or ROLLER. Timed slots, capacity per session, waivers, per-person pricing.
Coworking and meeting rooms: Nexudus, OfficeRnD, Optix, Cobot or Skedda, which handle memberships and room-by-the-hour together.
Whatever you run, the three website questions are the same: does it embed on my domain, can the buttons deep-link to a specific room or tour, and does it show live availability.
Step 2: configure the system before touching the site
Nothing on the website can compensate for a badly set-up engine.
- Every bookable thing named as guests would name it: room types, pitch types, tour departures, escape room games, table sizes.
- Rates and prices inclusive of tax and mandatory fees, matching what the site will show.
- Availability accurate, with the channel manager synced so marketplace and direct stock cannot double-book.
- Deposits, minimum stays, cut-off times and party sizes set.
- Cancellation and refund rules configured, in the same words the site uses.
- Confirmation and reminder messages in your voice, with directions, arrival time and parking.
- Waivers where the activity needs them, so nobody queues at the desk with a clipboard.
Then book yourself, on a phone, as a stranger, and pay real money. Refund it afterwards. Every problem you find here would otherwise have been found by a guest.
Step 3: embed rather than link out
The engine goes on your domain. Most systems offer an embeddable widget, an inline booking form, or a hosted page skinned to your brand. In order of preference: an inline embed on a dedicated Book page, a modal opened from the Book button, or a hosted page on a subdomain of your own site.
What to avoid is the button that opens the marketplace app or a third-party domain the guest does not recognise. That is the moment the booking stops being yours.
Step 4: the Book button and the deep links
A Book button in the header on every page, and one in the footer. Each of them opens the engine with as much already chosen as the system allows.
| Page | The Book button should carry | |---|---| | Room or pitch page | That room type, ready for dates | | Tour or session page | That product, ready for a date and slot | | Restaurant page | Party size and date, that venue | | Offers page | The rate plan or package | | Home | The engine, unfiltered |
Store the engine's identifiers for each room, tour or product as fields on the site's records, so the template builds the link. Hand-pasted URLs rot the first time somebody renames a product.
Step 5: one page carries the script
Booking widgets are heavy. Load the engine's script on the Book page only. Room pages, menu pages and tour pages are static content with links, so they stay fast and rank. Reserve the widget's height in the stylesheet so the page does not jump, and preconnect to the engine's domain so the first request starts sooner.
Step 6: test where guests actually are
Safari and Chrome on a phone, then inside the in-app browsers in Instagram and Facebook, which is where a large share of hospitality traffic comes from. If an embed misbehaves in an in-app browser, point social links at the engine's hosted page instead, which never fails the same way.
Step 7: tracking
Events for Book taps by page, booking started, and booking completed, with the room or tour as a parameter. Add the engine's own source report. Once a month, compare direct bookings against the marketplace statements. Without this you cannot tell whether the site is working, and the number moves quickly once the engine is embedded.
Step 8: the monthly check
From the home page and from a room or tour page, on a phone: start a booking, complete it, cancel it. Engines update their widgets, certificates expire, and a broken Book button is a business quietly closed online. Restaurants, campsites and tour operators all lose the same way when nobody tests.
Common mistakes
- The Book button linking to a marketplace listing.
- A contact form standing in for an engine.
- The widget loaded on every page.
- Prices on the site that no longer match the engine.
- No deep links, so every guest starts from an empty search.
- Nobody testing after the engine's next update.
Where this sits
An embedded booking engine with deep links, one script on one page and tracking on every button is the core of every hospitality business website we build, and the scope is at a fixed price. The system runs the availability and the money; the website makes sure the guest never has to leave to use it.