120 lines
6.5 KiB
Markdown
120 lines
6.5 KiB
Markdown
# 宠小它试点门店开通清单
|
||
|
||
> 目标：让 3～5 家独立宠物洗护单店用真实业务完成约 200 次“预约 → 服务 → 报告 → 查看/回访 → 再次预约”闭环，以数据决定 Phase 2 是否进入商业化。本文是开通和验收清单，不代表任何门店已经开通。
|
||
|
||
## 1. 试点准入
|
||
|
||
每家门店必须满足：
|
||
|
||
- 有一名可决策的老板和一名日常负责人，接受至少 4 周连续试用；
|
||
- 主要业务是宠物洗护/美容，愿意把真实预约和服务报告录入系统；
|
||
- 明确同意试点数据用途、照片/视频告知方式、数据保留与退出处理；
|
||
- 可配置真实营业时段、同时接待数、服务项目和预计时长；
|
||
- 有可用手机/电脑、稳定网络和微信小程序使用条件；
|
||
- 接受上线首周每日反馈、之后每周复盘，不要求支付、库存、储值、复杂会员、多门店组织等本期外能力。
|
||
|
||
不满足隐私告知、负责人、真实业务量或反馈承诺的门店，不进入试点。
|
||
|
||
## 2. 门店建档卡
|
||
|
||
每店单独保存，敏感信息进入权限受控系统，不写入公开文档或提交记录：
|
||
|
||
| 项目 | 填写要求 |
|
||
|---|---|
|
||
| 试点门店编号 | 使用内部编号，不用公开昵称代替主键 |
|
||
| 老板 / 日常负责人 | 姓名、联系方式、可响应时间（受控保存） |
|
||
| 预计周服务量 | 用于判断 200 次样本达成时间 |
|
||
| 营业日与营业时段 | 精确到半小时容量桶 |
|
||
| 同时接待数 | 1～10，必须与现场工位/人力真实匹配 |
|
||
| 服务项目 | 名称、预计时长（30～480 分钟，30 分钟倍数） |
|
||
| 员工名单 | 最小必要账号；离职/退出当天停用 |
|
||
| 门店 logo/电话/地址 | 宠主公开页允许展示的内容，经门店确认 |
|
||
| 素材告知方式 | 何时向宠主说明拍摄、报告链接和转发风险 |
|
||
| 支持群与升级联系人 | 产品、技术、隐私各自 owner |
|
||
| 上线日期 / 退出日期 | 明确试点窗口和退出处理 |
|
||
|
||
## 3. 开通前配置
|
||
|
||
- [ ] 创建门店和 boss，首次登录后更换/确认安全登录方式。
|
||
- [ ] boss 创建最小必要 staff；customer 不能进入 admin。
|
||
- [ ] 核对门店公开字段，不展示邀请码、ownerId 等内部信息。
|
||
- [ ] 配置营业开始、最后容量桶和真实 `bookingCapacity`。
|
||
- [ ] 配置全部在售服务项目及 `durationMinutes`；不使用笼统默认时长掩盖差异。
|
||
- [ ] 建立午休/停约 `blocked` 与到店客 `walk_in` 的操作约定。
|
||
- [ ] 用未来一天验证：长服务覆盖全部时段、超容量不可约、取消后释放容量。
|
||
- [ ] 清除 demo 门店/万能验证码/测试宠主和无效服务项目；测试记录与真实数据可区分。
|
||
- [ ] 确认报告前后照片最少各一张、服务过程素材可选、报告提交后锁定。
|
||
- [ ] 告知员工：完整报告 token、手机号和媒体链接不得贴入群聊、工单或截图。
|
||
|
||
## 4. 上线日三角色验收
|
||
|
||
### Boss
|
||
|
||
- 登录 admin，查看工作台、预约、客户、日程、报告、线索和设置；
|
||
- 新增/停用一个试点员工；确认跨店数据不可见；
|
||
- 调整一个服务时长或容量配置，并由第二人复核；
|
||
- 确认当天异常处理和人工回退联系人。
|
||
|
||
### Staff
|
||
|
||
- 按手机号关联真实宠主做一次代客预约，员工身份不被写成宠主；
|
||
- 开始服务、上传前/过程/后素材、提交报告并发送给宠主；
|
||
- 验证重复报告、缺照片、非法状态迁移均被拒绝；
|
||
- 在日程中登记一次 `walk_in`，必要时登记一次 `blocked`。
|
||
|
||
### Customer
|
||
|
||
- 扫门店入口，选择服务和可约时段，提交预约；
|
||
- 打开报告公开页，确认门店与宠物信息准确且没有内部字段；
|
||
- 提交提醒留资，重复提交不生成重复线索；
|
||
- 从报告页再次预约，验证门店和服务上下文连续。
|
||
|
||
## 5. 试点期支持节奏
|
||
|
||
- 上线前 2 天：完成培训、模拟全链路、回滚演练和联系人确认。
|
||
- 上线第 1～3 天：每日核对预约、完成、报告、报告打开、留资和失败记录。
|
||
- 第 2 周起：每周一次 30 分钟复盘，先解决阻塞履约的问题，不以新增页面代替流程修复。
|
||
- 严重权限/隐私/数据错误：立即停用相关入口并升级；容量或状态脏数据：暂停新增预约直至核对完成。
|
||
- 门店退出：停用账号和入口，按约定导出/保留/删除数据，并记录完成证据。
|
||
|
||
## 6. 200 次完整服务的统计口径
|
||
|
||
“一次完整服务”必须同时满足：
|
||
|
||
1. 有真实 `Appointment`，客户身份和创建人语义正确；
|
||
2. 合法 `new → doing → done`；
|
||
3. 有且仅有一份绑定报告，至少包含服务前/后照片；
|
||
4. 报告已产生可发送链接；
|
||
5. BusinessEvent 可追溯预约创建、服务开始、服务完成/报告提交。
|
||
|
||
样本按门店、服务类型、创建来源（customer/staff/boss）分层，测试预约、取消预约、重复数据和纯演示数据不计入 200 次。
|
||
|
||
## 7. 每周指标
|
||
|
||
| 指标 | 口径 | 用途 |
|
||
|---|---|---|
|
||
| 完整服务数 | 符合上方五项的服务 | 判断样本进度 |
|
||
| 预约完成率 | done / 有效预约 | 判断主链路稳定性 |
|
||
| 报告提交率 | 有报告的 done / done | 判断员工执行成本 |
|
||
| 报告打开率 | 首次打开报告 / 已提交报告 | 判断宠主价值 |
|
||
| 留资率 | 去重留资 / 首次打开报告 | 判断回访意愿 |
|
||
| 再次预约率 | 报告后窗口内产生新预约的 StoreCustomer / 可观察客户 | 判断闭环价值 |
|
||
| 容量冲突率 | 因无容量被拒绝的请求 / 可约请求 | 校准容量而非承诺零等待 |
|
||
| 人工救援率 | 需技术/运营改数据或绕流程的服务 / 完整服务尝试 | 判断是否可规模化 |
|
||
| P0 故障数 | 权限、数据、主链路阻断 | Go/No-Go 硬门槛 |
|
||
|
||
指标只使用最小必要业务 ID 和聚合数；周报不展示完整手机号、token 或私密媒体 URL。
|
||
|
||
## 8. 阶段退出标准
|
||
|
||
进入 Phase 2 决策评审前，至少满足：
|
||
|
||
- 3～5 家门店真实运行，累计约 200 次完整服务；
|
||
- 连续两周无未解决的 P0 权限、隐私或数据一致性事故；
|
||
- 核心链路不依赖开发者直接改库或手工补状态；
|
||
- 老板与员工能独立完成日常预约、服务、报告和回访；
|
||
- 再次预约闭环有可统计证据，而不是仅有页面或口头反馈；
|
||
- 各门店的继续使用意愿、付费假设和主要阻碍被记录。
|
||
|
||
未满足时继续修复产品内核，不提前引入支付、库存、储值、复杂会员、多门店组织或泛 AI。
|