此页面由 Cloud Translation API 翻译。

概览

参与预订等位名单计划的合作伙伴必须在开始前完成帐号设置。但是，一般指南中的某些步骤对于使用候位名单功能而言并不是必需的。本页中的指南介绍了有意使用“通过 Google 预订”上的等位名单功能的合作伙伴需要执行哪些步骤。我们建议您先阅读本概览，然后再完成集成步骤。

发布流程

图 1 概述了在 Actions Center 中发布已启用候位名单的商家的流程。

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

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

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

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

以下是预订候位名单集成中常见的极端情况，以及相应的首选解决方案。

如果部分（但不是所有）人数不接受增加新的候位名单人数（因为无需等待这些人数），则在 BatchGetWaitEstimates 响应中返回所有人数的 WaitEstimates，并允许用户无需等待即可加入这些人数的等位名单。对于无需等待的 party_size，返回 parties_ahead_count 为 0 的 WaitLength 和/或 start_seconds 为 0 且 end_seconds 为 0 的 estimated_seat_time_range
如果因等待时间过长而不接受添加新的等候名单人数，则首选在 BatchGetWaitEstimates 响应中省略这些人数的 WaitEstimates。

建议采用这些方法，因为即使商家的等候名单可能未完全开放，但也能为用户提供选项。

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

仅支持预订等位名单的合作伙伴不会向“通过 Google 预订”提供可用性 Feed。
仅支持预订等位名单的合作伙伴不会在预订服务器中实现预订方法。而是应该按照候位名单实现的说明实现预订服务器。
仅支持预订等位名单的合作伙伴不会向 Google 发出 API 调用。这意味着，仅支持预订等位名单的合作伙伴无需设置云项目或提供开发者电子邮件地址。您无需完成实时 API 更新。不过，仍需向 Actions Center 提供商家和服务 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 希望之前已启用等位名单功能但现已决定停用的商家能够做出特定回应。