conti-docs/prd/modules/04-RMD-提醒.md

4.4 提醒

本文件是【提醒 RMD】模块需求的编辑入口。 主文件 ../Continental-Retail-APP-PRD.md 第 4.4 节已于 2026-08 从本文件回灌（V1.1），此后的需求变更仍改本文件、再回灌。 两者不一致时以本文件为准。 目录约定见 README.md。

项	值
模块码	RMD
V1.0 章节	4.4
描述粒度	14 维完整模板
需求依据	业务需求 + 原型图
现状承载系统	F6（PC 端，App 内嵌 H5）
需求条数	7（待确认 2，完成度 71%）
配图	3 张（原型 3，均为 F6 PC 端截图）

模块概要

---

承接方式已定：提醒能力由 F6 承载，App 不做原生实现，以 Embedded H5 容器嵌入 F6 现有提醒页，能正常展示与操作即可。提醒规则、提醒单生成与跟进逻辑全部留在 F6 侧，App 只负责入口、换票鉴权与容器能力。方案取舍见 4.4.5。

本模块现状分三步：设置提醒规则 → 生成提醒单 → 跟进提醒单，分别对应 4.4.2–4.4.4。三步均由 F6 实现，以下小节记录其现状形态 —— 这既是 App 嵌入后用户实际看到的内容，也是后续若要原生化时的需求底稿。

4.4.1 需求描述

业务目标 —— 基于车辆保养周期、保险到期、检测异常等规则自动生成提醒单，由服务顾问跟进转化，提升复购与到店率，支撑痛点 2.4 的「客户分层营销」诉求

目标角色 —— 店长；技工是否开放入口待定 TODO(REQ-RMD-005)

入口 —— App 内提醒入口，具体位置随导航方案确定（见导航收敛与角色化配置）；点击后进入 Embedded H5 容器加载 F6 提醒页

前置条件 —— 门店已接入 F6；已有车辆与消费历史数据

页面内容 —— 由 F6 页面提供，App 侧不另行定义；现状形态见 4.4.2–4.4.4

主流程：

1. 设置提醒规则
2. 车主到店消费
3. 车主完工离店
4. 生成提醒单并跟进
5. 临近服务日提醒车主（可自动发短信/微信）
6. 车主再次到店

异常流程：

• 门店未接入 F6 → 提醒入口不显示，见门店能力开关
• F6 提醒页白屏 / 加载超时 / 票据过期 → 由 Embedded H5 容器统一处理，见 7.3
• 车主手机号缺失 → 无法发送短信/微信，仅支持电话提醒（F6 页面行为）
• 短信额度不足 → 提示「未购短信，无法分享」并提供购买入口（F6 页面行为）

业务规则 —— 见 4.4.6

权限规则 —— 页面内的规则配置与跟进权限由 F6 自行控制；App 侧只决定入口对哪些角色可见 TODO(REQ-RMD-005)

访问链路 —— App → Embedded H5 容器 → App Backend 换票下发 URL → F6 提醒页（不传裸 URL，见 7.3）

逻辑数据来源 —— F6（规则、提醒单、车辆与消费历史）

回写目标 —— 无。跟进动作（电话提醒 / 发送短信 / 发送微信 / 完成 / 转交）在 F6 页面内完成并由 F6 自行落库，App 不做回写

状态变化 —— 提醒单：未处理 → 我未完成 / 我已完成 → 所有已完成（状态机由 F6 维护）

验收标准 —— 见 4.4.7

4.4.2 设置提醒规则

页面内容 —— F6 PC 端「客情维护 > 商机设置 > 服务提醒」页（顶部叠加的流程条在第 ① 步），左侧为 F6 主导航，右侧「商机规则设置」区含八个规则类别 tab、保养 / 洗美子 tab 与一张规则表格，表格右侧「操作」列被截断并出现横向滚动条 —— PC 版式在窄容器内的实际表现。

关键交互 —— ①切换八个规则类别 tab；②切换保养 / 洗美子 tab；③行末「修改」→ 编辑该条规则；④「状态」列开关 → 启用 / 停用该规则（图中橙色为启用、灰色为停用）；⑤「+ 添加保养提醒规则」→ 新增，上限 20 条（REQ-RMD-002）；⑥横向滚动查看被截断的列。

