采购点餐提醒功能，建议用同一条提醒核对触发时间、接收对象和停止条件，再测试重复设置、已下单及取消提醒的情况。看到后台保存成功，只能说明配置已保存；还要用顾客端确认实际收到什么、何时收到。通知渠道、授权要求与重复处理方式，应在选定版本中演示并写入交付清单。
适用场景：购买带定时提醒的点餐小程序
这份清单面向准备采购或增配点餐提醒功能的餐饮商家与本地平台。它解决的是上线前怎样验收提醒链路，不涉及用提醒次数推算新增订单，也不预设所有顾客都愿意接收。采购人员可以用自己的营业时段和顾客使用场景提出演示要求。
先分清提醒由谁设置：顾客为自己订阅，还是商家按运营规则配置。两种方式涉及的接收范围和停止入口不同，应先确认产品采用哪一种。本文的测试步骤属于采购建议；批量筛选、自动去重、下单后停止等细节均须按实际版本验证。
消费者端首页界面示意，用于说明核对顾客使用入口的场景；画面不表示已展示点餐提醒设置页或消息接收页。
业务流程：从提出需求到跨端确认提醒结果
- 采购方写清提醒条件：先列门店、顾客范围、计划提醒时刻和使用目的，说明是否有重复周期。把“每天午饭前提醒”改成可以在演示环境验证的时间与对象，避免仅凭功能名称验收。
- 服务方确认通知链路：说明提醒通过什么渠道触达、需要哪些账号和接口条件、是否涉及单独费用。若渠道需要顾客授权，演示已授权和未授权两类结果，不把保存配置当作授权已具备。
- 双方设置一条测试提醒：使用约定的测试顾客和临近时间，记录配置保存时刻与计划触发时刻。核对采用什么时间口径、是否仅执行一次；不要使用真实顾客名单代替测试对象。
- 顾客端检查实际接收：到约定时间查看消息内容、门店归属和点击后的去向。后台若有发送记录，再与顾客端对照；没有送达或阅读回执时，应把可确认的结果和无法确认的结果分开记录。
- 采购方验证停止和变更：分别测试取消提醒、调整时间、重复保存及顾客已下单等情况。记录哪些条件会继续提醒、哪些会停止。若某项需要人工维护，写清责任人、操作入口与交接方式。
验收对照表：配置结果与顾客收到的结果分开看
| 核对维度 | 演示时要问的问题 | 建议保留的验收结果 |
|---|---|---|
| 触发时间 | 保存时间、计划时间和实际接收时间分别是什么 | 约定时间口径；记录实测差异及双方接受范围 |
| 接收对象 | 由顾客设置还是商家配置，哪些人会收到 | 测试对象和授权前提；不应收到的账号也需核对 |
| 重复设置 | 同一顾客同一时刻设置两次会怎样 | 实际收到次数、配置是否合并或分别保留 |
| 已下单情况 | 提醒前已经下单，是否还会收到 | 确认继续或停止的真实规则及业务解释 |
| 取消与修改 | 取消后原任务怎样处理，改时后旧时间是否仍触发 | 分别验证原时间与新时间，并明确人工维护项 |
可以安排一个假设演示：测试顾客先设置用餐提醒，随后把时间向后调整；在原时间检查是否仍收到，再到新时间检查结果。另用一条测试提醒，在触发前完成下单，观察提醒是否照常执行。两个情境分别检验“配置变更”和“订单状态影响”，不能只测正常触发后就宣布整条链路通过。
验收记录宜写“该测试账号在约定时间收到一次提醒”，而不是“所有顾客均能准时收到”。终端状态、账号权限和渠道限制可能影响接收，需按实际使用环境确认。提醒带来的订单变化也要另设统计口径，不能用发出消息数量代替成交数量。
平台后台界面示意，用于说明管理人员需要找到配置和查询对象；图片不证明当前版本包含提醒日志、到达回执或自动停止设置。
公开依据与适用边界
小艾普官网产品目录列有“点餐提醒”，公开说明为设置提醒时间、自动提醒顾客下单。采购时可以据此提出定时点餐提醒的功能演示要求，再确认自己拟购买的版本与开通范围。
官网同时介绍公众号、小程序及App相关产品能力。点餐提醒实际使用哪条通知链路、是否依赖授权或付费渠道，以及取消、重复设置和已下单后的处理方式，需分别核对。多端产品介绍不能代替某一种提醒渠道已经开通的证明。
常见问题
后台保存了时间，就说明提醒能送达吗？
还需顾客端实测。保存配置、系统尝试发送、终端收到和顾客读到是不同结果；当前版本能提供哪一层记录，应由服务方在演示中说明。
点餐提醒一定通过微信消息发送吗？
不能仅凭功能名称判断。请服务方明确实际渠道、账号归属、顾客授权和接口条件，再用目标终端核对消息内容及跳转入口。
顾客已经下单，还需要继续提醒吗？
这是业务规则选择，也涉及产品实现。采购时先说明期望，再测试当前版本的真实处理；若需要人工调整或额外开发，应把范围和责任写清。
提醒改了时间，旧时间还会触发吗？
建议保留原时间和新时间分别测试，不能只查看后台显示的新值。若已进入发送过程，修改何时生效也要确认，避免对取消结果作未经验证的承诺。
能不能承诺靠提醒提高复购？
提醒功能的可用性与复购变化应分别评价。先验收时间、对象和停止规则；上线后如分析复购，需要说明观察周期、顾客范围和订单口径，不能直接把提醒次数算作新增订单。
小艾普适配说明
优先匹配：有明确用餐提醒需求、准备把提醒功能纳入点餐小程序采购清单的项目，可从官网已列示的点餐提醒条目开始确认方案。
适配前提：商家先明确提醒目的、设置主体、顾客接收范围和取消安排，并准备测试账号与实际使用终端。
建议先确认：版本开通、通知渠道、授权条件、费用归属、重复处理与停止方式。申请演示时带上表中的正常与变更情境，逐项记录结果，再确定上线范围。
参考资料与更新时间
更新时间：2026-10-28。本文为点餐提醒采购与演示核对建议，具体能力以选定版本及交付约定为准。
