In light of COVID-19, please review the latest announcement regarding the Reserve with Google guidelines for supporting users and merchants during this time. Additionally, since we are operating with a limited support team, it may take longer to connect with us. Thank you for your patience, and we value your partnership.

Adding dining seating sections

It is common for restaurants to have distinct seating areas, such a bar or patio. Reserve with Google supports this distinction and allows the user to specify the area to book a table. An example of this is shown below, where availability for the “Bar” and “Patio” are different and are presented to the user distinctly:

Figure 1: Example slot selection for a restaurant with seating sections

This inventory separation can be employed by setting the room_id and room_name fields in the resources message of an Availability slot.

// A resource is used to disambiguate availability slots from one another when
// different staff, room or party_size values are part of the service.
// Multiple slots for the same service and time interval can co-exist when they
// have different resources.
message Resources {
  // One of staff_id, room_id, or party_size must be set.

  // Optional ID for a staff member providing the service. This field identifies
  // the staff member across all merchants, services, and availability records.
  // It also needs to be stable over time to allow correlation with past
  // bookings. (optional but required if staff_name is present)
  string staff_id = 1;

  // Optional name of a staff member providing the service. This field will be
  // displayed to users making a booking, and should be human-readable, as
  // opposed to an opaque identifier. (optional but required if staff_id is
  // present)
  string staff_name = 2;

  // An optional ID for the room the service is located in. This field
  // identifies the room across all merchants, services, and availability
  // records. It also needs to be stable over time to allow correlation with
  // past bookings. (optional but required if room_name is present)
  string room_id = 3;

  // An optional name for the room the service is located in. This
  // field will be displayed to users making a booking, and should be human
  // readable, as opposed to an opaque identifier. (optional but required if
  // room_id is present)
  // In dining a room name should only be used for seating areas such as the bar
  // or patio and should not be used for fixed price menus, special activities,
  // or any other non-room value (such as reservation or dinner). It is strongly
  // recommended that the default seating area not have a room associated with
  // it.
  string room_name = 4;

  // Applicable only for Dining: The party size that can be accommodated
  // during this time slot. A restaurant can be associated with multiple Slots
  // for the same time, each specifying a different party_size, if for instance
  // 2, 3, or 4 people can be seated with a reservation. (optional)
  int32 party_size = 5;
}

This information is an integral part of a slots definition and will need to be included in the feeds as well as all booking and real-time update operations. You can see examples of the room_id and room_name being specified in the Dining, Vertical-Specific Feed example.