malei 598a250c81 docs: define follow-up task and rebook contracts

2026-08-02 02:11:28 +08:00

33 KiB

Raw Blame History

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

参考：宠老板介绍页 · 宠老板官网
状态：产品草案（仅文档，未进入编码）
日期：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
报告分享 / 显式发送确认 / 打开埋点 / 留资回访	✅	小程序 + Admin + 公开页 + Leads
门店设置 / 员工 / 服务类型	✅ 基础	小程序「我的」
会员卡 / 储值 / 套餐	❌ gap 占位	本体未展开
收银 / 库存 / 寄养 / 提成 / 进货	❌	明确不在 P0
独立 Web 门店管理后台	❌	老板只能在小程序里点

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

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

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

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

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

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

5.1 产品形态

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

5.2 信息架构（IA）草案

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

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

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

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

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

模块	能力	依赖
A1 工作台	登录落点；「今日待办」弹层（预约/待报告/成片异常/待回访）+ 顶栏 4 指标卡；卡片下钻列表	现有 API 聚合
A2 预约中心	列表筛选（状态/日期/技师）、详情、取消/开始（权限同现网）	Appointment*
A3 报告中心	报告列表、公开链接复制、成片三态、触发重生成	Report* / Highlight
A4 回访任务	FollowUpTask 领取/改期/关闭/真实再次预约	ReportLead + FollowUpTask
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

再下一步：

~~按 PRD 出线框说明~~ → docs/门店管理后台-PhaseA-线框说明.md
~~评估技术选型~~ → docs/门店管理后台-技术选型草案.md（推荐 Vue3 + Element Plus + admin/）
~~拆编码任务 brief~~ → docs/门店管理后台-PhaseA-编码任务brief.md（待用户授权编码）
坚持要对标收银/库存 — 需单独商业论证（受 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 对方信息架构（从侧栏读出）

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

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

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

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

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
与此前客户列表截图同模块；本张带产品引导气泡，侧栏为「中台版」变体（标签管理 / 会员卡 / 次卡平铺）。

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

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

引导文案要点：

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

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

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

汇总条映射

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

行内操作映射

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

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

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

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

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

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

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

对方导入流程

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

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

对我们的含义

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

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

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

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

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

布局结构（三栏）

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

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

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

可直接搬到 Phase A 的模式

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

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

今日预约     → 全部 | 待开始(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 期线框（定稿草案）

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

报告漏斗（替代微信商城状态）：今日已提交报告 · 已确认发送 · 已打开 · 已留资 · 回访后真实再次预约——均由 BusinessEvent 汇总；发送只认员工显式确认，不以提交、复制链接或展示二维码冒充；再次预约只认携带 FollowUpTask 且真实保存成功的 Appointment。

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：

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

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

截图受阻时的推进方式

若能打开：洗护报告、提醒、接待管理、工作日历 — 继续发
若整片店面业务都门禁 — 停等竞品预约 UI，直接按宠小它现网写 Phase A PRD（工作台 / 预约 / 报告 / 线索 / 设置）
不建议为截图去开通对方高版本，性价比低
已由 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 分钟档）	服务项目级预计时长（30 分钟粒度），预约保存时长快照并跨容量桶占用
小程序	商城上架 + 预约开关分离	有名称即可出现在预约选项
复购	规格级「复购提醒」	有 `service_interval` 建议周期，但是按服务名匹配，非规格级
押金/券	微信支付押金、付费券	无

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

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

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

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

明确不做（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 汇总）

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

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

参考链接

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）

33 KiB Raw Blame History Unescape Escape