可用角色 —— 店长 ✅（设置提醒规则属门店管理职能）；技工 ✗。页面内权限由 F6 自行控制，App 只控入口可见性 TODO(REQ-RMD-005)。

需求关联 —— REQ-RMD-002 规则数量上限、REQ-RMD-003 自动提醒开关、REQ-RMD-007（本图的横向滚动即「PC 版式展示降级」的直接证据）

规则分八类（tab）：服务提醒 / 车险到期提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保提醒。最多可自定义 20 个提醒规则。

服务提醒下分「保养提醒」与「洗美提醒」，按项目设置服务周期。保养提醒规则表字段：

字段	说明	示例
提醒类别	规则名称，可标「推荐」	小保养、空气滤清器、火花塞、变速箱油、刹车油、发动机清洗、油底壳螺丝、防冻冷却液、轮胎
包含项目	触发该提醒的业务项目	工单业务分类：保养；更换空气滤清器·保养工时费
是否根据保养手册	是 / 否
提醒单生成日	相对下次服务日的提前量	下次服务日前 30 天 / 15 天 / 7 天 / 60 天 / 10 天 / 23 天
提醒单处理人	责任人角色	工单服务顾问 / 公司统一处理人 / 无处理人
是否自动提醒	是 / 否
状态	启用 / 停用开关
操作	修改

保养提醒规则字段

系统预置规则基于常见保养提醒周期，建议开启后不删除；开启时若提醒包含项目有云项目，会自动下载云项目至本地。

4.4.3 生成提醒单

页面内容 —— F6 PC 端「服务提醒 > 我未完成」页（流程条在第 ② 步），顶部是两个按八类规则分列的计数看板（待我处理 0 / 所有未处理 8100），其下依次为八类 tab、四个状态 tab、搜索筛选行与提醒单表格（共 1939 条），本图为测试门店数据（客户姓名含「测试111」、手机号含 12123456789 等非法号码）。

关键交互 —— ①切换八类 tab / 四个状态 tab → 过滤列表；②行首勾选框多选 → 对选中项批量执行；③「电话提醒」→ 外呼（App 内经容器 dial 桥接，见验收标准）；④「发送短信」/「发送微信」→ 手动触达；⑤「完成」→ 关单；⑥「转交」→ 移交他人；⑦「列设置」→ 自定义显示列；⑧「更多筛选」/「设为常用」→ 条件筛选与常用条件保存。

可用角色 —— 店长 ✅；技工 ❓ TODO(REQ-RMD-005)。⚠️ 与 REQ-ACC-006 一致，该项关闭前按更严格一侧实现（技工不可见）。

需求关联 —— REQ-RMD-001 承接方式、REQ-RMD-003 自动提醒、REQ-RMD-006 短信额度

页面构成：

• 顶部双看板：「待我处理的提醒单」与「所有未处理的提醒单」，各按八类规则分列计数；
• 八类 tab（服务提醒 / 保险提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保）；
• 流程条：①设置提醒规则 → ②车主到店消费 → ③车主完工离店 → ④生成提醒单并跟进 → ⑤临近服务日，提醒车主（可自动发送短信微信）→ ⑥车主再次到店；
• 状态 tab：我未完成 / 我已完成 / 所有未完成 / 所有已完成；
• 提醒单列表字段：提醒单号、客户姓名、手机号、车牌号、上次服务门店、上次服务日期、提醒类别、提醒来源、关联单号；
• 操作区：操作 / 电话提醒 / 发送短信 / 发送微信 / 完成 / 转交 / 列设置。

4.4.4 跟进提醒单

页面内容 —— 与上一张是同一个 F6 页面（同一份表格、同一批数据），区别只是流程条高亮在第 ③ 步并另加了两个 PPT 标注框，图左下角还残留德文占位文字 Individueller Informationsbereich，说明本图取自 PPT 模板。

关键交互 —— 无新增交互。跟进动作就是上一张图中列表上方的那排按钮（电话提醒 / 发送短信 / 发送微信 / 完成 / 转交），「跟进提醒单」不是一个独立页面。

