预约按钮不是餐厅网站体验的终点
很多餐厅网站把预约按钮当成一条边界：顾客一点击，官网任务就算结束。实际运营里通常不是这样。跳转到第三方预约平台仍然属于顾客旅程的一部分，因为顾客还需要确认自己订的是哪家店、什么时间、什么服务，以及操作到底有没有成功。
一个好的预约交接应该回答四个问题：
- 我现在预约的还是刚才那家餐厅和那个门店吗？
- 日期、人数或者服务类型有没有正确带过去？
- 第三方平台失败时，我还能怎么办？
- 餐厅最后用什么证据判断预约真的完成？
这些答案取决于预约平台能够提供什么。官网不应该伪装平台并不存在的能力，但可以让跳转过程更可理解。
在离开官网之前先把重要条件讲清楚
顾客进入第三方平台之前，官网可以先解释门店、预约类型、取消政策、订金、无障碍情况和特殊服务要求。
例如，普通两人桌预约和 private dining enquiry 如果流程不同，就不应该共用完全相同的按钮。Tasting menu 需要订金，也应该在顾客进入付款页面前说明。Walk-in 可以接受但预约数量有限时，也应该放在预约入口附近，而不是藏在 footer。
目的不是把预约平台每一个字段复制一遍，而是避免顾客离开官网以后才发现关键条件。
把触摸目标和页面重排当成转化设计的一部分
顾客使用手机预约时，整条流程也需要保持可用。无障碍规范提供了具体检查标准，但它们本身并不能证明手机预约占比，或者预测转化提升幅度。
WCAG 2.2 关于 target size 的说明强调，触摸控件需要有足够可点击空间，尤其对手指操作、低视力或者精细动作困难的人更重要。Reflow 规范则要求普通内容在相当于 320 CSS pixel 的宽度下仍能使用，不应该被迫同时横向和纵向滚动，除非内容本身确实需要二维布局。
餐厅至少应该测试：
- 320px 宽度时预约入口是否正常；
- 日期和人数控件用手指是否容易操作；
- 键盘 focus 顺序是否合理；
- 错误提示能否指出具体问题；
- loading 状态会不会看起来像已经确认成功；
- 不只是测试官网，也实际检查跳转后的第三方页面。
整条链路的可用性，取决于其中最难用的那一步。
把预约点击和预约成功分开衡量
官网通常很容易记录“预约按钮被点击”，但这个事件只能证明意图，不能证明预约完成。
可以把证据分成几个层级：
| 事件 | 能证明什么 | 不能证明什么 |
|---|---|---|
| 看到了预约 CTA | 页面提供了行动入口 | 顾客真的想订位 |
| 点击预约 CTA | 顾客表现出意图 | 第三方平台正常加载 |
| 第三方 session 开始 | 跳转基本成功 | 预约已经完成 |
| 收到确认 | 创建了预约 | 顾客最终到店或消费 |
| 实际到店/履约 | 服务真正发生 | 这些收入全部由官网新增 |
这可以避免一个很常见的问题：把 outbound click 直接写成 booking conversion。
如果预约平台能提供确认事件、booking ID 或 server-side webhook，证据就更强。如果平台没有这些能力，就应该如实报告“点击”，而不是靠推测升级成“预约”。
跨域衡量只在真实支持时配置
餐厅官网和预约平台通常不在同一个域名。普通分析系统在跨域后可能重新开始一个 session。Google 关于 cross-domain measurement 的文档说明，如果几个域名确实属于同一个业务并且能够合法配置 Google tag，可以使用跨域机制延续测量。
但这不代表所有第三方预约平台都能这样做。有的平台不允许餐厅安装自己的 tag，也不能修改目标页面。在这种情况下，应使用平台真正提供的证据，比如 outbound click、referral、预约导出、API 数据或者第一方确认。
不要为了让 funnel 看起来连续，就牺牲隐私、安全或者平台规则。
不能通过假定权限或削弱隐私控制，让报告显得连续。
- 确认合法域名与标签权限
- 实际测试连续性，而不是默认存在
- 将外链点击称为点击
- 采用获准导出或确认记录
失败状态应该和成功状态一样认真设计
预约流程最常见的失败并不神秘：
- 选中的时间没有位置；
- 预约平台暂时不可用；
- 订金付款失败；
- 顾客中途关闭页面；
- 确认邮件延迟；
- 餐厅已经换平台，但旧链接还散落在其他页面。
网站需要提供恢复路径。可能是电话、其他日期、适合大团体的咨询表单，或者清楚告诉顾客重新尝试。最重要的是，不能因为顾客点击了按钮就显示“预约成功”。
一个很实用的测试方式，是每测一次正常路径，也测一次失败路径：
- 在手机上打开官网；
- 点击预约；
- 模拟第三方失败或者无库存；
- 检查顾客是否知道发生了什么；
- 检查分析系统有没有错误记录成功事件。
这类测试的成本很低，却能避免真正顾客用投诉来发现问题。
备用路径要让人理解状态，而不是假装已经占用预约名额。
- 01说明失败
区分没有空位与平台故障。
- 02保留必要上下文
保留安全选项，不暴露个人资料。
- 03提供真实替代
只使用商家实际能够响应的联系渠道。
- 04核实结果
重试或电话点击不等于确认。
换预约平台之前先定义一份 measurement contract
餐厅更换预约平台时，往往主要比较费用、桌位管理和客户资料。官网接入部分也应该有一份很短的 measurement contract。
至少写清：
- 每个门店和服务的 canonical booking URL；
- 离开官网前记录哪些事件；
- 第三方能提供哪些确认事件；
- 最终预约如何核对；
- UTM 或 campaign naming 谁负责；
- 哪些顾客数据明确不收集；
- 旧链接什么时候、由谁移除。
这让后续迁移更安全，也避免 agency、预约平台和餐厅经理对 conversion 各有一套定义。
性能和确认质量需要一起看
速度快确实能帮助顾客更快到达预约入口，但 Core Web Vitals 或加载速度本身不能证明预约流程成功。真正的业务结果还取决于顾客是否到达一个可信的 confirmation state。
所以我们的 餐厅预约转化 pillar 会把性能、信息清晰度和衡量放在同一个系统里。一个加载很快但已经失效的预约链接，并不是转化优化。
一份实际可用的预约交接 QA 清单
上线前，或者每次更换平台以后检查：
- 每个预约链接都进入正确餐厅和正确门店；
- 手机窄屏下控件仍然好用；
- 订金、取消政策和特殊要求在跳转前说清楚；
- loading、error 和 confirmation 三种状态不会混淆；
- outbound click 使用稳定事件名称；
- 只有真正支持时才做跨域跟踪；
- 能获得平台或第一方证据时，再报告完成预约；
- 第三方失效时有电话或咨询 fallback；
- Business Profile、旧 landing page、导航和广告里的旧链接都被清理；
- 测试预约有记录并及时取消，避免污染真实运营数据。
更前面的发现阶段，可以回到 餐厅预约转化 pillar 和 手机菜单短指南 继续阅读。
顾客应该感觉预约是一条连续路径，即使背后用了多个系统。我们的衡量也应该一样诚实：每个系统能证明到哪里，数据结论就停在哪里。
