Important notes about seating

To ensure capacity is correct, active seat maps are always tied to resources. You can see this relationship in the resource’s settings and in the use count menu in the seat map settings. Sometimes, the same seat map may be added to multiple resources (for example, if different parts of the map correspond to different resources). But a single resource can never be tied to more than one seat map.

Mapping customer types to seat map zones is done with resource requirements. To determine which parts of the map a customer type can be booked into, go to the related resource requirement group, then find the requirement(s) for that specific customer type (cmd+F if there are a lot). Click on the related resource requirement option and go to the Seating tab.

If “All zones” is selected, this means that the customer type can be booked into all zones that have been checked on the related resource’s settings, which is not necessarily all zones on the seat map itself.

General tips

• When looking at related resource requirements or seat maps, always use the blue “jump link” next to the name of the requirement group/resource/seat map. This ensures you go straight to the correct place and reduces the amount of time spent searching through long lists of resources or seat maps.

  

• Resource requirements can be set up at the item level OR company level. To avoid having to search for the right requirements, use the jump link mentioned above!

Online customers using methods of payment like iDEAL that require pending bookings may potentially lose their selected seats while entering payment info, depending on how long it takes to complete the payment process and the level of demand for the activity/event being booked.

As long as the API integration takes resources into account (which most do), seats can be successfully auto-assigned for customers booking through an OTA like Viator, Expedia, or Reserve with Google. However, customers will not be able to choose their own seats from the map if booking through an OTA.

Because customers booking through OTAs receive confirmations from the OTA and not from FareHarbor (except Reserve with Google, which sends both), the communication of seating information for API bookings is more manual. If the company wants to relay seating information to the customer in this case, they should send a confirmation/reminder/message email from the booking in FareHarbor, otherwise the customer won’t see it.

There are several possible ways to set up buyouts with seating, based on the size of the venue and what’s most important to the company.

Option 1: Assign all seats

Set up resource requirements so that the “Buyout” customer type requires the same number of bookable seats on the seat map. On the related resource, make sure auto-assign is on (this ensures that all seats on the map get automatically filled; otherwise, the capacity will be full but the map will still appear empty/available).

Good for:

• Small venues with fewer than 50 seats
• Companies that want to see ALL seats on the map booked/unavailable

Not great for:

• Items where “Display seating assignments on emails, confirmations, and receipts” is enabled
• Companies that experience slow load times

Option 2: Fill all seats once booked

Set up resource requirements so that the “Buyout” customer type uses 1 of the seat map resource and has the “Fill all seats once booked” option enabled. The Buyout customer type should also be exclusive and have a capacity of 1.

On the related resource, make sure auto-assign is on (this ensures that all seats on the map are automatically made unavailable; otherwise, the availability will still be bookable).

Good for:

• Larger venues with more than 50 seats
• Companies that experience slow load times
• Companies with either a separate Buyout item, or an exclusive Buyout customer type with max capacity of 1
• Companies that want to see ALL seats on the map booked/unavailable when a buyout has been purchased

Not great for:

• Companies that have multiple resources using the same seat map
• Companies that rely on resource use counts (for example, if they need to see “75 booked, 0 available” instead of “1 booked, 0 available”)

Option 3: Resource custom restriction: Same booking

Set up resource requirements so that once the resource has been used, any overlapping uses must be for the same booking.

Good for:

• Larger venues with more than 50 seats
• Companies that experience slow load times
• Companies that don’t care how many seats appear “booked” on the seat map

Not great for:

• Companies that have multiple resources using the same seat map
• Companies that rely on resource use counts (for example, if they need to see “75 booked, 0 available” instead of “1 booked, 0 available”)

Other notes

• Note that with any of these options, Dashboard users with permission to overbook and overuse resources can still overbook on top of a buyout. For example, they can select another customer type in addition to a buyout, select 2 buyouts, create a new booking on top of the buyout, etc.
  • In these instances, seats will not be auto-assigned even if auto-assignment is on. Any time a user is “overriding the rules” by overbooking, we leave seats unassigned so that the user can manually edit them as they see fit.
  • While we will always warn the user in the book form that they are overbooking, all precautions should be taken to set things up in a way that prevents a user from accidentally overbooking (make the Buyout CT exclusive with capacity of 1, etc.).

• For companies that have buyouts and allow their customers to choose seats while booking online, it’s recommended that they do not use the “Show seat map at start of booking” option. This is because it’s unintuitive for a user to select “Buyout” from a single seat on the map.

  

During development of the seating assignment feature we tested a seat map with 2000 seats as our upper limit, and noted that load times for these maps on the book form and manifest could be up to 15 seconds.

Complex resource requirements may also increase load times or make things slow when a user tries to select or edit a seat.

While there is no strict cutoff on the number of seats that we can support on a seat map, it’s always good to test larger maps and complex setups before locking anything in.