可用角色 —— 同 4.4.3：店长 ✅；技工 ❓ TODO(REQ-RMD-005)。

需求关联 —— REQ-RMD-003 自动提醒、REQ-RMD-006 短信额度。本图主要作跟进手段的分类佐证，不引入新页面需求。

本图澄清了一处结构误解：V1.0 把 4.4.3「生成提醒单」与 4.4.4「跟进提醒单」写成两节，容易读成两个页面。实际上 F6 侧只有一个列表页，「生成」是系统按规则自动产出提醒单，「跟进」是人在同一个列表上执行操作。App 以 Embedded H5 嵌入时，这两节对应同一个 URL。

跟进手段四类：

1. SA 发券 —— 服务顾问向车主发放优惠券；
2. SA 电话跟进 —— 通过列表「电话提醒」直接外呼；
3. SA 主动发短信提醒 —— 手动触发短信/微信；
4. 临近服务期系统自动发送短信提醒 —— 由规则的「是否自动提醒」开关驱动。

4.4.5 承接方式

现状三步全部在 F6 PC 端完成（会员营销 > 商机规则设置 / 服务提醒）。App 侧的承接范围曾有四个候选：

方案	范围	优点	代价
A	全不做，仍在 PC 端	零成本	门店移动化诉求落空
B	只做「跟进提醒单」（列表 + 电话/短信/微信/完成）	覆盖高频动作，移动端体验合理	规则配置仍需上 PC；需 F6 开放对应 API
C	三步全部移植	完整闭环	规则配置表单在手机上体验差，工作量大
D	Embedded H5 直接嵌 F6 现有页	开发量最小，不依赖 F6 开放 API	F6 现有页为 PC 版，手机上展示效果受限

提醒模块承接方案候选

已选定方案 D。 判定逻辑是：提醒能力本就属于 F6 的业务范畴，App 的整合目标是消除来回切换系统，而不是把 F6 的功能重做一遍；只要能在 App 内看到并处理提醒单，整合价值就已经兑现。方案 B 虽然移动端体验更好，但需要 F6 额外开放提醒单列表与跟进动作的 API，属外部依赖，首版不引入。

随之接受的两个约束：

• 展示效果降级 —— F6 现有提醒页是 PC 版式（八类 tab + 九列表格），在手机上很可能需要横向滚动。本期接受这一降级，不为其做专门适配。若 F6 能提供移动端页面则直接换 URL，见 TODO(REQ-RMD-007)。
• App 侧无原生能力 —— 提醒单不进入 App 的待办、消息或首页看板，也不参与弱网与离线策略；页面内的一切行为都是 F6 的行为。

4.4.6 业务规则

REQ-RMD-001 承接方式 —— 已定：以 Embedded H5 嵌入 F6 现有提醒页，App 不做原生实现，见 4.4.5

REQ-RMD-002 规则数量上限 —— 最多自定义 20 个提醒规则（F6 侧约束，App 不另设限制）

REQ-RMD-003 自动提醒 —— 规则开启「是否自动提醒」后，临近服务日由 F6 自动发送短信/微信，不经 App

REQ-RMD-004 规则冲突 —— 同一车同一项目命中多条规则时的去重由 F6 规则引擎决定，不属 App 需求范围（已随 REQ-RMD-001 关闭）

REQ-RMD-005 入口可见性 —— 提醒入口对技工是否可见待定 TODO(REQ-RMD-005)；页面内的操作权限由 F6 控制，App 不参与

REQ-RMD-006 短信额度 —— 短信为 F6 侧付费资源，额度不足时由 F6 页面阻断发送并提供购买入口

REQ-RMD-007 移动端页面 —— F6 是否能提供移动端版式的提醒页 URL 待确认 TODO(REQ-RMD-007)；在其提供之前，按 PC 版式嵌入并接受展示降级，见 4.4.5

4.4.7 验收标准

