北京
按例披露：我目前就职于 Cal ID，负责 WhatsApp 预约功能。我们上线该功能已经有一段时间了，下面这些坑都是在这个过程中踩到的。
“让用户不离开 WhatsApp 就能完成预约”听起来是个小功能，但实际上不是。WhatsApp 并不是为预约场景设计的，很多你以为能用的能力，要么根本不工作，要么会用一种安静的方式生成错误数据。其中大部分问题，我们是上线之后在生产环境里用昂贵代价发现的。
下面按消耗时间排序，列一下这些问题。
最痛的是这一个：WhatsApp Flows 在桌面端不渲染，而 API 却告诉你一切正常。
WhatsApp Flows 原本是体验最好的路径：聊天窗口内直接出现表单、原生日期选择器、真实输入框，用户不需要靠自然语言输入。所以我们把预约体验构建在 Flows 上。
然后桌面用户开始报告“点了没反应”。Flows 不支持 WhatsApp Desktop 或 Web，这本身是文档化的平台限制。真正的问题是，当你向桌面用户发送 Flow 时，发送接口返回 200。API 接受了你的消息；从服务器角度看，Flow 成功启动了。没有报错、没有 webhook、没有任何投递级别的信号来告诉你：用户面对的是一条根本无法交互的消息。
我们原本有一个失败时触发的回退方案，但它从未被触发过，因为从未发生过“失败”。现在的做法是混合启动：先发 Flow，紧接着补发一条纯文本消息，提供在聊天内完成的替代路径。如果用户回复“菜单”“这里预约”或“在聊天中预约”，我们就完全跳过 Flows，改走旧的基于文本的对话流程。
因此我们现在同时维护着两套完整的预约实现。这个方案并不优雅，但它是唯一可行的做法——因为你无法从 API 检测到这种失败场景。
如果你基于 Flows 做开发，请同时把文本回退方案做好。不要以后再说，不要把它当作 stretch goal。上线那天，一定会有一定比例的用户面对一条无法操作的“成功消息”。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
