Kiosk、Yield、Marketing 与硬件试点验收

当门店准备从软件测试进入受控的真实世界试点时使用本指南。Docker 健康或构建成功，并不能证明实体 Kiosk、真实门店数据、Email Provider 或已安装设备在现场可用。

注意

每次只验收一个明确的门店、版本和时间窗口。遇到跨店数据、未同意的邮件、凭据泄露、错误财务状态或无法清除的客户数据时立即停止。BLOCKED 与 NOT RUN 必须如实记录，不能改写为 PASS。

开始前记录

• 试点 ID、环境、Git SHA/镜像标签与门店时区；
• 明确 Tenant、Store、操作员与最终批准人；
• 数据是合成数据、员工测试数据，还是已批准的代表性门店数据；
• 适用时记录设备型号/OS、Email Provider 与设备管理方式；
• 回滚负责人、证据位置与事故联系人。

截图和普通支持消息不得包含客户联系方式、意图/健康文字、设备凭据或 Provider 密钥。

Kiosk

1. 在真实安装设备的受管/全屏模式中运行。
2. 完成当天预约、意图/人体图输入和到店付款确认。
3. 添加两条 Sale line，删除其中一条，并与 POS 领取后的 Sale 金额核对。
4. 中断网络后重试；handoff 只能领取一次，重复或过期领取必须被拒绝。
5. 完成并重置后，验证后退/前进、自动填充和断电恢复都不会显示上一位客户数据。
6. 检查 EN、中文、ไทย、真实触控目标、坐姿触达和短状态码流程；状态不得显示技师、队列位置或等待时间承诺。

柜台 Sale 流程见销售与结账。

Yield Intelligence

1. 确认门店具有代表性预约、服务能力、排班、请假、工位配置与 denied-demand 记录。
2. 在 Admin → Roster → Coverage Planner 分别运行 7 天和 14 天窗口。
3. 将预约需求、denied-demand、缺口日和建议数量与该精确门店的来源记录核对。
4. 切换门店/窗口，确认旧结果或迟到响应不会覆盖当前结果。
5. 店长逐条复核建议。是否应用一条建议是可选的人工作业，仍要求 roster.schedule.manage；规划器不会自动改排班。

记录有用、拒绝、误报与漏报建议。不要把规划器解释为工资、Award、资质、收入或自动用工建议。见预约与排班。

Email Marketing

当前只有 Email 可运营。没有获批的发件人、Provider、同意文案与明确同意的测试人群，不得开始。

1. 在 Admin → 客户生命周期营销 确认精确门店与 Channel readiness。
2. 生成一个固定生命周期候选，复核聚合人群，编辑并由独立人员批准后再排期。
3. 发送前撤回一名测试收件人的同意，证明该地址不发送，而其他获批收件人可继续。
4. 只记录脱敏后的 MMOS delivery ID 与 Provider 结果；不得记录 API key 或完整收件人列表。
5. 测试签名退订链接和后续 Email 地址变更；冻结的投递地址与当前地址都必须继续被抑制。
6. 禁用 Email 后，新准备和已准备投递都必须在 Provider egress 前停止；WhatsApp、WeCom 与 SMS 仍不可用。

见营销自动化。

商城、硬件与设备

1. 提交一笔真实但受控的报价/订单，核对冻结商品、备注和状态历史；状态不得表示已经付款或发货。
2. Super Admin 人工审核/报价，Tenant 明确确认。
3. 将实体资产登记并分配到精确 Tenant/Store。
4. Kiosk 硬件履行时，把一次性凭据直接存入获批的设备密钥库，并证明关闭后无法回读。
5. 注册设备并发送 heartbeat，核对期望软件/配置；只在受控设备测试获批的 update、restart 或 maintenance。禁止远程 shell、摄像头、麦克风与客户监控。
6. 准备 Hardware Support handoff，再由人员明确提交和推进工单；handoff 本身不得自动提交。
7. 附上实体安装、网络恢复、受管模式、商业条款、物流与 EMM/MDM 证据；缺失项必须标为 BLOCKED/NOT RUN。

见平台商城与硬件支持。

签署

每个步骤使用 PASS、FAIL、BLOCKED、NOT RUN 或 NOT APPLICABLE，并记录证据、负责人和复测日期。店长与技术负责人签署精确门店/版本/窗口；Marketing/Privacy 和 Platform Owner 还需签署其管辖轨道。附条件批准必须写明到期日，不能复用于其他门店、版本、Provider 或设备型号。