It is common for restaurants to have distinct seating areas, such a bar or patio. The Actions Center 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:
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 or experience of // of the service. This field will be displayed to users making a booking, // and should be human readable, as opposed to an opaque identifier. // A room name should only be used for seating areas or prepaid experiences. // Examples of room names include "Bar", "Patio", "Dining Room". Examples of // dining experiences using room names include "Five-Course Tasting Menu", // "Chef Omakase". It is strongly recommended that the default seating area // does 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.