Live Availability: How to Set It Up on a Hospitality Site

#Why availability decides the booking

The marketplace answers the only question the guest has in one second: are you free on the fourteenth. Your website, if it offers an enquiry form, answers it tomorrow. That gap is why the guest who searched your name still books through a platform and why you still pay commission on them.

Live availability is the fix, and it is a configuration job more than a design one. The engine already knows what is free. The work is getting that answer onto your own pages, keeping it correct, and making sure it can never sell the same room twice.

#Step 1: decide what one calendar means

Availability can only be live if there is a single source of truth.

Accommodation needs the property management system or channel manager to hold the calendar, with the marketplaces and your own booking engine both reading and writing to it. Little Hotelier, SiteMinder, Cloudbeds, eviivo, Beds24, Lodgify, Hostaway and Smoobu all work this way. Direct bookings must decrement marketplace stock within seconds, not overnight.

Restaurants need the table plan in OpenTable, ResDiary, SevenRooms, Tock or Quandoo, with the same inventory offered to the widget on your site and to the marketplace network.

Experiences need session capacity in FareHarbor, Bookeo, Rezdy, Bokun, Xola or Resova, with any resellers pulling from the same pool.

Coworking needs desks and meeting rooms in Nexudus, OfficeRnD, Optix or Skedda, so an external booking cannot clash with a member's.

If two systems can both say yes to the same night, you do not have live availability. You have a race.

#Step 2: fix the inventory before you show it

Availability is only useful if it is true.

• Every unit set up separately, with real capacities, not a generic pool.
• Minimum stays, changeover days, arrival and departure rules configured.
• Cut-off times for same-day bookings that match what the kitchen or the guide can actually cope with.
• Seasonal closures, maintenance and owner blocks entered in advance.
• Rates loaded for the whole booking window, so the calendar does not run out twelve months ahead.
• Buffer or turnaround time between sessions for escape rooms, boats and activity sessions.

Block a date in the system and watch it disappear from your site and from the marketplaces. If it does not, stop here and fix the sync.

#Step 3: put a date picker where the guest is

The engine's availability calendar belongs on the Book page. What belongs everywhere else is a small, fast entry point:

• A date and party-size picker in the hero of the home page that hands its values to the engine.
• On each room, pitch, tour or game page, a "Check dates" button that opens the engine already filtered to that product.
• On restaurant pages, a party size and date control that opens the table widget.
• On a holiday let or B&B site, a simple month calendar showing free and booked nights, so a browsing guest sees the shape of the season at a glance.

Those small controls are static markup that pass parameters to the engine. They do not need the engine's script, so they cost nothing in speed.

#Step 4: say something useful when you are full

Full is a fact, not a dead end. The engine should be configured, and the page written, so that a guest who finds no availability is offered the next best thing:

• The nearest available dates, which most engines can display.
• A different room type, pitch or session time.
• A waiting list or an alert when a date frees up, which several accommodation and experience systems support.
• For restaurants, the bar, a different service, or the waitlist.
• A phone number, because groups and last-minute changes are still handled better by a person.

A site that says "no availability" and nothing else has sent that guest to a competitor for free.

#Step 5: keep it fast and stable

Live data is the slowest thing on a hospitality page if you let it be. Load the availability widget on the Book page only, reserve its height so nothing shifts, and preconnect to the engine's domain. Where the engine offers an API, a cached summary such as "next available: Friday 3 October" can be rendered on room pages without loading anything heavy, refreshed every few minutes rather than on every visit.

Have a fallback. If the engine is unreachable, the page should show the phone number and an enquiry option rather than a blank box.

#Step 6: test the sync properly

Once a month, and after any change to rates or channels:

1. Take a direct booking on your own site for a specific night.
2. Check that night has gone from every marketplace listing.
3. Take a marketplace booking and check it has gone from your own site.
4. Cancel both and check the night comes back in both places.

Also check the engine's cut-off behaviour late in the day, which is where same-day bookings most often go wrong.

#Common mistakes

• An enquiry form described as booking.
• The channel manager syncing on a timer long enough to double-book.
• Availability shown but prices not matching the engine.
• The widget on every page, slowing the whole site.
• Nothing offered when the answer is no.
• Owner and maintenance blocks kept in a separate spreadsheet.

#Where this sits

Live availability from your own system, entry points on the pages guests actually read and a monthly sync test are part of every hospitality business website we build. The marketplace has no advantage that survives a site which answers the availability question as quickly as it does.