# 门店管理后台升级方案（对标宠老板 · 差异化落地）

> 参考：[宠老板介绍页](https://www.chonglaoban.cn/about/chonglaoban) · [宠老板官网](https://www.chonglaoban.cn/)  
> 状态：产品草案（仅文档，未进入编码）  
> 日期：2026-07-10  
> 对齐：`docs/.agents/common-context.md`、本体 P1/P2 gap 占位、`架构与产品评估报告-2026-07-05.md`

---

## 1. 一句话结论

**不要照搬宠老板做「全店收银进销存 ERP」**；应做 **「服务经营后台」**：把宠小它已跑通的预约 → 服务 → 报告 → 成片 → 留资闭环，升级为老板可在 **PC/平板 Web 后台** 高效管店，并在此基础上按阶段补 CRM / 经营看板 / 会员套餐。

宠老板赢在「店内交易与库存」；宠小它应赢在「服务体验与复购触达」。后台是放大器，不是换赛道。

---

## 2. 宠老板能力拆解（对标对象）

来源：官网「系统介绍 / 宠老板介绍」公开卖点。

| 模块群 | 代表能力 | 本质 |
|--------|----------|------|
| 基础 | 收银、会员、库存、店铺/分店/店员、积分、寄养、活体/商品销售 | 店内交易 + 进销存 + 多业态 |
| 智能 | 统计报表、流水、账本、提醒、预约、提成、决策助手、微信推送 | 经营分析 + 激励 + 触达 |
| 增值 | 进货商城、微店/小程序商城、宠付宝、短信、推广工具 | 支付 / 供应链 / 营销平台 |
| 形态 | Windows/Mac/iOS/Android 收银与移动端；云端连锁；公众号+小程序 | 多端收银一体 |

**他们的主叙事**：高效管店、收银结账、库存盘点、寄养结算、连锁调拨、手机看店。

---

## 3. 宠小它现状（我们已有什么）

| 能力 | 现状 | 载体 |
|------|------|------|
| 预约状态机 / 号源 / 排班占用 | ✅ | 小程序门店端 |
| 服务报告 + 前后照片 + 成片 | ✅ 差异化核心 | 小程序 + 公开 H5 |
| 报告分享 / 打开埋点 / 留资回访 | ✅ 部分 | 公开页 + Leads |
| 门店设置 / 员工 / 服务类型 | ✅ 基础 | 小程序「我的」 |
| 会员卡 / 储值 / 套餐 | ❌ gap 占位 | 本体未展开 |
| 收银 / 库存 / 寄养 / 提成 / 进货 | ❌ | 明确不在 P0 |
| **独立 Web 门店管理后台** | ❌ | 老板只能在小程序里点 |

痛点：老板在手机小程序里做「经营管理工作台」效率低（列表筛选弱、多开对比难、报表难看、批量操作弱）。这正是「搞一套门店管理后台」的第一性需求，而不是先上收银。

---

## 4. 定位对比（必须先定）

```text
宠老板：店内交易操作系统（POS + 进销存 + 会员资产）
宠小它：服务体验与复购操作系统（预约履约 + 报告内容 + 触达转化）
```

| 维度 | 宠老板 | 宠小它应坚持 |
|------|--------|--------------|
| 核心对象 | 订单/SKU/库存/会员余额 | 预约/报告/成片/线索 |
| 老板日常 | 收银、盘点、寄养结算 | 排班接单、出报告、看转化、回访 |
| 宠主触点 | 微店商城、消费通知 | 报告页、预约、提醒、口碑成片 |
| 差异化 | 行业全功能 + 进货商城 + 保险 | **洗美报告成片 + 分享转化**（对方没有的主线） |
| 风险 | 功能面极宽，我们短期做不全 | 若跟风收银库存，会稀释主线且工期爆炸 |

**建议对外话术**：  
「宠小它门店后台 = 洗美服务经营台；不是又一个宠老板。」

---

## 5. 门店管理后台：建议形态

### 5.1 产品形态

| 项 | 建议 |
|----|------|
| 形态 | **Web 管理端**（桌面优先，平板可用）；与现有 uni-app 小程序并存 |
| 登录 | 复用现有 `sessionToken`；**boss / staff 均可进且可编辑**本店（customer 禁止）；删店/员工管理等仍仅 boss |
| 数据范围 | 严格 `store_id`；首期单店，连锁/分店放到更后 |
| 技术倾向（待架构拍板） | 独立 `admin` 前端（Vue/React + 中后台组件库）调现有 `/api/**`；少造第二套业务规则 |
| 不做什么（首期） | 原生收银硬件、钱箱小票机、进货商城、活体交易、保险、宠付宝 |

### 5.2 信息架构（IA）草案

```text
门店后台
├── 今日工作台          # 今日预约、进行中、待出报告、留资待回访、成片失败
├── 预约与排班          # 日/周视图、号源、手动占用、改派/取消
├── 服务报告            # 列表、详情、成片状态、重新生成、分享链接管理
├── 客户与宠物          # 宠主/宠物档案（服务过的）、历史报告入口
├── 回访线索            # Leads 池、提醒日期、退订状态、跟进备注（可后补）
├── 经营数据            # 打开率、成片成功率、留资转化、预约完成率（依赖埋点落地）
├── 门店设置            # 资料、营业时段、服务类型、员工与邀请码
└──（后期）会员与资产    # 次卡/储值/套餐 — 对标宠老板会员，但不做库存
```

小程序保留：**到店履约现场操作**（拍照、填报告；亦可开始服务）。  
Web 后台主攻：**经营、检索、批量、报表、设置**；**允许「开始服务」**（`new→doing`），拍照/填报告仍引导回小程序。

---

## 6. 分阶段路线图（强烈建议按此砍）

### Phase A — 管理台 MVP（优先做，4–8 周量级视人力）

**目标**：老板愿意每天打开 Web 后台，而不是只在小程序里翻。

| 模块 | 能力 | 依赖 |
|------|------|------|
| A1 工作台 | 登录落点；「今日待办」弹层（预约/待报告/成片异常/待回访）+ 顶栏 4 指标卡；卡片下钻列表 | 现有 API 聚合 |
| A2 预约中心 | 列表筛选（状态/日期/技师）、详情、取消/开始（权限同现网） | Appointment* |
| A3 报告中心 | 报告列表、公开链接复制、成片三态、触发重生成 | Report* / Highlight |
| A4 线索中心 | 回访池、脱敏展示、建议日期 | ReportLead* |
| A5 设置中心 | 门店资料、营业时段、服务类型、员工 | Store/User/ServiceType |
| A6 排班 | 日视图 + 手动占用 | Schedule* |

**验收**：老板用 PC 完成「看今日单 → 查报告链接 → 处理一条留资 → 改营业时间」，无需打开小程序。

**刻意不做**：收银、库存、会员储值、提成、连锁。

### Phase B — 经营增强（对齐原 P1）

| 模块 | 能力 | 对标宠老板哪块 |
|------|------|----------------|
| B1 埋点可统计 | 报告打开/再打开、成片成败、播放/保存、留资 | 统计报表（子集） |
| B2 经营看板 | 日/周：预约完成率、报告发送率、打开率、留资转化 | 数据分析 |
| B3 智能提醒 | 建议洗护到期、留资到期未跟进 | 智能提醒 |
| B4 客户档案增强 | 宠主合并规则、宠物疫苗/驱虫字段（可选轻量） | 会员/宠物档案（轻量） |
| B5 消息触达 | 订阅消息/模板去重（与公众号文档对齐） | 微信推送 |

### Phase C — 选择性「宠老板化」（原 P2，需单独立项）

仅在 A/B 稳定、数据口径清楚后评估：

| 候选 | 建议 | 理由 |
|------|------|------|
| 次卡 / 套餐 / 储值 | 可做 | 与洗美复购强相关；本体已有 gap 占位 |
| 技师提成 | 谨慎 | 规则复杂，易扯皮；可先「按单人工核算导出」 |
| 寄养结算 | 不做或独立产品线 | 业态不同，会拖垮主线 |
| 商品库存 / 进销存 | 默认不做 | 与内容/服务差异化无关；竞品极强 |
| 收银 / 宠付宝类 | 默认不做 | 支付合规与硬件成本高 |
| 连锁分店 / 调拨 | 很后 | 先把单店后台做透 |
| 微店商城 | 不做标配 | 我们已有小程序预约+报告；商城是另一场战争 |

---

## 7. 功能对标矩阵（决策用）

| 宠老板能力 | 宠小它态度 | 落点阶段 |
|------------|------------|----------|
| 收银管理 | 不做 | — |
| 会员管理 | 后期轻量（次卡/档案） | C |
| 库存 / 进货商城 | 不做 | — |
| 寄养管理 | 不做（除非单独立项） | — |
| 店员管理 | 已有 → 迁到 Web | A |
| 分店 / 连锁 | 暂缓 | C+ |
| 积分系统 | 暂缓 | C |
| 预约管理 | 已有 → Web 强化 | A |
| 统计报表 / 流水 | 做「服务经营指标」非流水账 | B |
| 提成计算 | 暂缓 | C |
| 微信推送 | 与现有触达文档合并 | B |
| 微店小程序商城 | 不跟风；强化报告+预约 | — |
| 活体交易 / 保险 | 不做 | — |
| **服务报告成片分享** | **我们独有，后台要管好** | A 核心 |
| **留资回访** | **我们独有主线，后台要管好** | A 核心 |

---

## 8. 与现有文档 / 本体的关系

| 已有条目 | 后台如何消费 |
|----------|--------------|
| `entity:appointment` / `report` / `report_lead` | A 期列表与工作台主数据 |
| `entity:analytics_dashboard`（gap） | B 期落地为真实看板实体 |
| `entity:membership` / `stored_value` / `service_package`（gap） | C 期再展开字段 |
| P1-4 埋点可统计 | B1 的前置条件 |
| P2-5 经营分析看板 | 并入后台 B2，不再单独飘着 |

**协作约束**：

- 本期若启动后台，需新建 Workstream（建议 Owner：`Store Admin FE` + `Backend Core`），写入 `.agents` 角色锁后再编码。
- 产品说明默认只改 `docs/`；实现须用户明确「做后台 / 改代码」。
- 禁止把收银库存写进 P0 完成口径。

---

## 9. 推荐下一步

**本体状态**：Phase A 后台概念已写入 ontology（`entity:admin_console` / `workbench` / `store_customer`，`rule:BR-ADMIN-001`…`004`，`action:view_workbench` 等）；其中 `store_customer` 已落为稳定 JPA 主档，其余读模型按实现状态为准。

下一文档步骤：~~用上述 ontologyRefs 写 Phase A 页面清单 PRD~~ → **已完成**：`docs/门店管理后台-PhaseA-页面清单PRD.md`

再下一步：

1. ~~按 PRD 出线框说明~~ → `docs/门店管理后台-PhaseA-线框说明.md`  
2. ~~评估技术选型~~ → `docs/门店管理后台-技术选型草案.md`（推荐 Vue3 + Element Plus + `admin/`）  
3. ~~拆编码任务 brief~~ → `docs/门店管理后台-PhaseA-编码任务brief.md`（**待用户授权编码**）  
4. **坚持要对标收银/库存** — 需单独商业论证（受 `BR-ADMIN-004` 禁止）  

**当前阻塞编码的唯一条件**：用户明确要求「改代码 / 实现后台」。

---

## 10. 风险

| 风险 | 说明 |
|------|------|
| 范围膨胀 | 「参考宠老板」极易变成两年 ERP；必须用 Phase 闸门 |
| 双端规则分叉 | Web 与小程序必须共用同一套 Service 规则与本体 |
| 过早做会员储值 | 无稳定预约/报告数据时，储值会变成另一套半成品 |
| 忽视差异化 | 后台若只模仿收银，会丢掉成片/留资这个真正壁垒 |

---

## 11. 截图研读纪要（2026-07-10 · 宠老板近期升级说明）

> 素材目录：`docs/refs/chonglaoban-upgrade/`（11 张，来自对方「会员等级」相关升级说明）  
> 这批图**不是**工作台/预约首页，而是 **客户中心 + 会员等级体系 + 收银台 + 权限** 的深水区。说明对方近期迭代重心在「会员资产与等级规则」，不是服务报告。

### 11.1 截图覆盖了什么

| 页面 | 看到的能力 | 对我们的含义 |
|------|------------|--------------|
| 会员等级配置 | 计算方式（累计消费/积分/储值充值）、滚动窗口（近 12 自然月等）、付费升级/自动升级/自动降级、升降级阈值缓冲、等级优惠/升级礼包、有效期 | **完整 CRM 会员引擎**；规则密度极高，属 Phase C 量级 |
| 会员卡模板 + 规则说明 | 有效期重置、礼包只发最高档、退款 7 天回滚校验、每日凌晨批处理、**同步规则至多店** | 连锁配置分发；我们单店期可忽略「同步」 |
| 会员等级变更记录 | 门店筛选、日期、姓名/手机/宠物名搜索、变更前后、原因、执行店、操作员；手机号脱敏 | **审计日志 UX 可直接借鉴**（任何敏感变更都该有） |
| 客户列表 | 一人多宠、等级徽章、标签、余额拆「充值/赠送」、次卡、累计消费/次数/上次消费、导入导出、批量改等级/升降级开关/发券等 | **客户主档列表范式**可借鉴；资产列（余额/次卡）我们 Phase A 不做 |
| 修改会员等级弹窗 | 改前→改后、原因、温馨提示（换卡迁余额、手动不发礼包、可查变更记录） | **人工纠偏 + 规则提示** 模式很好，后期会员模块照抄交互 |
| 收银台 | 左导航含「预约服务 / 洗护报告」；结账三栏：客户上下文 / 卡券 / 购物清单；扫码枪 | 证明对方也有洗护报告入口，但主路径仍是收银；**我们不应以收银台为后台首页** |
| 权限设置 | 「修改会员等级」「等级变更记录」「会员等级配置」拆成独立权限点 | **敏感操作独立授权** 应写入我们后台权限模型（即使 A 期只有 boss） |

### 11.2 对方信息架构（从侧栏读出）

```text
店铺概况 / 接待管理
店面业务 → 收银台、订单、预约服务、洗护报告、寄养、疫苗驱虫…
商品服务 / 库存管理
客户中心 → 客户管理、宠物管理、会员卡模板、次卡模板、积分、会员营销
营销中心 / 数据统计 / 微信商城
```

启示：宠老板把「洗护报告」放在店面业务里，和收银并列；**客户中心是独立一级**，会员规则很重。我们后台 IA 应对齐「服务经营」而不是「客户资产」做首页。

### 11.3 可借鉴的交互模式（与是否做会员无关）

1. **列表页标配**：门店筛选 + 多条件 +「姓名/手机/宠物名」合一搜索 + 查询/重置 + 汇总条（红色小字统计）  
2. **主从 Tab**：列表 ↔ 变更记录（业务数据与审计并排）  
3. **批量操作底栏**：勾选后底部浮出批量菜单（改等级、打标签…）  
4. **敏感弹窗必有规则提示**：改什么、会触发/不触发什么、去哪查日志  
5. **手机号脱敏展示**：列表默认打码  
6. **权限粒度**：配置 / 改等级 / 看日志 三分开  
7. **一人多宠**：列表内嵌宠物标签 +「添加宠物」快捷入口  

### 11.4 明确不要照搬进 Phase A 的

| 能力 | 原因 |
|------|------|
| 累计消费升降级 + 滚动窗口 + 保级阈值 | 依赖完整收银流水；我们还没有交易账本 |
| 充值余额 / 赠送余额拆分 | 储值财务规则，属 Phase C |
| 次卡模板 / 积分 / 发券批量 | 营销资产体系，后置 |
| 收银台三栏结账 | 与我们「报告成片」主线抢资源 |
| 多店「同步规则至」 | 单店未做透前不做连锁配置分发 |
| 退款 7 天降级回滚 | 无退款链路则无此规则 |

### 11.5 对宠小它路线的修正（看完截图后）

| 原判断 | 修正 |
|--------|------|
| Phase C「轻量会员」可能只是等级标签 | 对方会员 = **卡模板 + 等级引擎 + 资产账 + 审计 + 权限**；若要做，必须整包设计，不能只做「银金钻」四个字 |
| 客户列表可很快做 | A 期可做 **「服务客户档案」瘦身版**：宠主+宠物+最近预约/报告/留资，**不含余额/次卡/积分** |
| 权限 A 期可只有 boss | 仍建议预留权限点命名（改客户、看手机号明文、导出），避免 C 期推倒 |

**Phase A 客户中心（瘦身）建议字段**：头像/昵称、脱敏手机、宠物列表、最近到店、最近报告、留资状态、来源（预约/报告页）；操作：查看详情、去报告、去回访。  
**不做**：余额、押金、积分、会员卡张数、批量改等级。

### 11.5.1 客户管理全页（教学标注版，补充）

> 素材：`docs/refs/chonglaoban-upgrade/04-customer-management-guide.png`  
> 与此前客户列表截图同模块；本张带产品引导气泡，侧栏为「中台版」变体（标签管理 / 会员卡 / 次卡 平铺）。

#### 对方页面骨架（可复用到任何中后台列表）

```text
筛选区（多条件 + 姓名/手机/宠物名） → 查询/重置/新增/导入/导出
汇总条（会员数、总余额拆分、预存款、押金、积分）
表格（会员 | 标签 | 宠物 | 资产列… | 更多操作）
```

引导文案要点：

1. 按条件筛会员  
2. 点姓名进详情  
3. 宠物列可展开 / 添加宠物  
4. 会员卡/次卡点进卡包  
5. 「更多」：充值、编辑、冻结小程序等  

#### 筛选维度（对方很全，我们要砍）

| 对方筛选项 | A 期 | 说明 |
|------------|------|------|
| 门店 | 单店可隐藏 | 多店再开 |
| 会员卡 / 次卡 / 标签 | ❌ | 无资产体系 |
| 注册日期 / 生日 | 可选后置 | |
| 公众号/小程序绑定 | B 可选 | 有 openid 后再做 |
| 性别 / 注册来源 | 可选 | 来源对我们有价值（预约/报告/留资） |
| 上次消费 / 累计消费金额 | ❌→改成服务口径 | 改为「上次到店」「累计完成预约」 |
| 姓名/手机/宠物名合一搜 | ✅ 必做 | 交互直接抄 |

#### 汇总条映射

| 对方 | 宠小它 A 期 |
|------|-------------|
| 会员数 | 客户数（有过预约或留资的宠主） |
| 总余额 / 预存款 / 押金 / 积分 | **整行不做** |
| — | 可改为：本月到店、待回访、有报告客户数 |

#### 行内操作映射

| 对方「更多」 | 我们 |
|--------------|------|
| 充值 | ❌ |
| 编辑会员信息 | ✅ 编辑备注/昵称（慎改手机） |
| 冻结小程序 | 后置 |
| — | ✅ 查看报告、去回访、查看预约 |

#### Phase A「客户管理」定稿草案

```text
筛选：来源（预约/报告留资/全部）| 有待回访 | 最近到店日期
搜索：姓名 / 手机 / 宠物名
按钮：查询、重置、（导出可 B 期）
汇总：客户数 · 待回访数 · 本月到店数

列：客户（头像+名+脱敏手机）| 宠物（标签+添加）| 最近到店 | 最近报告 | 留资状态 | 来源 | 操作（详情/报告/回访）
```

侧栏：客户管理、宠物管理 即可；**不做**标签管理/会员卡/次卡一级入口（C 期再说）。

### 11.5.2 客户管理 · 会员信息导入（补充）

> 素材：`docs/refs/chonglaoban-upgrade/05-customer-import-guide.png`  
> 连锁版教学弹层：「会员信息导入」五步引导。

#### 对方导入流程

1. 先在「会员卡」里建好 **会员卡模板**  
2. 下载最新 Excel 模板  
3. 按模板填写（表内「会员卡模板」名称须与系统一致）  
4. 上传文件  
5. 确认校验结果后提交  

列表背景还可见排序 Tab：入会时间 / 剩余金额 / 剩余积分 / 消费金额 / 消费次数 / 消费时间——全是 **资产与消费排序**，再次证明客户列表默认站在收银会员视角。

#### 对我们的含义

| 点 | 结论 |
|----|------|
| 导入强依赖「会员卡模板」 | 无卡体系就做不了对方同款导入；硬做会倒逼先建卡 |
| 五步引导 UX | **可借鉴**：下载模板 → 填写 → 上传 → 确认；任何批量导入都该有 |
| A 期是否做导入 | **不做**。客户应从预约/报告留资自然沉淀；开店冷启动若需要，B 期再做「瘦身导入」（姓名/手机/宠物名，无卡无余额） |
| 排序 Tab | A 期最多：最近到店 / 最近注册；不做余额/积分/消费额排序 |

**风险**：过早做「导入会员」会把产品叙事从「服务经营」拉回「会员资产台账」，并与 Phase C 会员引擎缠在一起。

### 11.6 登录首屏：店铺概况 +「今日待办」弹层（新增）

> 素材：`docs/refs/chonglaoban-upgrade/01-login-dashboard-todo.png`

刚登录默认落在 **店铺概况**，并立刻弹出 **今日待办**——这是对方把「老板每天第一眼」产品化的核心手法。

#### 布局结构（三栏）

| 区域 | 内容 |
|------|------|
| 左导航 | 店铺概况（高亮）→ 接待 → 店面业务 → 商品服务 → 库存 → 客户中心 → 营销 → 数据 → 微信商城 → 新零售 |
| 主区（弹层背后） | 顶栏 4 指标卡（今日订单/会员/提醒/预约 + 迷你趋势线）→ 客流分析折线 → 商城/库存状态条 |
| 右侧栏 | 店铺信息（店名、绑定手机、到期、短信余额）→ 进货商城广告 → 公告/行业资讯 |
| 前景弹层 | **今日待办**：预约 / 提醒 / 寄养 / 临期商品 / 库存不足 / 待发货 / 售后中；「不再提醒」+ 确定 |

#### 今日待办：对方有什么 vs 我们抄什么

| 对方卡片 | 我们态度 |
|----------|----------|
| 今日预约（全部/待确认/我的） | **对标**：全部、待开始、服务中；我们无「待确认接单」（下单即占号） |
| 今日提醒 | **对标**：洗护建议到期、留资待回访 |
| 寄养 / 临期商品 / 库存 / 待发货 / 售后 | **不对标**（业态外） |

#### 可直接搬到 Phase A 的模式

1. **登录落点 = 工作台**，不是收银台、不是客户列表  
2. **首屏弹「今日待办」**（可「不再提醒」）——先处理例外，再看图表  
3. **待办卡片可点击下钻**到对应列表  
4. **背后保留轻量指标卡**（A 期先数字，B 期再加 sparkline）  
5. 右侧广告位我们不做进货商城，可换成帮助/本周打开率等  

#### 宠小它「今日待办」MVP 草案

```text
今日预约     → 全部 | 待开始(new) | 服务中(doing)
待出报告     → doing 且尚无报告
成片异常     → processing 超时 | failed
待回访线索   → pending 且 remindDate≤今天
```

顶栏 4 指标卡建议：`今日预约` · `今日完成` · `待回访` · `成片失败`。

此前 IA 里「今日工作台」作为一级入口——**与对方首屏策略一致，锁定**。抄的是「待办驱动」交互，不是抄寄养/库存内容。

### 11.6.1 店铺概况本体（关掉待办弹层后）

> 素材：`docs/refs/chonglaoban-upgrade/02-store-overview.png`

弹层关掉后，店铺概况是一张 **「指标卡 + 趋势图 + 业务状态条 + 右侧店务栏」** 的经营首页。

#### 对方模块拆解

| 区块 | 内容 | 我们态度 |
|------|------|----------|
| 顶栏 4 卡 | 今日订单 / 今日会员 / 今日提醒 / 今日预约（带 sparkline） | **对标结构**；指标换成服务经营口径（见下） |
| 客流分析 | 会员数 / 散客数 / 总客流 折线，可选日期范围 | B 期再做；A 期可先不做图，或只做「预约量」单线 |
| 微信商城状态 | 待付款 / 待发货 / 待退款 / 待处理预约 | **不对标商城**；可改成「报告漏斗」四格 |
| 库存不足表 | 商品 + 当前库存 | **不对标** |
| 右侧店信息 | 店名、认证、手机、到期、短信余额 | 轻量保留：店名、营业时段摘要、员工数 |
| 右侧广告 | 进货商城 | **不做** |
| 右侧公告 | 系统升级说明 / 行业资讯 | 可选：产品更新日志或帮助链接 |

侧栏相对上一张多了 **工作日历**（在接待与店面业务之间）——A 期可并入「预约与排班」，不必单独一级。

#### 宠小它「店铺概况 / 工作台」A 期线框（定稿草案）

```text
┌─────────────────────────────────────────────┬──────────────────┐
│ 今日预约 │ 今日完成 │ 待回访 │ 成片失败     │ 门店卡片         │
│ （数字，可点下钻；B 期加 sparkline）          │ 店名/时段/员工   │
├─────────────────────────────────────────────┤ 帮助 / 更新说明  │
│ 今日待办条（或登录弹层关闭后的常驻摘要）      │                  │
│  · 待开始 n  · 服务中 n  · 待出报告 n         │                  │
│  · 成片失败 n  · 待回访 n                     │                  │
├─────────────────────────────────────────────┤                  │
│ 近 7 日预约完成趋势（可选，A 可后置）         │                  │
├──────────────────┬──────────────────────────┤                  │
│ 报告漏斗（替商城）│ 异常列表（替库存不足）    │                  │
│ 已发送/已打开/   │ 成片失败最近 5 条         │                  │
│ 已留资/已预约    │ 或 待回访最近 5 条         │                  │
└──────────────────┴──────────────────────────┴──────────────────┘
```

**报告漏斗四格**（替代微信商城四格）：`今日已发报告` · `已打开` · `已留资` · `从报告发起的预约`——直接打在我们差异化上；缺埋点统计时先显示「—」并链到 B1。

### 11.7 截图覆盖度与仍缺清单（2026-07-10 刷新）

#### 已有（够用）

| 主题 | 状态 |
|------|------|
| 登录今日待办 + 店铺概况 | ✅ |
| 客户管理列表 / 导入 / 改等级 / 变更记录 / 权限 | ✅ 偏会员资产，A 期只借交互 |
| 会员等级配置 / 卡模板同步 | ✅ 证明 C 期复杂度 |
| 新增服务（SKU 级） | ✅ 证明服务目录别做成 POS |
| 收银台 | ✅ 明确不对标为首页 |

#### Phase A 定稿仍缺（优先，按序）

| 优先级 | 页面 | 为什么要 | 状态 |
|--------|------|----------|------|
| **P0** | **预约服务**列表或日/周日历 | A2 核心 | ⛔ **当前账号版本无权限**（见下） |
| **P0** | **工作日历** | 确认是否=排班 | 待试；可能同属高版本 |
| **P0** | **洗护报告**列表 | A3 核心 | 待试（同在店面业务下，或也可打开） |
| **P1** | 预约/报告详情 | 定字段与主操作 | 依赖上两项 |
| **P1** | **接待管理**首页 | 避免与工作台重复 | 待试 |
| **P2** | 数据统计 / 提醒 / 店铺设置 | B 期或 A5 参考 | 可选 |

#### 11.7.1 预约服务：版本门禁（2026-07-10）

> 素材：`docs/refs/chonglaoban-upgrade/06-appointment-version-blocked.png`

点击侧栏 **店面业务 → 预约服务** 后弹出：

> 版本权限操作：当前版本不可使用该功能，请前往【系统升级】了解更多。

说明：对方把「预约」做成 **付费/高版本模块**，体验版/低版本账号看不到列表 UI。  
**不影响我们做 Phase A**——宠小它预约模型已在小程序落地，Web 后台可按自有状态机设计，不必等竞品截图。

本张仍有价值：展开了 **店面业务** 子菜单完整 IA：

```text
店面业务
├── 收银台
├── 订单管理
├── 预约服务      ← 版本门禁
├── 洗护报告      ← 请优先试能否打开
├── 寄养管理
├── 提醒
├── 记账本
├── 宠付宝
└── 转诊管理
```

与我们的映射：收银台/订单/寄养/记账/宠付宝/转诊 → 不对标；**预约 + 洗护报告 + 提醒** → A/B 对标。

#### 截图受阻时的推进方式

1. 若能打开：**洗护报告**、**提醒**、**接待管理**、**工作日历** — 继续发  
2. 若整片店面业务都门禁 — 停等竞品预约 UI，直接按宠小它现网写 **Phase A PRD**（工作台 / 预约 / 报告 / 线索 / 设置）  
3. 不建议为截图去开通对方高版本，性价比低  
4. **已由 PDF（7.2 支付宝安心生活）补全预约状态机与可约模型描述**，见 §11.9  

### 11.8 新增服务表单（商品服务深水区）

> 素材：`docs/refs/chonglaoban-upgrade/03-add-service.png`

对方把「服务」做成 **可售 SKU**：分类、多规格、零售价/会员价、时长、含商品、小程序上下架、复购提醒、会员折扣、付费券、预约押金、图文详情。这是收银+商城一体的服务目录，不是我们现在的「预约用服务类型名」。

#### 对方表单结构

| 区块 | 字段要点 |
|------|----------|
| 基础信息 | 名称*、分类（可跳转新增）、排序值、备注 |
| 服务项目/规格 | 可多条：规格名*、拼音码、条码、零售价*、会员价、时长、包含商品、服务说明（展示在小程序预约）、上架商城/可预约开关、复购提醒/参与会员折扣/生成服务记录 |
| 高级设置 | 适用宠物、服务标签、已售数量（可刷单展示） |
| 付费券配置 | 企业版：可退、有效期≤90 天、到期自动退 |
| 预约押金 | 开则小程序预约需微信支付押金 |
| 媒体 | 最多 9 图 + 1 短视频 |
| 服务详情 | 富文本 |

#### 与宠小它现状对比

| 维度 | 宠老板 | 宠小它现在 |
|------|--------|------------|
| 模型 | 服务目录 + 多规格 SKU | `entity:service_type`：**仅 name + storeId**（系统默认不可改删） |
| 价格 | 零售价 / 会员价 | **无**（预约不收银） |
| 时长 | 规格级时长（15 分钟档） | 号源是门店半小时档，**不绑服务时长** |
| 小程序 | 商城上架 + 预约开关分离 | 有名称即可出现在预约选项 |
| 复购 | 规格级「复购提醒」 | 有 `service_interval` 建议周期，但是**按服务名匹配**，非规格级 |
| 押金/券 | 微信支付押金、付费券 | **无** |

#### 借鉴分级（重要：别一次做成对方那样）

| 优先级 | 能力 | 说明 |
|--------|------|------|
| **A 期设置中心** | 名称、排序、启用/停用、适用宠物（猫/犬/不限）、备注、是否出现在预约 | 在现有 ServiceType 上**轻量加字段**即可；后台表单远短于对方 |
| **A/B 可选** | 服务说明（预约页展示）、封面图 1 张、建议时长（仅展示，不改号源算法） | 提升预约体验，仍不做价 |
| **B 期** | 与 `service_interval` 打通的「复购提醒」开关 | 对方规格级提醒 → 我们门店级/服务名级即可 |
| **C 期（若做会员/收银）** | 零售价/会员价、多规格、条码、含商品、押金、付费券、商城上架 | 一旦做价，就进入交易账本，与会员引擎同级复杂度 |

#### Phase A「服务类型」后台表单草案（瘦身）

```text
服务名称 * 
适用宠物：不限 | 猫 | 犬
排序（数字，越小越靠前）
预约可选：开/关
备注（仅店内可见）
[保存]
```

**明确不做（A 期）**：多规格、条码、零售/会员价、包含商品、商城上架、押金、付费券、刷已售数量、富文本详情。

#### 产品含义

对方「新增服务」证明：完整宠物店后台会把服务当成 **商品**。  
宠小它若坚持「服务经营 + 报告转化」，A 期服务配置应保持 **预约目录**，不要提前长成 POS 商品卡——否则设置中心会拖垮 MVP，并倒逼收银。

### 11.9 PC 端升级公告 PDF 研读（2026-07-10）

> 目录：`docs/refs/chonglaoban-upgrade/*.pdf`（6 份，用户下载的升级说明）

| PDF | 主题 | 对宠小它 |
|-----|------|----------|
| 4月1日更新公告 | 服务规格批量改分类、盘点、入库权限、移动端再购进收银、小程序营销、会员卡/次卡分享、订单批量退货 | 库存/收银/营销深水；**A 期不跟** |
| 6月16日更新公告 | 会员卡充值入口、改有效期、模板默认值 | 会员资产；C 期参考 |
| 6.24 扫码点餐 | 桌码/小程序点餐、备餐状态机、语音提醒、核销回传收银 | **餐饮业态**；明确不做 |
| 6.26 通用押金 | 通用 vs 锁定押金；取消预约/寄养须先处理锁定押金；结账默认可扣押金；有押金禁删会员 | 预约与资金账户强耦合；我们无支付则**不做押金态机** |
| 7.2 支付宝安心生活 | 服务发布到支付宝、次卡→预约→核销→结账多单；可约库存（排班/时长/人数）；跨店券 | 渠道扩张；预约含确认/拒绝/到店/履约，且可接外部单 |
| 7.9 会员卡自动升降级 | 与已截图一致：规则引擎、审计、权限、连锁同步 | C 期整包；A 不做 |

#### PDF 补上的「预约模型」（弥补截图门禁）

支付宝对接说明暴露了对方预约能力（体验版看不到 UI 也能推断）：

- 可配置 **是否自动接受预约**
- 状态：确认 / 拒绝 / 到店(履约中) / 取消 / 完成；**核销并结账 → 收银台**
- 可约：关联排班 / 服务时长 / 星期时段+人数库存
- 按手机号自动匹配或创建会员 +「未知」宠物

与宠小它：我们是 **下单即占号**，完成导向 **出报告/成片**，号源是半小时档+占用块——**A 期按自有模型设计即可，不必再等预约列表截图**。

#### 对方近期迭代方向（从 PDF 汇总）

```text
交易加深：押金账户、退货批量、再购进收银
渠道加深：支付宝安心生活、扫码点餐
会员加深：升降级引擎、卡模板、分享开卡
库存/餐饮：盘点、点餐备餐
```

几乎没有「洗护报告体验 / 内容分享转化」方向——**差异化窗口仍在宠小它**。

---

## 参考链接

- https://www.chonglaoban.cn/about/chonglaoban  
- https://www.chonglaoban.cn/  
- `docs/refs/chonglaoban-upgrade/`（截图 + PDF 素材）  
- `docs/架构与产品评估报告-2026-07-05.md`  
- `docs/coverage/ontology-coverage-audit.md`（P1/P2 gap）