Click and collect
查看提货 workflow 的主页面。
什么是自动售货 click and collect
click and collect 看起来很简单，直到线上预订真正遇到线下取货。那时团队必须决定何时锁定库存、如何通知顾客，以及顾客到达时机器到底应该做什么。
这正是流畅体验与笨拙提货之间的分界线。关键不只是“先卖出去”，而是预留和释放逻辑必须在机器侧真正跑通。
自动售货里的 click and collect 真正意味着什么
它意味着机器是提货体验的一部分，而不只是支付或最后交付的末端。预留、确认和释放都必须理解订单状态。
所以不能只是把 ecommerce 接进来然后指望一切自然运转。机器必须清楚自己在 workflow 里负责哪一段。
- 机器直接参与提货
- 预留与释放必须共享同一订单状态
- 它不是“电商加一台柜子”那么简单
工作流通常在哪里变复杂
问题往往出在没人提前定义：顾客迟到怎么办、订单变更怎么办、库存是太早锁还是太晚锁。
这些细节一开始看似小事，但很快就会变成支持工单、失败订单和站在机器前发懵的顾客。
- 定义预留与过期规则
- 明确变更与延迟的处理方式
- 上线前先设计好提货体验
部署前买方应确认什么
应该确认如何通知顾客、如何确认提货、出错时机器显示什么，以及库存是否和订单状态同步。
这类评审通常也会顺带涉及 integrations、machine UX，以及项目到底只需要提货，还是更广的 hybrid fulfillment。
- 通知与提货确认逻辑
- 订单状态与库存同步
- 与集成和 hybrid fulfillment 的关系
怎么判断这个模式是否适合
最合适的场景，是预约提货能明显降低摩擦、提升便利，并让机器在客户旅程里承担清晰角色的时候。
如果逻辑依然含糊，项目往往更需要先做兼容性评审，或转向更广的 hybrid fulfillment 讨论。
- 机器角色必须清晰
- 顾客要真正感到便利
- 逻辑含糊通常意味着 workflow 还没定好
实施层面的含义
最稳妥的部署会把这个主题变成真实工作流，而不是营销词条。因此兼容性、报表、支付、责任归属和 rollout 节奏需要一起讨论。
这些答案越早被写清楚，项目后续的返工和跨团队误解就越少。
- 把它当成真实工作流
- 把产品、运营和兼容性放在一起看
- 在 rollout 前定义责任人与测试
买方检查清单
用它判断这个主题是否已经准备好进入真正的部署讨论。
- 定义何时锁定库存
- 说明订单过期、延迟和变更处理
- 确认通知与提货确认逻辑
- 检查库存与订单状态是否同步
- 如果项目已真实存在，就转到 click-and-collect、hybrid fulfillment 或 demo 评审
有用的下一步
当指南不再只是理论时，下一步通常就是进入 click and collect 主页面，或更广的 hybrid fulfillment 与集成讨论。
常见问题
它和普通 ecommerce 自提有什么不同？
不同在于机器直接参与提货，因此预留、确认和释放都要经过机器与其逻辑。
库存应该什么时候预留？
取决于商业规则，但必须在部署前定义清楚。
如果顾客迟到怎么办？
这应该在上线前由政策和软件逻辑决定，而不是上线后现场 improvisation。
正确的下一步是什么？
进入 click and collect、hybrid fulfillment 页面，或在项目已明确时转入集成评审。