The multi-property widget

Why	One search block for the whole group of properties: the guest picks their property right in the widget and books without leaving the site.
Who	Anyone running several properties on one website: small chains of two or three hotels, apartment operators.
What you’ll get	A property selector in the widget on your website; once the guest chooses, the dates, rooms, and prices open for that property.
Limitations	The multi-property widget is not chain management: there are no consolidated reports across a group of properties. The guest books a room type — a specific bed cannot be chosen.

Groups of properties often share one website: a small chain keeps a single “Book” page, an apartment operator keeps one landing page for the whole portfolio. The multi-property widget is made for exactly this: one widget on the website, with a property selector inside. The guest does not have to guess where to book — they start right on your site and pick their property.

The selector is turned on with one switch in the PMS — no code, no developer. This article covers who the widget is for, how to turn it on, and what the guest sees.

Who the multi-property widget is for

The multi-property widget is the choice for when there are several properties and one website. The classic scenarios: a small chain of two or three hotels sharing a site, an apartment building with units of different layouts, an operator running several addresses in one city. Instead of a separate booking block on each property’s website — one widget listing the properties, where the guest picks theirs.

Here is how it looks in practice: the guest arrives at the group’s website from the “Contacts” page or from a search engine and sees a single search block with a property selector. One guest will pick the hotel in the center, another the apartments by the waterfront; both start their booking on the same page, in the same widget.

The opposite setup works too — each property gets its own website and its own widget. That is a valid scheme as well: every site has a search block set up for its own property. The multi-property widget is for when you deliberately keep one website for the whole group: one “Book” page, one block of code, and the guest takes care of the difference between properties by choosing.

The properties live in one account, and each has its own subscription. The group keeps a single website: one “Book” page, one search block — the very reason to choose the multi-property widget.

“Property” here means any unit that hosts guests: a hotel, a guesthouse, a hostel, an apartment building. For the guest, the widget simply offers options to choose from — and the choice decides where they stay.

If you run a single property, you do not need the multi-property widget: the regular widget already does the job — how to embed it is covered in the Booking Engine article (see “See also”).

Turn on the property selector

The widget — the search block on the website page — is configured in the PMS as a whole: its width on every screen, the button text, the language, the search behavior. The property selector is one of these settings; it lives on the “Widget” page, in the “Behavior” block — next to the default party size, the promo code field, and the prices in the calendar:

1. In the PMS, open the Online booking section and go to the “Widget” page.
2. Scroll the settings to the “Behavior” block — next to “Show the ‘children’ field”, “Show the ‘promo code’ field”, and “Show prices in the calendar”.
3. Find the “Multi-widget: property selection” switch and turn it on.
4. Look at the search block the way a guest would — on the live website or in the “Widget preview” next to the settings: the widget now offers a choice of property.

Outcome: the guest now picks a property in the widget first — and only then searches dates and rooms for that property.

The widget code comes from the same “Widget” page, as with any regular embed. If the widget is not on your website yet, start with the Booking Engine article: it covers the two ways to embed and the live preview of the settings.

The switch works both ways: if you decide to split the properties across separate websites, turn “Multi-widget: property selection” off — and the widget returns to a regular search with no selector.

What the guest sees

For the guest, one step is added — choosing a property; it comes first, before searching dates. From there the path is the one every booking module follows:

1. The guest opens your website and sees the widget with the group’s properties.
2. Picks their property — the one closer to the center, say, or by the sea.
3. Searches dates and rooms: the room types, rates, and prices open for the chosen property.
4. Completes the booking as in the regular module: guest details, confirmation.

After the property is chosen, the search runs on that property alone: the dates, the room types, and the prices belong to the chosen property, not to the whole group. The guest sees what can actually be booked in their property for their dates — with no “that room is in the other building” caveats.

For the property itself, nothing special happens in this story: such a guest’s booking is a regular direct booking from the website, and it lands in the calendar grid like any other.

What happens to the booking next — from confirmation to check-in — is covered in the article on direct bookings (see “See also”).

The guest goes through the whole path on your website, without leaving for third-party pages — and books exactly the property they chose at the start.

Honest limits

• This is not chain management. The multi-property widget solves one job: letting the guest choose a property on one website. There are no chain-management tools in the system — and no consolidated reports across several properties either.
• No choosing a bed. The guest books a room type or an apartment; choosing a specific bed is not available in the module.
• One booking block. The multi-property widget is one widget with a property selector, not several separate booking points: there are no separate booking points per property today.

In short, what the widget does not include:

You want	In the module
The guest chooses a property on one website	Yes — that is its job
Consolidated reports across the group of properties	No
Choosing a specific bed	No
Several booking points per property	No

The “not chain management” boundary is practical: if you expect group-wide numbers from the widget — occupancy, revenue, bookings across properties in one report — the system does not have them. Every property runs on its own, and the widget only answers for bringing the guest from one website to the right property. If you write about the group on your website or in a newsletter, do not promise readers shared dashboards or chain reports: the widget is about the guest’s way in, not about the numbers.

See also

• How direct bookings work — what happens to the booking after the guest picks a property and completes the booking.
• Module link parameters — prepare a link that opens the module with the arrival date or promo code already in place.