Files

240 lines
18 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# 4.4 提醒
> **本文件是【提醒 RMD】模块需求的编辑入口。**
> 主文件 [`../Continental-Retail-APP-PRD.md`](../Continental-Retail-APP-PRD.md) 第 4.4 节已于 2026-08 从本文件回灌(V1.1),此后的需求变更仍改本文件、再回灌。
> **两者不一致时以本文件为准。** 目录约定见 [`README.md`](./README.md)。
| 项 | 值 |
| --- | --- |
| 模块码 | RMD |
| V1.0 章节 | 4.4 |
| 描述粒度 | 14 维完整模板 |
| 需求依据 | 业务需求 + 原型图 |
| 现状承载系统 | F6PC 端,App 内嵌 H5 |
| 需求条数 | 7(待确认 2,完成度 71%) |
| 配图 | 3 张(原型 3,均为 F6 PC 端截图) |
模块概要
---
> **承接方式已定**:提醒能力**由 F6 承载**,App **不做原生实现**,以 [Embedded H5](../Continental-Retail-APP-PRD.md#73-f6-集成边界) 容器嵌入 F6 现有提醒页,能正常展示与操作即可。提醒规则、提醒单生成与跟进逻辑全部留在 F6 侧,App 只负责入口、换票鉴权与容器能力。方案取舍见 [4.4.5](#445-承接方式)。
本模块现状分三步:**设置提醒规则 → 生成提醒单 → 跟进提醒单**,分别对应 [4.4.2](#442-设置提醒规则)[4.4.4](#444-跟进提醒单)。三步均由 F6 实现,以下小节记录其现状形态 —— 这既是 App 嵌入后用户实际看到的内容,也是后续若要原生化时的需求底稿。
## 4.4.1 需求描述
**业务目标** —— 基于车辆保养周期、保险到期、检测异常等规则自动生成提醒单,由服务顾问跟进转化,提升复购与到店率,支撑[痛点 2.4](../Continental-Retail-APP-PRD.md#24-支付与营销) 的「客户分层营销」诉求
**目标角色** —— 店长;技工是否开放入口待定 `TODO(REQ-RMD-005)`
**入口** —— App 内提醒入口,具体位置随导航方案确定(见[导航收敛与角色化配置](./02-HOM-APP首页与导航.md#425-导航收敛与角色化配置));点击后进入 Embedded H5 容器加载 F6 提醒页
**前置条件** —— 门店已接入 F6;已有车辆与消费历史数据
**页面内容** —— 由 F6 页面提供,App 侧不另行定义;现状形态见 [4.4.2](#442-设置提醒规则)[4.4.4](#444-跟进提醒单)
**主流程**
1. 设置提醒规则
2. 车主到店消费
3. 车主完工离店
4. 生成提醒单并跟进
5. 临近服务日提醒车主(可自动发短信/微信)
6. 车主再次到店
**异常流程**
- 门店未接入 F6 → 提醒入口不显示,见[门店能力开关](../Continental-Retail-APP-PRD.md#74-门店能力开关)
- F6 提醒页白屏 / 加载超时 / 票据过期 → 由 Embedded H5 容器统一处理,见 [7.3](../Continental-Retail-APP-PRD.md#73-f6-集成边界)
- 车主手机号缺失 → 无法发送短信/微信,仅支持电话提醒(F6 页面行为)
- 短信额度不足 → 提示「未购短信,无法分享」并提供购买入口(F6 页面行为)
**业务规则** —— 见 [4.4.6](#446-业务规则)
**权限规则** —— 页面内的规则配置与跟进权限由 F6 自行控制;App 侧只决定入口对哪些角色可见 `TODO(REQ-RMD-005)`
**访问链路** —— App → Embedded H5 容器 → App Backend 换票下发 URL → F6 提醒页(不传裸 URL,见 [7.3](../Continental-Retail-APP-PRD.md#73-f6-集成边界)
**逻辑数据来源** —— **F6**(规则、提醒单、车辆与消费历史)
**回写目标** —— 无。跟进动作(电话提醒 / 发送短信 / 发送微信 / 完成 / 转交)在 F6 页面内完成并由 F6 自行落库,App 不做回写
**状态变化** —— 提醒单:未处理 → 我未完成 / 我已完成 → 所有已完成(状态机由 F6 维护)
**验收标准** —— 见 [4.4.7](#447-验收标准)
## 4.4.2 设置提醒规则
![原型-提醒-设置提醒规则](../images/原型-提醒-设置提醒规则.png)
**页面内容** —— F6 PC 端「客情维护 > 商机设置 > 服务提醒」页(顶部叠加的流程条在第 ① 步),左侧为 F6 主导航,右侧「商机规则设置」区含八个规则类别 tab、保养 / 洗美子 tab 与一张规则表格,表格右侧「操作」列被截断并出现横向滚动条 —— **PC 版式在窄容器内的实际表现**
**关键交互** —— ①切换八个规则类别 tab;②切换保养 / 洗美子 tab;③行末「修改」→ 编辑该条规则;④「状态」列开关 → 启用 / 停用该规则(图中橙色为启用、灰色为停用);⑤「+ 添加保养提醒规则」→ 新增,上限 20 条([REQ-RMD-002](#446-业务规则));⑥横向滚动查看被截断的列。
**可用角色** —— 店长 ✅(设置提醒规则属门店管理职能);技工 ✗。页面内权限由 F6 自行控制,App 只控入口可见性 `TODO(REQ-RMD-005)`
**需求关联** —— [REQ-RMD-002](#446-业务规则) 规则数量上限、[REQ-RMD-003](#446-业务规则) 自动提醒开关、[REQ-RMD-007](#446-业务规则)(本图的横向滚动即「PC 版式展示降级」的直接证据)
规则分八类(tab):**服务提醒 / 车险到期提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保提醒**。最多可自定义 20 个提醒规则。
服务提醒下分「保养提醒」与「洗美提醒」,按项目设置服务周期。保养提醒规则表字段:
| 字段 | 说明 | 示例 |
| --- | --- | --- |
| 提醒类别 | 规则名称,可标「推荐」 | 小保养、空气滤清器、火花塞、变速箱油、刹车油、发动机清洗、油底壳螺丝、防冻冷却液、轮胎 |
| 包含项目 | 触发该提醒的业务项目 | 工单业务分类:保养;更换空气滤清器·保养工时费 |
| 是否根据保养手册 | 是 / 否 | |
| 提醒单生成日 | 相对下次服务日的提前量 | 下次服务日前 30 天 / 15 天 / 7 天 / 60 天 / 10 天 / 23 天 |
| 提醒单处理人 | 责任人角色 | 工单服务顾问 / 公司统一处理人 / 无处理人 |
| 是否自动提醒 | 是 / 否 | |
| 状态 | 启用 / 停用开关 | |
| 操作 | 修改 | |
保养提醒规则字段
系统预置规则基于常见保养提醒周期,建议开启后不删除;开启时若提醒包含项目有云项目,会自动下载云项目至本地。
## 4.4.3 生成提醒单
![原型-提醒-生成提醒单](../images/原型-提醒-生成提醒单.png)
**页面内容** —— F6 PC 端「服务提醒 > 我未完成」页(流程条在第 ② 步),顶部是两个按八类规则分列的计数看板(待我处理 0 / 所有未处理 8100),其下依次为八类 tab、四个状态 tab、搜索筛选行与提醒单表格(共 1939 条),**本图为测试门店数据**(客户姓名含「测试111」、手机号含 `12123456789` 等非法号码)。
**关键交互** —— ①切换八类 tab / 四个状态 tab → 过滤列表;②行首勾选框多选 → 对选中项批量执行;③「电话提醒」→ 外呼(App 内经容器 `dial` 桥接,见[验收标准](#447-验收标准));④「发送短信」/「发送微信」→ 手动触达;⑤「完成」→ 关单;⑥「转交」→ 移交他人;⑦「列设置」→ 自定义显示列;⑧「更多筛选」/「设为常用」→ 条件筛选与常用条件保存。
**可用角色** —— 店长 ✅;技工 ❓ `TODO(REQ-RMD-005)`。**⚠️ 与 REQ-ACC-006 一致,该项关闭前按更严格一侧实现(技工不可见)。**
**需求关联** —— [REQ-RMD-001](#446-业务规则) 承接方式、[REQ-RMD-003](#446-业务规则) 自动提醒、[REQ-RMD-006](#446-业务规则) 短信额度
页面构成:
- 顶部双看板:「待我处理的提醒单」与「所有未处理的提醒单」,各按八类规则分列计数;
- 八类 tab(服务提醒 / 保险提醒 / 检测异常提醒 / 特定人群提醒 / 车辆年检到期提醒 / 卡到期提醒 / 意向管理 / 新车在保);
- 流程条:①设置提醒规则 → ②车主到店消费 → ③车主完工离店 → ④生成提醒单并跟进 → ⑤临近服务日,提醒车主(可自动发送短信微信)→ ⑥车主再次到店;
- 状态 tab:我未完成 / 我已完成 / 所有未完成 / 所有已完成;
- 提醒单列表字段:提醒单号、客户姓名、手机号、车牌号、上次服务门店、上次服务日期、提醒类别、提醒来源、关联单号;
- 操作区:操作 / 电话提醒 / 发送短信 / 发送微信 / 完成 / 转交 / 列设置。
## 4.4.4 跟进提醒单
![原型-提醒-跟进提醒单](../images/原型-提醒-跟进提醒单.png)
**页面内容** —— **与上一张是同一个 F6 页面**(同一份表格、同一批数据),区别只是流程条高亮在第 ③ 步并另加了两个 PPT 标注框,图左下角还残留德文占位文字 `Individueller Informationsbereich`,说明本图取自 PPT 模板。
**关键交互** —— 无新增交互。跟进动作就是上一张图中列表上方的那排按钮(电话提醒 / 发送短信 / 发送微信 / 完成 / 转交),**「跟进提醒单」不是一个独立页面**。
**可用角色** —— 同 [4.4.3](#443-生成提醒单):店长 ✅;技工 ❓ `TODO(REQ-RMD-005)`
**需求关联** —— [REQ-RMD-003](#446-业务规则) 自动提醒、[REQ-RMD-006](#446-业务规则) 短信额度。本图主要作跟进手段的分类佐证,不引入新页面需求。
> **本图澄清了一处结构误解**: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 的待办、消息或首页看板,也不参与[弱网与离线](../Continental-Retail-APP-PRD.md#86-弱网与离线)策略;页面内的一切行为都是 F6 的行为。
## 4.4.6 业务规则
**REQ-RMD-001 承接方式** —— 已定:以 Embedded H5 嵌入 F6 现有提醒页,App 不做原生实现,见 [4.4.5](#445-承接方式)
**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](#445-承接方式)
## 4.4.7 验收标准
1. 门店未接入 F6 时,提醒入口不显示;
2. 从提醒入口进入后,F6 提醒页正常加载,登录态与门店上下文自动带入,**不出现二次登录**;
3. 票据过期时容器自动换票并重载,用户无感知;
4. 页面内「电话提醒」可调起系统拨号盘(经容器的 `dial` 桥接能力,见 [7.3](../Continental-Retail-APP-PRD.md#73-f6-集成边界));
5. 切换门店或退出登录后,已打开的提醒页立即失效并关闭。
---
## 附:本模块归拢信息
> 以下内容从主文件的其它章节归拢而来,便于本模块独立评审。**回灌主文件时不处理本分界线以下的部分**——主文件的附录仍是全局视图。
### 附-1 业务数据字典(主文件附录 A.4)
| # | 数据集 | 来源 | 安全 | 备注 |
| --- | --- | --- | --- | --- |
| 1 | 提醒规则、提醒单、提醒作业 | F6 Backend | HTTPS | **F6 后台自动按规则生成提醒单**App 以 Embedded H5 嵌入展示,不落地也不回写,见 [4.4.5](#445-承接方式) |
提醒模块数据集(摘自主文件[附录 A.4](../Continental-Retail-APP-PRD.md#a4-提醒)
> 本模块是全文**唯一一个 App 侧零落地、零回写**的模块 —— 数据全在 F6,App 只提供容器。因此附录 A 只有一行,也不需要字段级清单。
### 附-2 权限矩阵(主文件附录 B 本模块分行)
**图例**:✅ 完整权限 · 🔸 受限 · ⚙️ 需店长/后台显式授权 · ✗ 无权限 · ❓ 待确认
| 功能 | 店长 | 技工 | 备注 / 待确认 |
| --- | --- | --- | --- |
| 设置提醒规则 | ✅ | ✗ | 属门店管理职能 |
| 生成 / 跟进提醒单 | ✅ | ❓ | 页内权限由 F6 控制,App 只控入口可见性 `TODO(REQ-RMD-005)` |
提醒模块权限矩阵(摘自主文件[附录 B](../Continental-Retail-APP-PRD.md#附录-b-权限矩阵)
适用的全局权限实施规则:接口层强制(REQ-ACC-004);⚙️ 类由店长或后台经[人员管理「可用系统」](./09-STM-门店管理.md#49-门店管理)授予(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](../Continental-Retail-APP-PRD.md#1024-提醒rmd)2 条)
### 附-4 配图清单(主文件附录 C 4.4 节)
| 序 | 说明 | 文件 |
| --- | --- | --- |
| 1 | 原型-设置提醒规则(F6「客情维护 > 商机设置」,八类 tab + 规则表 + 启停开关) | `../images/原型-提醒-设置提醒规则.png` |
| 2 | 原型-生成提醒单(F6 服务提醒列表,双看板 + 四状态 tab + 跟进按钮行,测试数据) | `../images/原型-提醒-生成提醒单.png` |
| 3 | 原型-跟进提醒单(**与上图同一页面**,PPT 标注四类跟进手段) | `../images/原型-提醒-跟进提醒单.png` |
提醒模块配图清单,3 张(原型 3)。说明较主文件[附录 C](../Continental-Retail-APP-PRD.md#附录-c-图表清单)已按实际截图内容补充,主文件附录 C 回灌时应一并更新。
### 附-5 本次拆分新增发现
本模块**未新增编号需求**(提醒能力整体外包给 F6,App 侧不产生新需求)。逐图核看得到三点观察,供评审参考:
1. **4.4.3 与 4.4.4 是同一个 F6 页面**,不是两个。已就地写进 [4.4.4](#444-跟进提醒单) 的说明块 —— 影响的是嵌入时的 URL 数量(1 个而非 2 个),不影响需求条目。
2. **「PC 版式展示降级」已有实证**。[REQ-RMD-007](#446-业务规则) 此前只是推断,本次在设置提醒规则图上看到了表格右侧列被截断 + 横向滚动条,可作为向 F6 提移动端页面需求时的直接依据。
3. **F6 侧数据同样含测试残留**(客户姓名 `无` / `测试等级` / `测试111`,手机号 `12123456789` 等非法号码)。与[库存模块](./07-INV-库存.md#附-5-本次拆分新增发现待业务确认)发现的同类问题一致,但**本模块不为此立需求** —— 数据在 F6 侧、清洗责任也在 F6 侧,App 只作展示。若上线前 F6 未清理,属对方系统的数据质量问题,建议在集成联调时一并提出。