此页面由 Cloud Translation API 翻译。

候位名单简介

参与等位名单计划的合作伙伴必须先完成帐号设置。但是，常规指南中的某些步骤不是使用候位名单功能所必需的。本页面上的指南介绍了对有兴趣使用“通过 Google 预订”功能候补名单功能的合作伙伴采取的步骤。我们建议您在完成集成步骤之前仔细阅读本概览。

发布流程

图 1 显示了在“通过 Google 预订”上发布已启用等位名单的商家的过程。

总的来说，您（合作伙伴）与 Google 之间的主要数据流如图 2 所示：

在实现候位名单功能时，请注意以下几点：

每个等位名单商家的服务必须填充 waitlist_rules。
- 您必须对候位名单和预订使用同一服务。换言之，如果您的餐厅还允许预订，则只需向服务中添加与等位名单相关的元数据即可预订。
在下列情况下，实现等位名单功能需要发送短信更新：
- 确认用户已成功加入等候名单。
- 通知用户他们的表格已准备就绪。
- 通知用户其等位名单条目已取消。
短信必须包含一个指向网页的链接，用户可在该页面查看他们的等位名单状态。
仅支持候位名单的商家无需向“通过 Google 预订”提供可用性 Feed。
您的预订服务器必须实现实现预订服务器中列出的所有特定于等位名单的步骤。同时支持预订和候补名单的合作伙伴可以在其现有预订服务器中添加新方法。
“通过 Google 预订”会为预订服务器中的等位名单方法运行一组测试用例。

此图表介绍了在响应 GetWaitlistEntry 调用时必须在 WaitlistEntry.waitlist_entry_state 中报告的状态。该图表还会指明何时录制和填充 WaitlistEntry.waitlist_entry_state_times.*_time_seconds 字段以及何时向用户发送短信，通知他们他们已进入新状态。

以下是等位名单集成的常见使用场景以及针对它们的首选解决方案。

如果部分（但并非所有）人数不接受添加新候位名单人数（因为没有为这些人数等待），则允许在 BatchGetWaitEstimates 响应中为所有人数返回 WaitEstimates，并允许用户无需等待，即可加入这些人数的等位名单。返回一个具有 0 个 parties_ahead_count 和/或具有 0 个 start_seconds 且具有 0 个 end_seconds 的 party_size（无需等待）的 WaitLength
如果由于人数过长，有一个或多个人数不接受增加新的等位名单，则最好在 BatchGetWaitEstimates 响应中省略针对这些人数的 WaitEstimates。

这些方法为首选方法，因为即使商家的等位名单未完全开放，它们也会为用户提供选项。

如果预订服务器仅用于等位名单，请注意以下几点：

仅支持候位名单的合作伙伴不会向“通过 Google 预订”提供可用性 Feed。
仅支持等位名单的合作伙伴不会在其预订服务器中实现预订方法。而是按照实现候位名单实现说明实现预订服务器。
仅支持候位名单的合作伙伴无需向 Google 发送 API 调用请求。这意味着仅有等位名单的合作伙伴无需设置 Cloud 项目或提供开发者电子邮件地址。您无需完成实时 API 更新。不过，仍需向“通过 Google 预订”提供商家 Feed 和服务 Feed。

如果您的商家要求能够手动接受或拒绝 Google 增加的新候补名单，则您需要执行额外的步骤：

对于需要手动确认的人数，请在 wait_estimate 中将 waitlist_confirmation_mode 设置为 WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS。必须在 BatchGetWaitEstimateResponse 和 GetWaitlistEntryResponse 中设置。
用户已请求但尚未被商家接受的等位名单条目应处于 PENDING_MERCHANT_CONFIRMATION 状态。

Google 测试了以下用例，以确保您的预订服务器实现中的等位名单方法能够正常运行。Google 还会测试和监控延迟时间。通过这些测试后才能发布。

系统会针对 BatchGetWaitEstimatesRequest 中请求的每种人数返回等待估算值。
对于商家可以接受或拒绝新增等位名单的人数，请将 waitlist_confirmation_mode 设置为 WAITLIST_CONFIRMATION_MODE_ASYNCHRONOUS。

对于之前已启用等位名单但决定退出的商家，Google 希望能得到某些响应。