Partners participating in the Reservations Waitlists program must complete the account Setup before they begin. However, some steps in the general guide aren't necessary for use of the waitlist feature. The guidelines on this page explain what steps apply to partners interested in using the waitlist feature on Reserve with Google. We suggest that you read through this overview before going through the integration steps.
Launch process
Figure 1 outlines the process to launch your waitlist-enabled merchants on the Actions Center.
![Figure 1: High-level integration steps](https://google-developers.gonglchuangl.net/static/actions-center/images/waitlists/reserve_with_google_waitlist_integration.png?authuser=1)
Overall, the major data flows between you (the Partner) and Google are captured in Figure 2:
![Figure 2: Integration data flow diagram](https://google-developers.gonglchuangl.net/static/actions-center/images/waitlists/waitlist_integration_data_flow_diagram.png?authuser=1)
Guidelines for all Reservations Waitlists partners
Keep the following in mind as you implement the Reservations Waitlists feature:
- The service for every Reservations Waitlists merchant must have
waitlist_rules
populated.- You must use the same service for both waitlist and reservation. In other words, if your restaurant also allows reservations, just add the waitlist related metadata to the service for reservation.
- Sending out SMS updates is required for the waitlist implementation in
the following cases:
- To confirm the user has successfully joined the waitlist.
- To notify the user that their table is ready.
- To notify the user that their waitlist entry has been cancelled.
- SMS messages must contain a link to a page where users can view their waitlist status.
- Waitlist-only merchants do not need to provide availability feeds to the Actions Center.
- Your booking server must implement all the waitlist-specific steps listed in Implement the booking server. Partners that support both reservations and waitlists can add on the new methods to their existing booking server.
- The Actions Center runs a set of test cases for the waitlist methods in the booking server.
Status flowchart
This chart describes the statuses that must be reported in
WaitlistEntry.waitlist_entry_state
when responding to
GetWaitlistEntry
calls. The chart also indicates when to record and populate the
WaitlistEntry.waitlist_entry_state_times.*_time_seconds
fields and when to send an SMS to the user to inform them they have entered a new state.
![Figure 3: Waitlist status flowchart](https://google-developers.gonglchuangl.net/static/actions-center/images/waitlists/waitlist_status_flowchart.png?authuser=1)
Common edge cases
The following are common edge cases in a Reservations Waitlists integration and preferred solutions for them.
-
If some (but not all) party sizes are not accepting new waitlist
additions because there is no wait on these party sizes then returning
WaitEstimates
for all party sizes in theBatchGetWaitEstimates
response and allowing users to join the waitlist for these party sizes with no wait is preferred. Return aWaitLength
with 0parties_ahead_count
and/or with anestimated_seat_time_range
with 0start_seconds
and with 0end_seconds
for theparty_size
s with no wait -
If one or more party sizes are not accepting new waitlist additions
because the wait has become too long then omitting
WaitEstimates
for those party sizes in theBatchGetWaitEstimates
response is preferred.
These approaches are preferred since they give the user options even though the merchant's waitlist may not be fully open.
Guidelines for Reservations Waitlists-only partners
Keep the following in mind if the booking server is used only for waitlists:
- Reservations Waitlists-only partners don't provide availability feeds to Reserve with Google.
- Reservations Waitlists-only partners do not implement the reservation methods in their booking server. Instead, you Implement the booking server with the instructions for the Waitlist implementation.
- Reservations Waitlists-only partners do not make API calls to Google. This means that Reservations Waitlists-only partners do not need to set up a cloud project or provide a developer email address. You do not need to complete Real-time API updates. However, merchant and service feeds still need to be provided to the Actions Center.
Guidelines for partners whose merchants must manually accept/reject waitlist additions
If your merchants require the ability to manually accept or reject new waitlist additions from Google, extra steps are required:
- Set the
waitlist_confirmation_mode
toWAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS
in thewait_estimate
for party sizes which require manual confirmation. This must be set in theBatchGetWaitEstimateResponse
and theGetWaitlistEntryResponse
. - Waitlist entries that have been requested by the user, but not yet
accepted by the merchant should be in state
PENDING_MERCHANT_CONFIRMATION
.
Reservations Waitlists test cases
Google tests the following use cases to ensure the functionality of the waitlist methods in your booking server implementation. Google also tests and monitors latency. All of these tests must pass prior to launch.
WaitEstimate retrieval
- Wait estimates are returned for each party size requested in a
BatchGetWaitEstimatesRequest
. - For party sizes which the merchant has the option to accept or reject
new waitlist additions, set waitlist_confirmation_mode to
WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS
.
Waitlist entry creation
- A waitlist entry can be created from a
CreateWaitlistEntry
request. - If waitlist entry creation fails, a business logic error shows up in the response.
- If a
CreateWaitlistEntry
attempt succeeds, the same response is returned when the sameCreateWaitlistEntry
is received again. - If a
CreateWaitlistEntry
attempt fails, the server retries when the sameCreateWaitlistEntry
is received again. - Waitlist entries show up in the merchant's interface.
- Calls to
GetWaitlistEntry
successfully return the created waitlist entry.
Waitlist entry states and timestamps
- Verify that each waitlist entry state is returned properly in the waitlist entry of
GetWaitlistEntry
responses. - Verify that each state timestamp is set in the appropriate timestamp field of the waitlist
entry in
GetWaitlistEntry
responses.
Waitlist entry deletion
- Existing waitlist entries can be deleted. The response to a successful
delete must be the empty proto
{}
.
Opt out
- Verify that opted out merchants are treated as described in Merchant opt out.
Sample waitlist service feed (JSON)
Waitlist service feedMerchant opt out
Google expects certain responses for merchants that previously had waitlists enabled but have decided to opt out.
Immediate opt out
- Return
CLOSED_OTHER
forBatchGetWaitEstimates
requests. - Return
WAITLIST_CLOSED
forCreateWaitlistEntry
requests. - Return
GetWaitlistEntry
requests properly for users who are already on the waitlist.
Extended opt out
- Remove the
waitlist_rules
from the service feed for the merchant if the merchant is not opting out of reservations. - Remove the merchant from the merchant feed if they opt out of all Google integrations.