1. 门店未接入 F6 时，提醒入口不显示；
2. 从提醒入口进入后，F6 提醒页正常加载，登录态与门店上下文自动带入，不出现二次登录；
3. 票据过期时容器自动换票并重载，用户无感知；
4. 页面内「电话提醒」可调起系统拨号盘（经容器的 dial 桥接能力，见 7.3）；
5. 切换门店或退出登录后，已打开的提醒页立即失效并关闭。

---

附：本模块归拢信息

以下内容从主文件的其它章节归拢而来，便于本模块独立评审。回灌主文件时不处理本分界线以下的部分——主文件的附录仍是全局视图。

附-1 业务数据字典（主文件附录 A.4）

#	数据集	来源	安全	备注
1	提醒规则、提醒单、提醒作业	F6 Backend	HTTPS	F6 后台自动按规则生成提醒单；App 以 Embedded H5 嵌入展示，不落地也不回写，见 4.4.5

提醒模块数据集（摘自主文件附录 A.4）

本模块是全文唯一一个 App 侧零落地、零回写的模块 —— 数据全在 F6，App 只提供容器。因此附录 A 只有一行，也不需要字段级清单。

附-2 权限矩阵（主文件附录 B 本模块分行）

图例：✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认

功能	店长	技工	备注 / 待确认
设置提醒规则	✅	✗	属门店管理职能
生成 / 跟进提醒单	✅	❓	页内权限由 F6 控制，App 只控入口可见性 TODO(REQ-RMD-005)

提醒模块权限矩阵（摘自主文件附录 B）

适用的全局权限实施规则：接口层强制（REQ-ACC-004）；⚙️ 类由店长或后台经人员管理「可用系统」授予（REQ-ACC-005）；🔸 与 ❓ 项在待确认关闭前，一律按更严格的一侧实现（REQ-ACC-006）；权限变更后用户下次进入 App 即生效（REQ-ACC-007）。

本模块权限有个特殊之处：App 只能控制入口可见性，控制不了页面内部。技工一旦进入 F6 提醒页，页内能做什么由 F6 的账号权限决定。因此 TODO(REQ-RMD-005) 的结论必须与 F6 侧的角色配置对齐，否则会出现「App 放行、F6 拦截」或反过来的错配。

附-3 待确认项（主文件 10.2.4）

编号	待确认内容	建议决策方
REQ-RMD-005	提醒入口对技工是否可见	产品
REQ-RMD-007	F6 能否提供移动端版式的提醒页 URL	架构 / F6

提醒模块待确认项（摘自主文件 10.2.4，2 条）

附-4 配图清单（主文件附录 C 4.4 节）

序	说明	文件
1	原型-设置提醒规则（F6「客情维护 > 商机设置」，八类 tab + 规则表 + 启停开关）	../images/原型-提醒-设置提醒规则.png
2	原型-生成提醒单（F6 服务提醒列表，双看板 + 四状态 tab + 跟进按钮行，测试数据）	../images/原型-提醒-生成提醒单.png
3	原型-跟进提醒单（与上图同一页面，PPT 标注四类跟进手段）	../images/原型-提醒-跟进提醒单.png

提醒模块配图清单，3 张（原型 3）。说明较主文件附录 C已按实际截图内容补充，主文件附录 C 回灌时应一并更新。

附-5 本次拆分新增发现

本模块未新增编号需求（提醒能力整体外包给 F6，App 侧不产生新需求）。逐图核看得到三点观察，供评审参考：

1. 4.4.3 与 4.4.4 是同一个 F6 页面，不是两个。已就地写进 4.4.4 的说明块 —— 影响的是嵌入时的 URL 数量（1 个而非 2 个），不影响需求条目。
2. 「PC 版式展示降级」已有实证。REQ-RMD-007 此前只是推断，本次在设置提醒规则图上看到了表格右侧列被截断 + 横向滚动条，可作为向 F6 提移动端页面需求时的直接依据。
3. F6 侧数据同样含测试残留（客户姓名 无 / 测试等级 / 测试111，手机号 12123456789 等非法号码）。与库存模块发现的同类问题一致，但本模块不为此立需求 —— 数据在 F6 侧、清洗责任也在 F6 侧，App 只作展示。若上线前 F6 未清理，属对方系统的数据质量问题，建议在集成联调时一并提出。