本頁面由 Cloud Translation API 翻譯而成。

候位名單簡介

參與候位名單計畫的合作夥伴必須先完成設定帳戶，才能開始使用這項功能。不過，使用一般名單中的某些步驟時，並不需要使用候位名單功能。本頁指南將說明有意使用「透過 Google 預訂」加入候補名單功能的合作夥伴。建議您先閱讀這份總覽說明，再進行整合步驟。

發布程序

圖 1 概略說明在透過「透過 Google 預訂」推出候位名單功能的商家。

整體來說，您 (合作夥伴) 與 Google 之間的主要資料流，如圖 2 所示：

導入等候名單功能時，請注意下列事項：

每個候位名單服務的服務都必須填入 waitlist_rules。
- 候位名單和預約服務必須使用相同的服務。換句話說，如果您的餐廳也允許預訂，只要將預約的相關中繼資料新增至預訂服務即可。
在以下情況中，您必須傳送簡訊更新，才能加入等候名單：
- 確認使用者已成功加入候位名單。
- 通知使用者其資料表已準備就緒。
- 通知使用者候位名單已經取消。
簡訊必須包含一個網頁連結，方便使用者查看候位名單狀態。
等候名單的商家不需要提供供應情形動態饋給給「透過 Google 預訂」。
您的預訂伺服器必須實作導入預訂伺服器中列出的所有候補名單專屬步驟。如果合作夥伴同時支援預訂和候位名單，可以將新方法加入現有的預訂伺服器。
「透過 Google 預訂」會針對預訂伺服器中的候位名單方法執行一組測試案例。

這張圖表說明回應 GetWaitlistEntry 呼叫時，WaitlistEntry.waitlist_entry_state 中必須回報的狀態。圖表也會顯示錄製和填入 WaitlistEntry.waitlist_entry_state_times.*_time_seconds 欄位的時機，以及向使用者告知他們已進入新狀態的時機。

以下是候位名單整合的常見極端案例，以及這些解決方案的偏好解決方案。

如果部分 (但並非全部) 派對人數不接受增加這些候補名單，這是因為系統不需等待這些派對人數，則在 BatchGetWaitEstimates 回應中，針對所有預訂人數傳回 WaitEstimates，並讓使用者能夠直接加入這些人數的候補名單，且不用等候。針對 party_size，傳回包含 0 parties_ahead_count 的 WaitLength 和/或包含 estimated_seat_time_range 的 start_seconds，以及 party_size 的 estimated_seat_time_range。
如果一或多位派對人數因候補時間過長而無法接受新的候位名單，則建議在 BatchGetWaitEstimates 回應中省略這些派對大小的 WaitEstimates。

我們建議採用這些方法，因為即便商家未完全開放，也能提供使用者的選項。

如果預訂伺服器僅用於等候名單，請注意下列事項：

僅限候補名單合作夥伴並未提供「透過 Google 預訂」的供應情形動態饋給。
僅限候補名單合作夥伴不會在預訂伺服器中導入預訂方法。而應改為導入預訂伺服器的操作說明，以便加入候位名單。
僅限等候名單合作夥伴不應向 Google 提出 API 呼叫；也就是說，僅具備候位名單的合作夥伴不需要設定雲端專案或提供開發人員的電子郵件地址。您不需要完成即時 API 更新。不過，您還是必須一併提供商家和服務動態饋給給「透過 Google 預訂」。

如果您的商家必須手動接受或拒絕 Google 加入新的候位名單，則必須執行額外步驟：

針對需要手動確認的預訂人數，在 wait_estimate 中將 waitlist_confirmation_mode 設為 WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS。您必須在 BatchGetWaitEstimateResponse 和 GetWaitlistEntryResponse 中設定這項資訊。
使用者已要求、但商家尚未接受的候補名單項目應處於 PENDING_MERCHANT_CONFIRMATION 狀態。

Google 會測試下列用途，以確保在預訂伺服器實作中導入候位名單方法的功能。並測試及監控延遲時間。這些測試必須全數通過，商家才能上線。

系統會針對 BatchGetWaitEstimatesRequest 中要求的每個派對大小傳回等待時間預估值。
如果商家可選擇接受或拒絕新增候位名單的人數，請將等候名單_confirmation_mode 設為 WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS。

對於先前已啟用候補名單，但已決定不採用此商家的商家，Google 會預期收到特定回應。