Add under-anything knowledge dashboard
This commit is contained in:
qiaoxinjiu
544
wishfulfilled-wiki/05_需求文档/00-系统总览.md
Normal file
544
wishfulfilled-wiki/05_需求文档/00-系统总览.md
Normal file
@@ -0,0 +1,544 @@
|
||||
1|# 如愿 · 系统总览 v1.0
|
||||
2|
|
||||
3|## 文件信息
|
||||
4|
|
||||
5|- 文件名称：`00-系统总览.md`
|
||||
6|- 项目代号：**如愿**
|
||||
7|- 工作目录：`/root/user-business/`
|
||||
8|- 当前版本：`v1.0`
|
||||
9|- 创建日期：`2026-05-22`
|
||||
10|- 上游基线：
|
||||
11| - `docs-from-business/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`
|
||||
12| - `docs-from-business/20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`
|
||||
13|
|
||||
14|## 目录
|
||||
15|
|
||||
16|1. [项目目标与原则](#1-项目目标与原则)
|
||||
17|2. [系统总边界](#2-系统总边界)
|
||||
18|3. [子系统划分](#3-子系统划分)
|
||||
19|4. [子系统间依赖关系](#4-子系统间依赖关系)
|
||||
20|5. [角色 → 独立前端映射](#5-角色--独立前端映射)
|
||||
21|6. [子系统内外边界明细](#6-子系统内外边界明细)
|
||||
22|7. [总系统级业务澄清问题清单](#7-总系统级业务澄清问题清单)
|
||||
23|8. [待确认的内外边界](#8-待确认的内外边界)
|
||||
24|9. [附录：子系统文档索引](#9-附录子系统文档索引)
|
||||
25|
|
||||
26|---
|
||||
27|
|
||||
28|## 1. 项目目标与原则
|
||||
29|
|
||||
### 1.1 项目代号："如愿"
|
||||
|
||||
> 取名"如愿"——系统做好能做的所有事（身份识别、需求评估、计划调度、渠道协同、风险拦截、结果追踪），让每一次运营投入都如愿转化为真实的评价提升和 ASIN 健康增长。Amazon 是否展示评价有平台的不确定性，但系统必须把可控环节做到极致。
|
||||
33|
|
||||
34|### 1.2 核心架构目标
|
||||
35|
|
||||
36|| # | 目标 | 说明 |
|
||||
37|| --- | --- | --- |
|
||||
38|| G1 | 前端分离 | 不同角色拥有独立前端应用，按需集成子系统能力 |
|
||||
39|| G2 | 清晰系统边界 | 明确系统内外边界，区分内部可控与外部依赖 |
|
||||
40|| G3 | 子系统解耦 | 子系统通过 API 契约通信，支持独立开发、独立部署 |
|
||||
41|| G4 | 并行开发 | 子系统之间尽量减少串行依赖，允许多团队并行推进 |
|
||||
42|| G5 | 独立角色前端 | Amazon 运营、用户运营、客服、风险管理、KOC/KOL 运营各自拥有独立前端 |
|
||||
43|
|
||||
44|### 1.3 架构原则
|
||||
45|
|
||||
46|| 原则 | 说明 |
|
||||
47|| --- | --- |
|
||||
48|| **单一数据源** | 每个业务事实只有一个子系统负责写入（Owner），其他子系统只读或通过 API 调用 |
|
||||
49|| **API 契约优先** | 子系统间通过明确 API 契约通信，先定义契约再实现 |
|
||||
50|| **真实人为核心** | 所有额度、风险、历史判断围绕「真实人」而非单一账号 |
|
||||
51|| **每次互动重判** | 身份、额度、风险不是一次性的，每次有效互动需重做判断 |
|
||||
52|| **审计不可少** | 所有状态变更、敏感访问、人工干预必须留痕 |
|
||||
53|
|
||||
54|---
|
||||
55|
|
||||
56|## 2. 系统总边界
|
||||
57|
|
||||
58|### 2.1 边界总图
|
||||
59|
|
||||
60|```
|
||||
61|┌─────────────────────────────────────────────────────────────────────┐
|
||||
62|│ 如愿 系统边界 │
|
||||
63|│ │
|
||||
64|│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │
|
||||
65|│ │ Amazon │ │ 用户运营 │ │ Amazon │ │ 风险/黑名 │ │
|
||||
66|│ │ 运营前端 │ │ 前端 │ │ 运营总监 │ │ 单前端 │ │
|
||||
67|│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
|
||||
68|│ │ │ │ │ │
|
||||
69|│ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ ┌────┴─────┐ │
|
||||
70|│ │ 客服前端 │ │ 客服管理 │ │ KOC/KOL │ │ 管理驾驶 │ │
|
||||
71|│ │ │ │ 前端 │ │ 运营前端 │ │ 舱 │ │
|
||||
72|│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └────┬─────┘ │
|
||||
73|│ │ │ │ │ │
|
||||
74|│ ═════╪══════════════╪══════════════╪══════════════╪══════ API网关 │
|
||||
75|│ │ │ │ │ │
|
||||
76|│ ┌────┴──────────────┴──────────────┴──────────────┴─────┐ │
|
||||
77|│ │ 内部子系统 │ │
|
||||
78|│ │ ┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐ │ │
|
||||
79|│ │ │ 用户身 │ │需求与计│ │额度与频│ │多渠道触│ │ │
|
||||
80|│ │ │份上下文│ │划管理 │ │ 控 │ │达引擎 │ │ │
|
||||
81|│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │
|
||||
82|│ │ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ ┌───┴────┐ │ │
|
||||
83|│ │ │客服工单│ │风险与反│ │评价结果│ │KOC/KOL │ │ │
|
||||
84|│ │ │与管理 │ │ 欺诈 │ │ 追踪 │ │ 协作 │ │ │
|
||||
85|│ │ └───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘ │ │
|
||||
86|│ │ ┌───┴────┐ │ │
|
||||
87|│ │ │审计与通│ │ │
|
||||
88|│ │ │知中心 │ │ │
|
||||
89|│ │ └────────┘ │ │
|
||||
90|│ └───────────────────────────────────────────────────────────┘ │
|
||||
91|│ │
|
||||
92|└─────────────────────────────────────────────────────────────────────┘
|
||||
93|
|
||||
94| ║ 外部系统 ║
|
||||
95|
|
||||
96|┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
|
||||
97|│ Amazon │ │ JOYHUB │ │JOYCOLLAB │ │ 邮件服务 │ │ 财务系统 │
|
||||
98|│ Marketplace│ │ 用户平台 │ │ KOC平台 │ │ (ESP) │ │(返款/退款)│
|
||||
99|└──────────┘ └──────────┘ └──────────┘ └──────────┘ └──────────┘
|
||||
100|```
|
||||
101|
|
||||
102|### 2.2 系统内部（如愿系统）
|
||||
103|
|
||||
104|| # | 子系统 | 代号 | 核心职责 | 详情文档 |
|
||||
105|| --- | --- | --- | --- | --- |
|
||||
106|| S1 | 用户身份与上下文 | `identity` | 真实人识别、身份线索归并、用户上下文卡 | [01-用户身份与上下文](01-子系统-用户身份与上下文.md) |
|
||||
107|| S2 | 需求与计划管理 | `planning` | 需求触发（人工/自动）、计划生成（推新/回评/免评）、审批工作流 | [02-需求与计划管理](02-子系统-需求与计划管理.md) |
|
||||
108|| S3 | 额度与频控 | `quota` | 月度测评/免评额度台账、累计评价额度、频控、预占 | [03-额度与频控](03-子系统-额度与频控.md) |
|
||||
109|| S4 | 多渠道触达引擎 | `outreach` | IM/EDM/APP Push/TEL 渠道调度、路由、去重、发送 | [04-多渠道触达引擎](04-子系统-多渠道触达引擎.md) |
|
||||
110|| S5 | 客服工单与管理 | `support` | 工单生命周期、自动分配、排班出勤、绩效统计 | [05-客服工单与管理](05-子系统-客服工单与管理.md) |
|
||||
111|| S6 | 风险与反欺诈 | `risk` | 强弱关联判断、黑名单、双重退款检测、风险事件 | [06-风险与反欺诈](06-子系统-风险与反欺诈.md) |
|
||||
112|| S7 | 评价结果追踪 | `review` | 评价提交记录、Amazon 展示核验、ASIN 健康回流 | [07-评价结果追踪](07-子系统-评价结果追踪.md) |
|
||||
113|| S8 | KOC/KOL 协作 | `creator` | KOC/KOL 匹配、内容跟踪、Code 管理、JOYCOLLAB 同步 | [08-KOC-KOL协作](08-子系统-KOC-KOL协作.md) |
|
||||
114|| S9 | 审计与通知中心 | `audit` | 状态变更审计、敏感访问日志、多类型通知/告警 | [09-审计与通知中心](09-子系统-审计与通知中心.md) |
|
||||
115|
|
||||
116|### 2.3 系统外部（外部依赖）
|
||||
117|
|
||||
118|| # | 外部系统 | 说明 | 交互方式 | 确认状态 |
|
||||
119|| --- | --- | --- | --- | --- |
|
||||
120|| E1 | **Amazon Marketplace** | 订单数据、评价数据、ASIN/Listing 健康数据、退款数据 | API 拉取 / 爬取 | ⚠️ 待确认 |
|
||||
121|| E2 | **JOYHUB 用户平台** | JOYHUB ID、设备信息、APP 行为数据、绑定玩具数据 | API 同步 | ⚠️ 待确认 |
|
||||
122|| E3 | **JOYCOLLAB** | KOC/KOL 内容数据、Code 使用数据、带货订单数据 | API 同步 | ⚠️ 待确认 |
|
||||
123|| E4 | **邮件服务 (ESP)** | EDM 发送、送达/打开/点击追踪、退订/硬退信 | SMTP + Webhook | ⚠️ 待确认 |
|
||||
124|| E5 | **财务系统** | 返款执行、返款状态、退款记录（OA 侧） | API 调用 | ⚠️ 待确认 |
|
||||
125|| E6 | **APP Push 服务** | APP 推送通道（FCM/APNs） | SDK / API | ⚠️ 待确认 |
|
||||
126|| E7 | **电话系统** | 外呼能力、来电识别、通话记录 | API / SIP | ⚠️ 待确认 |
|
||||
127|| E8 | **IM 平台 (WhatsApp?)** | IM 消息收发 | API | ⚠️ 待确认 |
|
||||
128|
|
||||
129|---
|
||||
130|
|
||||
131|## 3. 子系统划分
|
||||
132|
|
||||
133|### 3.1 划分依据
|
||||
134|
|
||||
135|子系统按照**业务域内聚**原则划分，每个子系统：
|
||||
136|
|
||||
137|1. 拥有明确的数据所有权（该子系统是某些核心数据对象的唯一写入方）
|
||||
138|2. 对外暴露清晰的 API 契约
|
||||
139|3. 可以独立开发、测试、部署
|
||||
140|4. 尽量减少对其他子系统的强依赖（启动依赖）
|
||||
141|
|
||||
142|### 3.2 各子系统数据所有权
|
||||
143|
|
||||
144|| 子系统 | 拥有（写入）的核心数据对象 |
|
||||
145|| --- | --- |
|
||||
146|| identity | `person_profiles`、`person_identity_links`、`contact_context_snapshots`、`device_records` |
|
||||
147|| planning | `demands`、`plans`、`plan_items`、`approval_records`、`asin_catalog` |
|
||||
148|| quota | `person_quota_ledgers`、`quota_reservations`、`frequency_control_records` |
|
||||
149|| outreach | `channel_route_decisions`、`channel_dedup_records`、`im_interaction_records`、`edm_message_events`、`app_touch_events`、`tel_call_records` |
|
||||
150|| support | `support_tickets`、`support_followups`、`support_assignment_logs`、`attendance_records`、`shift_schedules`、`support_performance_snapshots` |
|
||||
151|| risk | `risk_signals`、`risk_cases`、`blacklist_entities`、`refund_match_results` |
|
||||
152|| review | `review_submission_records`、`review_display_checks`、`review_results` |
|
||||
153|| creator | `exemption_plan_tasks`、`creator_content_records`、`creator_profiles`、`code_records` |
|
||||
154|| audit | `interaction_audit_logs`、`notification_records`、`manual_review_tasks` |
|
||||
155|
|
||||
156|---
|
||||
157|
|
||||
158|## 4. 子系统间依赖关系
|
||||
159|
|
||||
160|### 4.1 依赖图
|
||||
161|
|
||||
162|```
|
||||
163| ┌─────────────────────────────────────────────┐
|
||||
164| │ audit (审计与通知) │
|
||||
165| │ ← 所有子系统向 audit 发送事件 │
|
||||
166| └─────────────────────────────────────────────┘
|
||||
167| ↑
|
||||
168| ┌─────────┬─────────┬─────┼─────┬─────────┬─────────┐
|
||||
169| │ │ │ │ │ │ │
|
||||
170|┌───┴───┐ ┌───┴───┐ ┌───┴───┐ │ ┌───┴───┐ ┌───┴───┐ ┌───┴───┐
|
||||
171|│ review│ │creator│ │support│ │ │ risk │ │ quota │ │outreach│
|
||||
172|│(评价) │ │(KOC) │ │(客服) │ │ │(风险) │ │(额度) │ │(触达) │
|
||||
173|└───┬───┘ └───┬───┘ └───┬───┘ │ └───┬───┘ └───┬───┘ └───┬───┘
|
||||
174| │ │ │ │ │ │ │
|
||||
175| └─────────┼─────────┼─────┼─────┼─────────┼─────────┘
|
||||
176| │ │ │ │ │
|
||||
177| ┌────┴─────────┴─────┼─────┼─────────┴────────┐
|
||||
178| │ │ │ │
|
||||
179| ▼ ▼ ▼ ▼
|
||||
180| ┌─────────┐ ┌──────────────┐ ┌─────────┐
|
||||
181| │planning │←─────────│ identity │─────────→│ quota │
|
||||
182| │(计划) │ │ (用户身份) │ │ (额度) │
|
||||
183| └─────────┘ └──────────────┘ └─────────┘
|
||||
184|```
|
||||
185|
|
||||
186|### 4.2 依赖矩阵
|
||||
187|
|
||||
188|| ↓ 消费者 \ 提供者 → | identity | planning | quota | outreach | support | risk | review | creator | audit |
|
||||
189|| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
|
||||
190|| **identity** | - | - | - | - | - | R | - | - | E |
|
||||
191|| **planning** | **R** | - | R | - | - | R | R | - | E |
|
||||
192|| **quota** | **R** | - | - | - | - | - | R | - | E |
|
||||
193|| **outreach** | R | R | R | - | - | R | - | - | E |
|
||||
194|| **support** | R | - | - | - | - | R | - | - | E |
|
||||
195|| **risk** | R | - | - | - | - | - | - | - | E |
|
||||
196|| **review** | R | R | - | - | - | - | - | R | E |
|
||||
197|| **creator** | - | R | R | - | - | - | - | - | E |
|
||||
198|| **audit** | - | - | - | - | - | - | - | - | - |
|
||||
199|
|
||||
200|**图例：** `R` = 只读依赖（通过 API 查询），`E` = 事件发送（fire-and-forget），`-` = 无依赖
|
||||
201|
|
||||
202|### 4.3 启动依赖（必须就绪才能工作）
|
||||
203|
|
||||
204|| 子系统 | 启动依赖 | 说明 |
|
||||
205|| --- | --- | --- |
|
||||
206|| identity | 无硬依赖 | 可独立启动（需要 JOYHUB 数据同步） |
|
||||
207|| planning | identity（软依赖） | 无 identity 时可先操作，但无法做人群匹配 |
|
||||
208|| quota | identity（软依赖） | 额度按真实人计算，未归并时按单一账号 |
|
||||
209|| outreach | identity, planning, quota（软依赖） | 无依赖时可先建渠道基础设施 |
|
||||
210|| support | identity（软依赖） | 无用户上下文卡时可先跑工单 |
|
||||
211|| risk | identity（软依赖） | 强/弱关联依赖身份数据 |
|
||||
212|| review | identity, planning（软依赖） | 评价需关联计划和用户 |
|
||||
213|| creator | planning（软依赖） | 免评计划入口 |
|
||||
214|| audit | 无硬依赖 | 完全独立 |
|
||||
215|
|
||||
216|> **软依赖** = 可降级运行，核心功能不受阻。例如 outreach 在 identity 不可用时仍可发送消息，但缺少用户上下文。
|
||||
217|
|
||||
218|---
|
||||
219|
|
||||
220|## 5. 角色 → 独立前端映射
|
||||
221|
|
||||
222|### 5.1 前端应用矩阵
|
||||
223|
|
||||
224|| 前端应用 | 目标角色 | 集成的子系统 | 部署形态 |
|
||||
225|| --- | --- | --- | --- |
|
||||
226|| **运营工作台** | Amazon 运营、Amazon 运营总监 | planning + review + quota (查询) | Web SPA |
|
||||
227|| **用户运营中心** | 用户运营、用户运营负责人/组长 | planning + outreach + quota + review | Web SPA |
|
||||
228|| **客服工作台** | 菲律宾客服组员 | support + identity (上下文卡) + outreach (TEL) | Web SPA / 桌面端 |
|
||||
229|| **客服管理台** | 菲律宾客服负责人、客服组长 | support (管理模块) + audit | Web SPA |
|
||||
230|| **风险控制台** | 风险/黑名单相关人员 | risk + identity (上下文卡) + audit | Web SPA |
|
||||
231|| **达人协作台** | KOC/KOL 运营 | creator + outreach (协同) + review (免评结果) | Web SPA |
|
||||
232|| **管理驾驶舱** | 运营总监、用户运营负责人 | 跨子系统聚合看板 (planning + outreach + support + review) | Web SPA |
|
||||
233|
|
||||
234|### 5.2 角色-功能矩阵
|
||||
235|
|
||||
236|| 功能 \ 角色 | Amazon运营 | 运营总监 | 用户运营 | 用户负责人 | 客服组员 | 客服组长 | 客服负责人 | 风险人员 | KOC运营 |
|
||||
237|| --- |:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
|
||||
238|| 提需求（推新/回评/免评） | ✓ | ✓ | - | - | - | - | - | - | - |
|
||||
239|| 审批计划 | - | ✓ | - | ✓ | - | - | - | - | - |
|
||||
240|| 评估需求 | - | - | ✓ | ✓ | - | - | - | - | - |
|
||||
241|| 生成计划/调资源 | - | - | ✓ | ✓ | - | - | - | - | - |
|
||||
242|| 查看 ASIN 健康 | ✓ | ✓ | ✓ | - | - | - | - | - | - |
|
||||
243|| 处理工单 | - | - | - | - | ✓ | ✓ | - | - | - |
|
||||
244|| 分配工单 | - | - | - | - | - | ✓ | ✓ | - | - |
|
||||
245|| 电话外呼/接听 | - | - | - | - | ✓ | - | - | - | - |
|
||||
246|| 查看排班出勤 | - | - | - | - | - | ✓ | ✓ | - | - |
|
||||
247|| 绩效统计 | - | - | - | - | - | ✓ | ✓ | - | - |
|
||||
248|| 风险审核 | - | - | - | - | - | - | - | ✓ | - |
|
||||
249|| 黑名单管理 | - | - | - | - | - | - | - | ✓ | - |
|
||||
250|| KOC/KOL 匹配 | - | - | - | - | - | - | - | - | ✓ |
|
||||
251|| 内容跟踪 | - | - | ✓ | - | - | - | - | - | ✓ |
|
||||
252|
|
||||
253|---
|
||||
254|
|
||||
255|## 6. 子系统内外边界明细
|
||||
256|
|
||||
257|### 6.1 identity — 用户身份与上下文
|
||||
258|
|
||||
259|| 维度 | 说明 |
|
||||
260|| --- | --- |
|
||||
261|| **对内** | 管理真实人归并逻辑、身份线索关联（JOYHUB ID↔邮箱↔电话↔设备↔订单→真实人ID）、用户上下文卡聚合与快照、设备变化识别 |
|
||||
262|| **对外（提供给其他子系统）** | `GET /api/identity/person/{context}` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/merge` — 归并请求 |
|
||||
263|| **依赖外部系统** | JOYHUB（用户基础数据）、APP（设备数据） |
|
||||
264|| **待确认边界** | 真实人归并是自动还是人工确认？归并拆分（合并错了如何回退）？非 APP 用户的身份线索从哪里同步（ESM 的邮箱清洗？） |
|
||||
265|
|
||||
266|### 6.2 planning — 需求与计划管理
|
||||
267|
|
||||
268|| 维度 | 说明 |
|
||||
269|| --- | --- |
|
||||
270|| **对内** | 需求触发（人工提交 + 自动触发规则）、需求评估、计划创建（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |
|
||||
271|| **对外（提供给其他子系统）** | `GET /api/plans/{id}` — 计划详情；`GET /api/plans?status=approved` — 待执行计划；`POST /api/demands` — 创建需求 |
|
||||
272|| **依赖外部系统** | Amazon（ASIN 数据、销售数据、评价缺口） |
|
||||
273|
|
||||
274|### 6.3 quota — 额度与频控
|
||||
275|
|
||||
276|| 维度 | 说明 |
|
||||
277|| --- | --- |
|
||||
278|| **对内** | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |
|
||||
279|| **对外（提供给其他子系统）** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+预占；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认占用 |
|
||||
280|| **依赖外部系统** | 无直接外部系统依赖 |
|
||||
281|| **待确认边界** | 额度预占有效期多长？跨月额度如何处理（月末最后一天预占，下月一号释放还是保留？） |
|
||||
282|
|
||||
283|### 6.4 outreach — 多渠道触达引擎
|
||||
284|
|
||||
285|| 维度 | 说明 |
|
||||
286|| --- | --- |
|
||||
287|| **对内** | 渠道路由决策、渠道去重、IM 推送（分层 A/B/C）、EDM 发送与行为追踪、APP Push、TEL 任务生成 |
|
||||
288|| **对外（提供给其他子系统）** | `POST /api/outreach/send` — 发送触达；`GET /api/outreach/history/{person_id}` — 触达历史 |
|
||||
289|| **依赖外部系统** | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |
|
||||
290|| **待确认边界** | IM 具体是什么平台（WhatsApp/自研 IM）？EDM 模板管理在 outreach 内还是独立内容管理？APP Push 是否复用 JOYHUB 现有 Push 通道？ |
|
||||
291|
|
||||
292|### 6.5 support — 客服工单与管理
|
||||
293|
|
||||
294|| 维度 | 说明 |
|
||||
295|| --- | --- |
|
||||
296|| **对内** | 工单生命周期、自动分配（按排班/在线/负载）、答应配合状态机、出勤/排班/绩效 |
|
||||
297|| **对外（提供给其他子系统）** | `POST /api/tickets` — 创建工单；`GET /api/tickets/{id}` — 工单详情；`GET /api/support/stats` — 绩效数据 |
|
||||
298|| **依赖外部系统** | 无直接外部系统依赖（电话记录来自 outreach TEL 模块） |
|
||||
299|| **待确认边界** | 客服是否使用独立 IM 工具还是复用 outreach 的 IM 通道？排班数据是否与现有 HR 系统对接？ |
|
||||
300|
|
||||
301|### 6.6 risk — 风险与反欺诈
|
||||
302|
|
||||
303|| 维度 | 说明 |
|
||||
304|| --- | --- |
|
||||
305|| **对内** | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测（Amazon退款 vs OA返款） |
|
||||
306|| **对外（提供给其他子系统）** | `GET /api/risk/check/{person_id}` — 风险查询；`POST /api/risk/report` — 上报风险信号 |
|
||||
307|| **依赖外部系统** | Amazon（退款数据）、财务系统（OA 返款数据） |
|
||||
308|
|
||||
309|### 6.7 review — 评价结果追踪
|
||||
310|
|
||||
311|| 维度 | 说明 |
|
||||
312|| --- | --- |
|
||||
313|| **对内** | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康更新回流、计划完成度计算 |
|
||||
314|| **对外（提供给其他子系统）** | `POST /api/reviews/submission` — 记录提交；`GET /api/reviews/status/{plan_id}` — 计划评价进度 |
|
||||
315|| **依赖外部系统** | Amazon（评价展示状态、ASIN 评分数据） |
|
||||
316|
|
||||
317|### 6.8 creator — KOC/KOL 协作
|
||||
318|
|
||||
319|| 维度 | 说明 |
|
||||
320|| --- | --- |
|
||||
321|| **对内** | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪 |
|
||||
322|| **对外（提供给其他子系统）** | `GET /api/creators/match?plan_id=` — 匹配推荐；`POST /api/creators/tasks` — 创建协作任务 |
|
||||
323|| **依赖外部系统** | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |
|
||||
324|
|
||||
325|### 6.9 audit — 审计与通知中心
|
||||
326|
|
||||
327|| 维度 | 说明 |
|
||||
328|| --- | --- |
|
||||
329|| **对内** | 所有子系统的状态变更审计、敏感字段访问日志、多类型通知（额度预警/超时提醒/紧急 Listing 告警/审批通知） |
|
||||
330|| **对外（提供给其他子系统）** | `POST /api/audit/event` — 上报审计事件；`POST /api/notifications/send` — 发送通知 |
|
||||
331|| **依赖外部系统** | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |
|
||||
332|| **待确认边界** | 审计日志保留策略？通知模板管理在 audit 内还是需要独立内容管理？ |
|
||||
333|
|
||||
334|---
|
||||
335|
|
||||
336|## 7. 总系统级业务澄清问题清单
|
||||
337|
|
||||
338|> 以下问题需要与业务方确认，涉及跨子系统边界、关键业务规则和外部系统对接。
|
||||
339|
|
||||
340|### 7.1 外部系统对接（8 项）
|
||||
341|
|
||||
342|| # | 问题 | 涉及外部系统 | 优先级 |
|
||||
343|| --- | --- | --- | --- |
|
||||
344|| Q-E1 | Amazon 数据以什么方式接入？（MWS/SP-API 授权拉取、爬虫、CSV 导入、已有中间表？） | Amazon | **P0** |
|
||||
345|| Q-E2 | JOYHUB 现有数据有哪些可用？是否有现成 API？JOYHUB ID ↔ 邮箱 ↔ 设备 ↔ 订单 的关联数据是否已存储？ | JOYHUB | **P0** |
|
||||
346|| Q-E3 | JOYCOLLAB 数据同步方向是单向（COLLAB→USER）还是双向？同步频率？Code 生成是在 COLLAB 还是 USER？ | JOYCOLLAB | **P0** |
|
||||
347|| Q-E4 | 当前 EDM 使用什么邮件服务？（SendGrid / Mailchimp / SES / 自建？）是否有现成的送达/打开/点击追踪？ | ESP | **P0** |
|
||||
348|| Q-E5 | OA 返款系统是哪个？是否有 API 可以查询返款状态和返款记录？（用于双重退款比对） | 财务系统 | **P0** |
|
||||
349|| Q-E6 | APP Push 是否复用 JOYHUB 现有 Push 通道还是需要独立接入 FCM/APNs？ | APP Push | P1 |
|
||||
350|| Q-E7 | 电话系统用什么方案？（自建 SIP / 第三方云呼叫中心？）是否已有通话记录存储？ | 电话系统 | P1 |
|
||||
351|| Q-E8 | IM 平台具体是什么？（WhatsApp Business API / 自研 IM / Facebook Messenger？） | IM 平台 | P1 |
|
||||
352|
|
||||
353|### 7.2 用户身份体系（5 项）
|
||||
354|
|
||||
355|| # | 问题 | 优先级 |
|
||||
356|| --- | --- | --- |
|
||||
357|| Q-I1 | 「真实人」归并是完全自动还是需要人工确认？自动归并错误时如何拆分？（拆分会影响到已关联的历史评价和额度） | **P0** |
|
||||
358|| Q-I2 | 非 APP 用户（只知道邮箱）如何建立真实人？没有设备号仅凭邮箱+收件地址归并，置信度阈值如何定？ | **P0** |
|
||||
359|| Q-I3 | JOYHUB ID 与真实人是 1:1 还是 N:1？（一个真实人可能拥有多个 JOYHUB ID） | P1 |
|
||||
360|| Q-I4 | 设备变化的「换机」判定标准是什么？（同一 JOYHUB ID 下设备号变化？多久内变化算换机？） | P1 |
|
||||
361|| Q-I5 | 用户上下文卡的「快照」是否需要保留历史版本？（每次互动生成新快照 vs 覆盖上次） | P2 |
|
||||
362|
|
||||
363|### 7.3 额度与频控规则（6 项）
|
||||
364|
|
||||
365|| # | 问题 | 优先级 |
|
||||
366|| --- | --- | --- |
|
||||
367|| Q-Q1 | 月度额度按自然月还是按 30 天滚动？如果是自然月，预占在月末最后一天是否需要特殊处理？ | **P0** |
|
||||
368|| Q-Q2 | 「测评 4 次」的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 次评价？（如果一次计划要求用户提交多条评价怎么算） | **P0** |
|
||||
369|| Q-Q3 | 「累计 12 个评价」是永久上限还是可以重置？（例如用户长期优质，是否可以放宽？） | P1 |
|
||||
370|| Q-Q4 | 额度预占的有效期多长？如果预占后用户始终未响应，多久释放额度？ | P1 |
|
||||
371|| Q-Q5 | 频控规则中的「渠道频控」具体阈值是多少？（IM 每日最多推几次？EDM 每周最多几封？） | P1 |
|
||||
372|| Q-Q6 | 「接近上限时提前预警」——预警阈值是还剩 1 次还是还剩 N%？ | P2 |
|
||||
373|
|
||||
374|### 7.4 计划与审批流程（5 项）
|
||||
375|
|
||||
376|| # | 问题 | 优先级 |
|
||||
377|| --- | --- | --- |
|
||||
378|| Q-P1 | 自动触发需求的条件是什么？（ASIN 评分低于多少？评价缺口多少条？Listing 健康到什么程度？） | **P0** |
|
||||
379|| Q-P2 | 审批链中的「指定负责人」如何确定？（系统自动按规则还是人工指定？规则是什么？） | **P0** |
|
||||
380|| Q-P3 | 计划审批后是否可以修改？修改是否需要重新审批？ | P1 |
|
||||
381|| Q-P4 | 计划之间是否有互斥关系？（同一个 ASIN 同时跑推新和回评计划是否可以？） | P1 |
|
||||
382|| Q-P5 | 「紧急计划」的判定标准和特殊审批流程？（谁可以标记为紧急？是否跳过某些审批节点？） | P1 |
|
||||
383|
|
||||
384|### 7.5 渠道协同与去重（5 项）
|
||||
385|
|
||||
386|| # | 问题 | 优先级 |
|
||||
387|| --- | --- | --- |
|
||||
388|| Q-C1 | 渠道优先级路由规则是否需要可配置？（例如针对某类用户调整 IM > EDM 的优先级） | **P0** |
|
||||
389|| Q-C2 | 用户已在客服工单中时「暂停自动触达」——是所有渠道暂停还是仅暂停与当前工单相关的渠道？ | P1 |
|
||||
390|| Q-C3 | EDM 引导注册 APP 后，如何识别「该 EDM 邮箱对应该 APP 用户」？靠什么字段关联？ | P1 |
|
||||
391|| Q-C4 | 渠道去重中「同一计划同一用户不重复通过多渠道路由」——如果高优先级渠道发送失败（退信/未送达），是否自动降级到下一渠道？ | P1 |
|
||||
392|| Q-C5 | IM 推送中的「催评卡片」和 APP Push 中的「催评推送」如何协调？（两者会不会同时推送给同一用户？） | P1 |
|
||||
393|
|
||||
394|### 7.6 客服与工单（5 项）
|
||||
395|
|
||||
396|| # | 问题 | 优先级 |
|
||||
397|| --- | --- | --- |
|
||||
398|| Q-S1 | 工单自动分配算法——「当前负载」如何计算？（按未关闭工单数？按最近 N 小时处理量？） | **P0** |
|
||||
399|| Q-S2 | 客服的「在线状态」如何获取？（手动切换在线/离线，还是自动检测活跃度？） | P1 |
|
||||
400|| Q-S3 | 「答应配合」的超时判定——答应后多少天未提交算超时？超时后提醒频率？ | P1 |
|
||||
401|| Q-S4 | 出勤排班是否与本系统内的排班模块管理还是对接外部 HR 系统？ | P1 |
|
||||
402|| Q-S5 | 客服转化统计中的 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按最终结果？） | P2 |
|
||||
403|
|
||||
404|### 7.7 风险与反欺诈（4 项）
|
||||
405|
|
||||
406|| # | 问题 | 优先级 |
|
||||
407|| --- | --- | --- |
|
||||
408|| Q-R1 | 「强关联」中哪些维度的命中可以直接自动化拦截，哪些需要人工复核？（文档说一旦命中直接进入高风险，但实际执行中是否所有强关联都自动拦截？） | **P0** |
|
||||
409|| Q-R2 | 双重退款检测——Amazon 退款数据如何及时获取？（T+1 同步？实时 Webhook？手动导入？） | **P0** |
|
||||
410|| Q-R3 | 黑名单是否有过期/申诉/解除机制？什么条件下可以从黑名单中移除？ | P1 |
|
||||
411|| Q-R4 | 风险信号的「弱关联」观察期多长？观察期过后是自动解除还是人工确认？ | P1 |
|
||||
412|
|
||||
413|### 7.8 评价结果与回流（4 项）
|
||||
414|
|
||||
415|| # | 问题 | 优先级 |
|
||||
416|| --- | --- | --- |
|
||||
417|| Q-V1 | Amazon 评价展示的核验方式是什么？（定时爬取 Amazon 页面？手动录入？用户上传截图？API？） | **P0** |
|
||||
418|| Q-V2 | 「Amazon 未展示 / 暂不可核验」的评价进入异常观察队列后，观察多久？复查频率？ | P1 |
|
||||
419|| Q-V3 | ASIN 健康「回流」的具体含义是什么？（更新 ASIN 评分/评价数到 planning 子系统，触发新一轮需求？） | P1 |
|
||||
420|| Q-V4 | 一个用户可能为多个 ASIN 提交评价——这些评价是否都计入同一个计划的完成度？ | P1 |
|
||||
421|
|
||||
422|### 7.9 KOC/KOL 协作（4 项）
|
||||
423|
|
||||
424|| # | 问题 | 优先级 |
|
||||
425|| --- | --- | --- |
|
||||
426|| Q-K1 | JOYCOLLAB 中 KOC/KOL 数据字段有哪些？（粉丝量、平台、国家、历史效果——文档提到但需确认完整字段） | **P0** |
|
||||
427|| Q-K2 | 「匹配 KOC/KOL」是运营人工选择还是系统自动推荐？推荐算法依赖什么数据？ | P1 |
|
||||
428|| Q-K3 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？是一对一（每个 KOC 独立 Code）还是一对多？ | P1 |
|
||||
429|| Q-K4 | KOC/KOL 的财务结算（提成/返点）是完全在财务系统还是在 USER 系统内触发？ | P1 |
|
||||
430|
|
||||
431|### 7.10 数据迁移与历史兼容（3 项）
|
||||
432|
|
||||
433|| # | 问题 | 优先级 |
|
||||
434|| --- | --- | --- |
|
||||
435|| Q-D1 | 现有 USER 后台 ERP 系统（`C:\XCODE\USER`）是否完全废弃还是部分模块保留？新旧系统切换策略？ | **P0** |
|
||||
436|| Q-D2 | 历史数据（已有评价记录、用户数据、工单记录）是否需要迁移到新系统？迁移范围和清洗策略？ | **P0** |
|
||||
437|| Q-D3 | 旧系统中存在的用户额度数据如何初始化？（历史测评次数、免评次数、累计评价数如何确定？） | **P0** |
|
||||
438|
|
||||
439|### 7.11 项目分期与 MVP 范围（5 项）
|
||||
440|
|
||||
441|| # | 问题 | 优先级 |
|
||||
442|| --- | --- | --- |
|
||||
443|| Q-M1 | 项目一期（MVP）的最小范围是什么？9 个子系统中哪些是必须的、哪些可以二期再做？ | **P0** |
|
||||
444|| Q-M2 | MVP 先支持哪个 Amazon 站点？（.com？还是多站点？）先支持哪种计划类型？（推新/回评/免评全部 or 先做回评？） | **P0** |
|
||||
445|| Q-M3 | 前端应用的优先级——7 个前端中哪些是 MVP 必须有？（客服工作台+运营工作台？还是全部都要？） | **P0** |
|
||||
446|| Q-M4 | 项目整体时间线和里程碑约束？（6 个月？1 年？是否有硬性 deadline？） | P1 |
|
||||
447|| Q-M5 | 开发团队规模和结构？（几个后端开发？几个前端？是否有专职 QA？）是否支持 9 个子系统并行开发？ | P1 |
|
||||
448|
|
||||
449|### 7.12 基础设施与部署（6 项）
|
||||
450|
|
||||
451|| # | 问题 | 优先级 |
|
||||
452|| --- | --- | --- |
|
||||
453|| Q-IN1 | 部署环境？（云厂商 AWS/阿里云？自建机房？）是否已有 Kubernetes 集群或考虑容器化部署？ | **P0** |
|
||||
454|| Q-IN2 | 数据库选型？（PostgreSQL / MySQL？）每子系统独立数据库还是共享数据库？是否已有数据库团队和规范？ | **P0** |
|
||||
455|| Q-IN3 | 子系统间异步通信方案？（消息队列：Kafka/RabbitMQ/Redis？还是全部同步 HTTP？） | **P0** |
|
||||
456|| Q-IN4 | API 网关选型？（Kong/Nginx/自研？）认证鉴权方案？（JWT/OAuth2/SSO？） | P1 |
|
||||
457|| Q-IN5 | 日志、监控、链路追踪方案？（ELK/Prometheus+Grafana/Jaeger？）是否已有公司级基础设施可复用？ | P1 |
|
||||
458|| Q-IN6 | 灾备和容灾要求？（RPO/RTO 目标？是否需要多可用区/异地容灾？数据备份频率？） | P2 |
|
||||
459|
|
||||
460|### 7.13 安全与合规（5 项）
|
||||
461|
|
||||
462|| # | 问题 | 优先级 |
|
||||
463|| --- | --- | --- |
|
||||
464|| Q-SC1 | 是否有需要通过的安全合规认证？（SOC2 / ISO 27001 / 等保？）对系统架构有何约束？ | P1 |
|
||||
465|| Q-SC2 | 用户个人数据（邮箱、电话、地址、设备号）的保留和删除策略？（GDPR 的「被遗忘权」如何处理？） | P1 |
|
||||
466|| Q-SC3 | Amazon 的 API 使用条款（SP-API Acceptable Use Policy）对数据存储和使用的限制？（评价数据是否可以长期存储？） | P1 |
|
||||
467|| Q-SC4 | 系统权限模型？（RBAC？角色和权限的粒度？是否需要支持数据行级权限——例如不同站点的运营只看自己的 ASIN？） | P1 |
|
||||
468|| Q-SC5 | 敏感数据（收款信息、设备号）的加密存储方案？传输加密（TLS）要求？ | P2 |
|
||||
469|
|
||||
470|### 7.14 技术栈与规范（4 项）
|
||||
471|
|
||||
472|| # | 问题 | 优先级 |
|
||||
473|| --- | --- | --- |
|
||||
474|| Q-TS1 | 后端技术栈偏好？（Python/FastAPI？Go？Node.js？Java？）是否有公司技术栈约束？ | P1 |
|
||||
475|| Q-TS2 | 前端技术栈偏好？（React/Vue/Angular？）是否有公司前端组件库或设计系统可复用？ | P1 |
|
||||
476|| Q-TS3 | API 规范标准？（OpenAPI 3.0？gRPC？）是否需要 BFF（Backend for Frontend）层？ | P2 |
|
||||
477|| Q-TS4 | 代码仓库策略？（Monorepo or Polyrepo？9 个子系统分仓库还是一仓库？CI/CD 工具？） | P2 |
|
||||
478|
|
||||
479|### 7.15 多站点与多市场（4 项）
|
||||
480|
|
||||
481|| # | 问题 | 优先级 |
|
||||
482|| --- | --- | --- |
|
||||
483|| Q-MS1 | 系统需要支持多少个 Amazon 站点？（.com / .co.uk / .de / .fr / .it / .es / .jp / .ca？）不同站点的业务流程是否一致？ | **P0** |
|
||||
484|| Q-MS2 | 多站点下「真实人」归并是否跨站点？（同一个真实人在 .com 和 .co.uk 用不同邮箱/账号——是否归并为同一人？） | P1 |
|
||||
485|| Q-MS3 | 额度规则是否跨站点？（测评 4 次是每个站点独立还是全局？累计 12 个评价呢？） | P1 |
|
||||
486|| Q-MS4 | 未来是否扩展到 Amazon 以外的平台（eBay/Walmart/独立站）？架构上需要预留扩展点吗？ | P2 |
|
||||
487|
|
||||
488|### 7.16 内容与素材管理（3 项）
|
||||
489|
|
||||
490|| # | 问题 | 优先级 |
|
||||
491|| --- | --- | --- |
|
||||
492|| Q-CM1 | EDM 模板、IM 推送话术、APP Push 文案的创建和维护由谁负责？（内容运营？用户运营？）是否需要独立的内容管理子系统？ | P1 |
|
||||
493|| Q-CM2 | 多语言内容策略？（面向美国用户的英文消息、面向德国用户的德语消息——模板由谁翻译和维护？系统是否需要自动翻译？） | P1 |
|
||||
494|| Q-CM3 | 图片/视频素材（产品图片、测评指引图）的存储和管理？是否需要 CDN？ | P2 |
|
||||
495|
|
||||
496|### 7.17 业务量级预估（4 项）
|
||||
497|
|
||||
498|| # | 问题 | 优先级 |
|
||||
499|| --- | --- | --- |
|
||||
500|| Q-BV1 | 系统需要管理的 ASIN 数量级？（几十个？几百个？几千个？） | P1 |
|
||||
501|| Q-BV2 | 日活跃用户数（APP 端）？日触达消息量（IM+EDM+APP Push+TEL）？ | P1 |
|
||||
502|| Q-BV3 | 客服团队规模？（几个组？每组多少人？峰值工单量？） | P1 |
|
||||
503|| Q-BV4 | 峰值场景预估？（Prime Day / Black Friday 期间流量和触达量是平时的几倍？） | P2 |
|
||||
504|
|
||||
505|### 7.18 外部系统对接细节（4 项）
|
||||
506|
|
||||
507|| # | 问题 | 优先级 |
|
||||
508|| --- | --- | --- |
|
||||
509|| Q-EX1 | 各外部系统的 SLA 和可用性？（Amazon SP-API 的 rate limit？JOYHUB 的响应时间？）当外部系统不可用时的降级策略？ | P1 |
|
||||
510|| Q-EX2 | 外部系统的认证方式？（Amazon SP-API 的 OAuth 授权流程？JOYHUB 的 API Key？）谁负责管理这些凭证？ | P1 |
|
||||
511|| Q-EX3 | 数据同步的增量 or 全量策略？（Amazon 订单是增量拉取最近 N 天还是全量同步？JOYHUB 用户数据呢？） | P1 |
|
||||
512|| Q-EX4 | 外部系统数据格式和字段映射是否已有文档？（Amazon 订单字段→系统内部字段的映射关系？） | P2 |
|
||||
513|
|
||||
514|---
|
||||
515|
|
||||
516|## 8. 待确认的内外边界
|
||||
517|
|
||||
518|> 以下边界由于文档信息不足，标记为「待确认」，需要在后续与业务方或技术团队确认。
|
||||
519|
|
||||
520|| # | 边界问题 | 影响范围 | 建议确认方式 |
|
||||
521|| --- | --- | --- | --- |
|
||||
522|| B1 | **内容/素材管理归属**：EDM 模板、IM 推送话术、APP Push 文案由哪个子系统管理？是 outreach 内的内容模块，还是独立的内容管理子系统？ | outreach | 与内容运营角色确认工作流 |
|
||||
523|| B2 | **品牌/内容运营角色**：文档提到品牌运营和内容运营但目前不展开。他们是否需要独立前端？需求何时明确？ | planning / creator | 与业务方确认是否一期纳入 |
|
||||
524|| B3 | **数据仓库/BI 边界**：文档明确「完整 BI/财务/ROI 系统」不在本版主流程，但管理驾驶舱涉及聚合看板。看板数据是子系统直接提供聚合 API 还是走独立数据仓库？ | 全部 | 与数据团队确认数据架构 |
|
||||
525|| B4 | **外部系统降级策略**：Amazon API 不可用时，哪些功能可以降级运行？JOYHUB 不可用时用户身份如何兜底？ | identity / planning / review | 制定 SLA 和降级方案 |
|
||||
526|| B5 | **多语言支持**：系统前端是否只面向菲律宾客服（英文？）还是国内团队也使用（中文？） | 所有前端 | 确认各前端的语言需求 |
|
||||
527|| B6 | **定时任务归属**：自动需求触发、EDM 批处理、超时检测、评价核验等定时任务在各子系统内实现还是有统一调度器？ | 多个子系统 | 确认是否引入统一任务调度 |
|
||||
528|
|
||||
529|---
|
||||
530|
|
||||
531|## 9. 附录：子系统文档索引
|
||||
532|
|
||||
533|| 文档 | 描述 |
|
||||
534|| --- | --- |
|
||||
535|| [01-子系统-用户身份与上下文](01-子系统-用户身份与上下文.md) | 真实人归并、用户上下文卡、设备识别 |
|
||||
536|| [02-子系统-需求与计划管理](02-子系统-需求与计划管理.md) | 需求触发、计划生命周期、审批工作流 |
|
||||
537|| [03-子系统-额度与频控](03-子系统-额度与频控.md) | 额度台账、频控引擎、预占释放 |
|
||||
538|| [04-子系统-多渠道触达引擎](04-子系统-多渠道触达引擎.md) | IM/EDM/APP/TEL 调度与执行 |
|
||||
539|| [05-子系统-客服工单与管理](05-子系统-客服工单与管理.md) | 工单管理、客服管理支撑 |
|
||||
540|| [06-子系统-风险与反欺诈](06-子系统-风险与反欺诈.md) | 风险判断、黑名单、双重退款 |
|
||||
541|| [07-子系统-评价结果追踪](07-子系统-评价结果追踪.md) | 评价提交、展示核验、结果回流 |
|
||||
542|| [08-子系统-KOC-KOL协作](08-子系统-KOC-KOL协作.md) | KOC/KOL 匹配、内容跟踪、JOYCOLLAB 同步 |
|
||||
543|| [09-子系统-审计与通知中心](09-子系统-审计与通知中心.md) | 审计日志、多类型通知告警 |
|
||||
544|
|
||||
199
wishfulfilled-wiki/05_需求文档/01-子系统-用户身份与上下文.md
Normal file
199
wishfulfilled-wiki/05_需求文档/01-子系统-用户身份与上下文.md
Normal file
@@ -0,0 +1,199 @@
|
||||
# 子系统 01 — 用户身份与上下文 (`identity`) v1.0
|
||||
|
||||
## 子系统概述
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| 代号 | `identity` |
|
||||
| 核心职责 | 真实人识别与归并、身份线索关联、用户上下文卡生成 |
|
||||
| 数据所有权 | `person_profiles`, `person_identity_links`, `contact_context_snapshots`, `device_records` |
|
||||
| 启动依赖 | 无硬依赖（需 JOYHUB 数据同步到位） |
|
||||
| 外部系统依赖 | JOYHUB（用户数据）、APP（设备数据） |
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块划分
|
||||
|
||||
### 整体模块图
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ identity 子系统 │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ M1: 身份线索 │ │ M2: 真实人 │ │ M3: 用户上下 │ │
|
||||
│ │ 采集与同步 │→│ 归并引擎 │→│ 文卡服务 │ │
|
||||
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
│ │ │ │ │
|
||||
│ ▼ ▼ ▼ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ M4: 设备变化 │ │ M5: 身份管理 │ │ M6: 对外 API │ │
|
||||
│ │ 识别 │ │ Admin │ │ Gateway │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
### 模块明细
|
||||
|
||||
| # | 模块 | 代号 | 职责 |
|
||||
| --- | --- | --- | --- |
|
||||
| M1 | 身份线索采集与同步 | `identity-ingest` | 从 JOYHUB、APP 等外部系统拉取/接收身份线索（JOYHUB ID、邮箱、电话、设备号、订单关联） |
|
||||
| M2 | 真实人归并引擎 | `person-merge` | 按标准姓名+地址、多线索交叉权重归并，生成/更新真实人 ID |
|
||||
| M3 | 用户上下文卡服务 | `context-card` | 聚合身份+交易+服务+风险+设备+触达全量数据生成上下文快照 |
|
||||
| M4 | 设备变化识别 | `device-tracker` | 识别设备号变化、换机、多设备场景，记录设备变化日志 |
|
||||
| M5 | 身份管理 Admin | `identity-admin` | 人工归并/拆分操作、归并冲突处理、身份数据校正 |
|
||||
| M6 | 对外 API Gateway | `identity-api` | 向其他子系统提供真实人查询、上下文卡查询、归并请求等 API |
|
||||
|
||||
---
|
||||
|
||||
## 2. 各模块内外说明
|
||||
|
||||
### 2.1 M1: 身份线索采集与同步
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 管理外部系统的数据同步任务（定时拉取 JOYHUB 用户数据、设备数据）；解析和标准化各来源的身份线索（邮箱规范化、电话格式化、地址标准化）；写入 `person_identity_links` 表 |
|
||||
| **对外接口** | `POST /internal/identity/ingest — 接收上游推送的身份线索`；同步调度器可配置频率 |
|
||||
| **数据写入** | `person_identity_links`（线索类型 + 线索值 + 来源系统 + 采集时间） |
|
||||
|
||||
### 2.2 M2: 真实人归并引擎
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 执行归并规则：标准姓名+地址一致→同一真实人；多线索交叉（设备+电话+邮箱+收款信息）按权重打分；地址一致姓名不同→标记家庭关联但不合并；生成真实人 ID、归并证据、置信度 |
|
||||
| **对外接口** | `POST /api/identity/merge — 触发归并`；返回归并结果（真实人 ID + 置信度） |
|
||||
| **数据写入** | `person_profiles`（真实人创建/更新）、`person_identity_links`（关联关系更新） |
|
||||
| **关键规则** | 邮箱不同+JOYHUB ID 不同不能单独否定「同一真实人」；订单号命中历史异常需拉出风险记录 |
|
||||
|
||||
### 2.3 M3: 用户上下文卡服务
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 聚合 6 组字段（当前身份、真实人归并、历史交易、历史服务、历史风险、当前设备、触达历史）；生成上下文快照（含快照时间）；首次生成 vs 增量更新 |
|
||||
| **对外接口** | `GET /api/identity/context/{person_id} — 获取用户上下文卡`；返回聚合后的全量上下文 |
|
||||
| **数据写入** | `contact_context_snapshots` |
|
||||
| **依赖其他子系统** | 交易数据来自 planning；服务数据来自 support；风险数据来自 risk；触达数据来自 outreach（通过 API 聚合或事件） |
|
||||
|
||||
### 2.4 M4: 设备变化识别
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 监控同一 JOYHUB ID 下设备号变化；记录换机/多设备事件；关联设备型号、系统版本、APP 版本变化 |
|
||||
| **对外接口** | 内部事件 `device.changed` 供其他模块消费 |
|
||||
| **数据写入** | `device_records`（设备变化时间、变化类型） |
|
||||
| **待确认** | 多久内的设备变化算「近期换机」？多设备同时活跃如何标记？ |
|
||||
|
||||
### 2.5 M5: 身份管理 Admin
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 提供人工归并操作界面（两个真实人合并为一个）；归并拆分（合并错了如何回退）；冲突处理（系统自动归并 vs 人工判定不一致时） |
|
||||
| **对外接口** | 管理 API（不对其他子系统暴露） |
|
||||
| **数据写入** | 所有身份相关表（权限控制） |
|
||||
|
||||
### 2.6 M6: 对外 API Gateway
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 统一对外 API 认证、限流、日志 |
|
||||
| **对外接口** | `GET /api/identity/person?线索类型=&线索值=` — 按线索查真实人；`GET /api/identity/context/{person_id}` — 用户上下文卡；`POST /api/identity/batch-check` — 批量身份查询 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 对外 API 契约（草案）
|
||||
|
||||
| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 按线索查真实人 | `GET /api/identity/person` | `?type=email&value=xxx@yy.com` 或 `?type=joyhub_id&value=123` | `{person_id, confidence, matched_clues[]}` | 所有子系统 |
|
||||
| 获取用户上下文卡 | `GET /api/identity/context/{person_id}` | `person_id` | `{identity, transactions, services, risks, devices, outreach_history}` | support, risk, outreach |
|
||||
| 批量身份查询 | `POST /api/identity/batch-check` | `[{type, value}, ...]` | `[{person_id, confidence}, ...]` | planning, outreach |
|
||||
| 触发归并 | `POST /api/identity/merge` | `{clues: [{type, value}, ...]}` | `{person_id, is_new, confidence}` | outreach（每次互动时调用） |
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据对象（本子系统写入）
|
||||
|
||||
| 对象 | 核心字段 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| `person_profiles` | person_id, status, created_at, updated_at, merge_evidence | 真实人主表 |
|
||||
| `person_identity_links` | person_id, clue_type (JOYHUB_ID/EMAIL/PHONE/DEVICE/ORDER_NAME_ADDRESS), clue_value, source, confidence, linked_at | 身份线索关联表 |
|
||||
| `contact_context_snapshots` | person_id, snapshot_time, identity_snapshot, transaction_snapshot, service_snapshot, risk_snapshot, device_snapshot, outreach_snapshot | 上下文快照 |
|
||||
| `device_records` | person_id, joyhub_id, device_id, device_model, os_version, app_version, change_type (NEW/SWITCH/MULTI), recorded_at | 设备变化记录 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 业务澄清问题清单 — identity
|
||||
|
||||
### 5.1 真实人归并规则（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-01 | 标准姓名+地址的「标准化」规则是什么？（大小写、空格、缩写如 St./Street、middle name 处理？）标准化在哪个模块做？ | **P0** |
|
||||
| I-02 | 归并是多线索交叉权重打分——各维度的权重如何设定？（邮箱=0.3、设备=0.4、电话=0.2、收款=0.5？由谁定义？可否动态调整？） | **P0** |
|
||||
| I-03 | 归并是完全自动执行还是部分需要人工审核？触发人工审核的条件是什么？（置信度 < 多少？涉及风险用户？） | **P0** |
|
||||
| I-04 | 自动归并错误后如何拆分？拆分时如何处理已关联的历史评价和额度数据？（评价归属、额度扣减是否回滚？） | **P0** |
|
||||
|
||||
### 5.2 非 APP 用户处理（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-05 | 非 APP 用户的邮箱从哪里来？（Amazon 订单中的买家邮箱？EDM 列表？客服录入？）邮箱质量/有效性如何保证？ | **P0** |
|
||||
| I-06 | 只有邮箱没有设备号的非 APP 用户，归并置信度是否单独设置较低阈值？这种情况下如何确定是同一真实人？ | P1 |
|
||||
| I-07 | EDM 引导用户注册 APP 后——如何识别「这个新 APP 用户就是之前那个 EDM 邮箱用户」？（注册时要求填同一邮箱？设备号关联？） | P1 |
|
||||
|
||||
### 5.3 设备与多账号（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-08 | 「同设备多账号」的风险判断——同一个设备号关联了多个 JOYHUB ID，哪些情况正常（家庭共用）哪些算风险信号？ | P1 |
|
||||
| I-09 | 设备号变化的识别窗口——同一个 JOYHUB ID 下，设备号变化间隔多久内算「近期换机」？ | P1 |
|
||||
| I-10 | APP 卸载重装导致设备号变化怎么处理？（卸载重装可能生成新设备号） | P2 |
|
||||
|
||||
### 5.4 用户上下文卡（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-11 | 上下文卡的「快照」保留几份？每次互动生成新快照（保留历史）还是覆盖（只保留最新一份）？保留历史的话保留多久？ | P1 |
|
||||
| I-12 | 上下文卡中的历史交易、历史服务等数据是从其他子系统实时拉取还是从本地冗余存储读取？（涉及跨子系统数据一致性） | P1 |
|
||||
| I-13 | 上下文卡是否需要在某个条件触发时预生成（如用户接入前），还是每次实时生成？ | P2 |
|
||||
|
||||
### 5.5 数据同步（2 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-14 | JOYHUB 数据同步频率？（实时/每小时/每天？）同步方式？（API 拉取 / 消息队列 / 数据库直连？） | **P0** |
|
||||
| I-15 | JOYHUB 和 APP 端的数据字段完整清单是否已有？（注册邮箱、设备号、设备型号、APP 版本、系统版本、绑定玩具、活跃行为——文档已列出但需确认是否有遗漏） | **P0** |
|
||||
|
||||
### 5.6 身份数据生命周期（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-16 | 用户数据保留策略——身份线索和历史快照保留多久？（6个月？1年？永久？）超出保留期后是归档还是删除？ | P1 |
|
||||
| I-17 | 用户注销/数据删除请求如何处理？（用户要求删除所有个人数据——如何标记而不是物理删除以保持额度/风险记录的完整性？） | P1 |
|
||||
| I-18 | 「被遗忘权」实操——删除真实人记录后，与之关联的额度、风险、评价如何处理？（匿名化保留？还是级联删除？） | P1 |
|
||||
| I-19 | 用户主动修改关键身份信息（换邮箱、换电话）——系统如何感知和响应？（自动触发重新归并？还是保持原关联？） | P1 |
|
||||
|
||||
### 5.7 多站点与跨平台身份（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-20 | 同一个自然人在 Amazon.com 和 Amazon.co.uk 用不同邮箱和地址——是否跨站点归并为同一个「真实人」？ | P1 |
|
||||
| I-21 | 未来扩展到非 Amazon 平台（eBay/Walmart/独立站）——真实人体系是否需要跨平台？架构预留？ | P2 |
|
||||
| I-22 | 不同国家站点的地址标准化规则不同（US→州/邮编、UK→郡/邮编、DE→邮编/城市）——标准化引擎如何处理？ | P2 |
|
||||
|
||||
### 5.8 归并冲突与人工干预（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-23 | 系统自动归并和人工判定冲突时，以谁为准？（人工优先？系统告警→人工确认？）冲突记录保留多久？ | P1 |
|
||||
| I-24 | 人工拆分归并的操作是否需要审批？（谁来审批？审批流程？）拆分的审计记录保留什么字段？ | P1 |
|
||||
| I-25 | 是否存在「不确定」状态的真实人？（置信度太低无法归并，标记为「待定」——如何流转到人工审核？） | P1 |
|
||||
|
||||
### 5.9 实施层面（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| I-26 | 身份归并是实时还是异步？（用户接入时实时归并→阻塞用户体验 vs 异步归并→可能用旧数据？） | P1 |
|
||||
| I-27 | 上下文卡聚合的性能要求——单次查询需要在多少 ms 内返回？（涉及跨子系统调用时的超时和降级） | P2 |
|
||||
| I-28 | 如果 JOYHUB 数据同步中断，identity 子系统如何降级？（用缓存数据？标记为「数据可能过期」？） | P1 |
|
||||
214
wishfulfilled-wiki/05_需求文档/02-子系统-需求与计划管理.md
Normal file
214
wishfulfilled-wiki/05_需求文档/02-子系统-需求与计划管理.md
Normal file
@@ -0,0 +1,214 @@
|
||||
# 子系统 02 — 需求与计划管理 (`planning`) v1.0
|
||||
|
||||
## 子系统概述
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| 代号 | `planning` |
|
||||
| 核心职责 | 需求触发（人工/自动）、需求评估、计划生成（推新/回评/免评）、审批工作流、ASIN 基础信息管理 |
|
||||
| 数据所有权 | `demands`, `plans`, `plan_items`, `approval_records`, `asin_catalog` |
|
||||
| 启动依赖 | identity（软依赖，无 identity 可操作但无法做人群匹配） |
|
||||
| 外部系统依赖 | Amazon（ASIN 数据、销售数据、评价缺口） |
|
||||
|
||||
---
|
||||
|
||||
## 1. 模块划分
|
||||
|
||||
```
|
||||
┌─────────────────────────────────────────────────────────────┐
|
||||
│ planning 子系统 │
|
||||
│ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ M1: 需求管理 │ │ M2: 计划引擎 │ │ M3: 审批工作 │ │
|
||||
│ │ (Demand) │→│ (Plan) │→│ 流 │ │
|
||||
│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
│ │ │ │ │
|
||||
│ ▼ ▼ ▼ │
|
||||
│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
│ │ M4: 自动触发 │ │ M5: ASIN管理 │ │ M6: 对外 API │ │
|
||||
│ │ 规则引擎 │ │ │ │ Gateway │ │
|
||||
│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
│ │
|
||||
└─────────────────────────────────────────────────────────────┘
|
||||
```
|
||||
|
||||
| # | 模块 | 代号 | 职责 |
|
||||
| --- | --- | --- | --- |
|
||||
| M1 | 需求管理 | `demand-mgr` | 需求创建、评估（成立/待补充/驳回）、优先级管理、需求与 ASIN 关联 |
|
||||
| M2 | 计划引擎 | `plan-engine` | 从已确认需求生成计划（推新/回评/免评）、计划生命周期管理、计划项拆解 |
|
||||
| M3 | 审批工作流 | `approval-workflow` | 计划审批链（Amazon 运营总监→用户负责人→渠道负责人）、审批记录 |
|
||||
| M4 | 自动触发规则引擎 | `auto-trigger` | 按 ASIN 健康度、评价缺口自动触发需求；定时评估触发条件 |
|
||||
| M5 | ASIN 管理 | `asin-catalog` | ASIN 基础信息、评分、评价数、Listing 健康状态维护 |
|
||||
| M6 | 对外 API Gateway | `planning-api` | 向其他子系统提供计划查询、ASIN 查询、审批状态查询 API |
|
||||
|
||||
---
|
||||
|
||||
## 2. 各模块内外说明
|
||||
|
||||
### 2.1 M1: 需求管理
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | Amazon 运营人工提需求（选择 ASIN、指定类型：推新/回评/免评、目标数量、周期）；用户运营评估需求（查 ASIN 健康、目标数量、历史完成、当前资源）；评估结果：已确认/待补充/驳回 |
|
||||
| **对外接口** | `POST /api/demands` — 创建需求；`PUT /api/demands/{id}/evaluate` — 评估需求 |
|
||||
| **数据写入** | `demands` |
|
||||
| **依赖** | `GET /api/identity/person` — 评估时可能需要运营人员身份 |
|
||||
| **待确认** | 需求是否有优先级字段（P0/P1/P2）？驳回后是否允许重新提交？ |
|
||||
|
||||
### 2.2 M2: 计划引擎
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 从已确认需求生成计划草案（类型：推新/回评/免评）；计划参数（目标 ASIN、目标数量、周期、预算、备注）；计划状态流转；计划项拆解（将计划拆成可分配给渠道的执行单元） |
|
||||
| **对外接口** | `POST /api/plans` — 创建计划；`PUT /api/plans/{id}/status` — 更新状态；`GET /api/plans/{id}/items` — 获取计划项 |
|
||||
| **数据写入** | `plans`, `plan_items` |
|
||||
| **依赖** | `GET /api/quota/check` — 生成人群前查询额度；`GET /api/risk/check` — 计划复核时查询风险 |
|
||||
| **待确认** | 计划是否可以包含多个 ASIN？推新和回评是否可以合并为一个计划？ |
|
||||
|
||||
### 2.3 M3: 审批工作流
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 按计划类型路由不同审批链：（测评→Amazon运营总监 / 回评→总监或指定负责人 / 免评→总监+用户负责人 / 紧急→运营负责人+用户负责人+主管）；周/月推送计划审批（用户负责人→渠道负责人）；审批节点（通过/驳回/待补充） |
|
||||
| **对外接口** | `POST /api/approvals/{plan_id}/submit` — 提交审批；`PUT /api/approvals/{plan_id}/review` — 审批决策 |
|
||||
| **数据写入** | `approval_records` |
|
||||
| **依赖** | `GET /api/identity/person` — 获取审批人身份 |
|
||||
| **待确认** | 审批链是否可以动态配置（不同站点/国家不同审批人）？驳回后修改再提交是否需要重新走完整审批链？ |
|
||||
|
||||
### 2.4 M4: 自动触发规则引擎
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 定时扫描 ASIN 健康状态（评分、评价数、差评比例）；当满足触发条件时自动创建需求（无需人工干预）；触发规则可配置 |
|
||||
| **对外接口** | 内部定时任务，不对外暴露 |
|
||||
| **数据写入** | `demands`（自动生成的需求） |
|
||||
| **依赖** | `GET /api/reviews/asin-health` 或本地 ASIN 数据 |
|
||||
| **待确认** | 自动触发后是否需要人工确认还是直接进入评估？自动触发的优先级如何设定？ |
|
||||
|
||||
### 2.5 M5: ASIN 管理
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | ASIN 基础信息（ASIN 码、标题、品类、站点）；评分、评价总数、差评数；Listing 健康状态（活跃/风险/下架）；与计划的关联关系 |
|
||||
| **对外接口** | `GET /api/asins/{asin}` — ASIN 详情；`GET /api/asins?status=at_risk` — 需关注的 ASIN 列表 |
|
||||
| **数据写入** | `asin_catalog` |
|
||||
| **依赖** | Amazon 数据同步（外部系统） |
|
||||
| **待确认** | ASIN 数据是否已在 JOYHUB 或其他系统中维护？是否需要新建还是复用？ |
|
||||
|
||||
### 2.6 M6: 对外 API Gateway
|
||||
|
||||
| 维度 | 说明 |
|
||||
| --- | --- |
|
||||
| **对内** | 统一对外 API 认证、限流、日志 |
|
||||
| **对外接口** | `GET /api/plans?status=approved` — 待执行计划（outreach 消费）；`GET /api/plans/{id}` — 计划详情（review 消费）；`GET /api/asins/{asin}` — ASIN 查询 |
|
||||
|
||||
---
|
||||
|
||||
## 3. 对外 API 契约（草案）
|
||||
|
||||
| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
| --- | --- | --- | --- | --- |
|
||||
| 创建需求 | `POST /api/demands` | `{asin, type, target_count, period, priority}` | `{demand_id, status}` | 运营前端 |
|
||||
| 评估需求 | `PUT /api/demands/{id}/evaluate` | `{decision, reason}` | `{status}` | 用户运营前端 |
|
||||
| 创建计划 | `POST /api/plans` | `{demand_id, type, params}` | `{plan_id}` | 用户运营前端 |
|
||||
| 待执行计划列表 | `GET /api/plans?status=approved` | 无 | `[{plan_id, type, items}]` | outreach |
|
||||
| 计划详情 | `GET /api/plans/{id}` | `plan_id` | 完整计划含审批记录 | review / outreach |
|
||||
| ASIN 查询 | `GET /api/asins/{asin}` | `asin` | ASIN 详情+健康状态 | 所有子系统 |
|
||||
|
||||
---
|
||||
|
||||
## 4. 数据对象
|
||||
|
||||
| 对象 | 核心字段 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| `demands` | demand_id, asin, type (NEW/REVIEW/EXEMPTION), target_count, period, status (PENDING/EVALUATING/CONFIRMED/REJECTED/WAITING), priority, created_by, evaluated_by, created_at | 需求主表 |
|
||||
| `plans` | plan_id, demand_id, type, status (DRAFT/REVIEW/APPROVED/EXECUTING/COMPLETED/CANCELLED), target_count, period, created_at | 计划主表 |
|
||||
| `plan_items` | item_id, plan_id, asin, item_type, target_count, assigned_channel, status | 计划执行项 |
|
||||
| `approval_records` | approval_id, plan_id, approver, decision, comment, decided_at, step_order | 审批记录 |
|
||||
| `asin_catalog` | asin, title, category, marketplace, rating, review_count, negative_count, health_status, last_synced_at | ASIN 信息 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 业务澄清问题清单 — planning
|
||||
|
||||
### 5.1 需求与计划模型（5 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-01 | 一个需求是否可以生成多个计划？（例如一个回评需求拆分到 IM 计划和 EDM 计划）还是一对一？ | **P0** |
|
||||
| P-02 | 计划是否可以跨 ASIN？（一个推新计划覆盖 3 个新 ASIN）还是每个计划只针对一个 ASIN？ | **P0** |
|
||||
| P-03 | 计划中的「目标数量」是指目标评价数还是目标触达用户数？（如果转化率 2%，要得到 10 个评价需触达 500 人） | **P0** |
|
||||
| P-04 | 计划的「周期」是什么粒度？（周/月/自定义日期范围？）周期结束后未完成的计划如何处理？ | P1 |
|
||||
| P-05 | 需求是否有优先级？（P0/P1/P2 或高/中/低？）优先级影响什么？（审批速度？资源分配？） | P1 |
|
||||
|
||||
### 5.2 审批流程（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-06 | 文档提到「免评计划 → Amazon 运营总监 + 用户负责人」审批——是两者都必须通过（会签）还是任一通过即可（或签）？ | **P0** |
|
||||
| P-07 | 「指定负责人」的指定规则是什么？（按 ASIN 品类？按站点？按当前负载？人工指定？） | P1 |
|
||||
| P-08 | 审批超时如何处理？（审批人 N 天未处理，自动通过？自动驳回？升级到上级？） | P1 |
|
||||
| P-09 | 审批驳回后修改再提交，审批链是否重置还是从当前节点继续？ | P1 |
|
||||
|
||||
### 5.3 自动触发（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-10 | 自动触发的具体阈值是什么？（① ASIN 评分低于多少？② 差评在最近 N 天新增多少？③ 评价总数 < 目标值？） | **P0** |
|
||||
| P-11 | 自动触发是每天跑一次还是实时监控？（如果是实时，高频变化的 ASIN 会不会重复触发？） | P1 |
|
||||
| P-12 | 自动触发生成的需求是否自动进入评估环节还是需要人工确认后才进入？ | P2 |
|
||||
|
||||
### 5.4 ASIN 管理（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-13 | ASIN 数据来源和更新频率？（从 Amazon API 拉取？T+1？实时？手动导入？） | **P0** |
|
||||
| P-14 | ASIN 的「Listing 健康状态」如何定义？（评分 ≥ 4.2 = 健康？差评率 < X%？）健康度是否有多个等级？ | P1 |
|
||||
| P-15 | ASIN 是否有关联关系？（变体 ASIN、父 ASIN-子 ASIN）关联合并还是独立管理？ | P2 |
|
||||
|
||||
### 5.5 计划执行衔接（2 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-16 | 计划审批通过后如何流转到 outreach 子系统？（planning 主动推送？outreach 定时拉取？事件通知？） | P1 |
|
||||
| P-17 | 计划执行过程中是否可以调整目标数量或周期？调整是否需要重新审批？ | P2 |
|
||||
|
||||
### 5.6 计划模板与复用（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-18 | 是否需要计划模板功能？（对常推的 ASIN 创建可复用的计划模板——模板包含预设的渠道/目标数/周期？） | P1 |
|
||||
| P-19 | 周期性计划（如「每月 1 号自动对 ASIN X 发起回评计划」）是否支持？谁有权限创建？ | P2 |
|
||||
| P-20 | 计划是否可以暂停/恢复？（执行中因库存或供应链原因需暂停——暂停期间已触达的用户如何处理？） | P1 |
|
||||
|
||||
### 5.7 预算与资源管理（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-21 | 计划是否有预算字段？（返款金额、Code 成本、KOC 费用——是否需要预算审批？超出预算如何处理？） | P1 |
|
||||
| P-22 | 资源容量规划——同时可执行的计划数是否有上限？（受限于客服人力/EDM发送额度/IM频控？） | P1 |
|
||||
| P-23 | 是否需要计划执行成本的 ROI 计算？（返款总额 / 获得的评价数 = 单评价成本——系统自动计算还是手动录入？） | P2 |
|
||||
|
||||
### 5.8 季节性/大促处理（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-24 | Prime Day / Black Friday 等大促期间的计划是否有特殊处理？（提前锁定额度、加大推送量、豁免某些频控规则？） | P1 |
|
||||
| P-25 | 大促前的「预热计划」和大促后的「回评计划」是否需要在系统中作为计划间的依赖关系来管理？ | P2 |
|
||||
| P-26 | 季节性产品（圣诞装饰、夏季用品）的计划是否有时间敏感度标记？（错过季节窗口的计划自动降级？） | P2 |
|
||||
|
||||
### 5.9 多站点/多市场（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-27 | 不同 Amazon 站点的计划是否可以统一管理？（同一个 ASIN 在不同站点是独立计划还是关联计划？） | P1 |
|
||||
| P-28 | 多站点的审批人是否不同？（.com 的运营总监和 .co.uk 的运营总监可能是不同人） | P1 |
|
||||
| P-29 | 跨站点需求的冲突检测？（.com 和 .de 同时对同一真实的同一用户做了不同计划——算不算冲突？） | P2 |
|
||||
|
||||
### 5.10 实施层面（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| P-30 | 自动触发生成的需求如果无人处理（评估超时），是否自动驳回还是升级通知？ | P1 |
|
||||
| P-31 | 审批工作流引擎——是否有现成的审批引擎可复用？（还是需要从零开发状态机？） | P2 |
|
||||
| P-32 | 计划执行过程中用户反馈「不想再收到」——是标记为退订（outreach 处理）还是需要回写到 planning 的计划状态中？ | P1 |
|
||||
198
wishfulfilled-wiki/05_需求文档/03-子系统-额度与频控.md
Normal file
198
wishfulfilled-wiki/05_需求文档/03-子系统-额度与频控.md
Normal file
@@ -0,0 +1,198 @@
|
||||
1|# 子系统 03 — 额度与频控 (`quota`) v1.0
|
||||
2|
|
||||
3|## 子系统概述
|
||||
4|
|
||||
5|| 维度 | 说明 |
|
||||
6|| --- | --- |
|
||||
7|| 代号 | `quota` |
|
||||
8|| 核心职责 | 额度台账（测评4/免评4/累计12）、额度预占与释放、频控规则引擎、发送前终校 |
|
||||
9|| 数据所有权 | `person_quota_ledgers`, `quota_reservations`, `frequency_control_records` |
|
||||
10|| 启动依赖 | identity（软依赖，额度按真实人计算，未归并时按单一账号） |
|
||||
11|| 外部系统依赖 | 无直接外部依赖 |
|
||||
12|
|
||||
13|---
|
||||
14|
|
||||
15|## 1. 模块划分
|
||||
16|
|
||||
17|```
|
||||
18|┌─────────────────────────────────────────────────────────────┐
|
||||
19|│ quota 子系统 │
|
||||
20|│ │
|
||||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
22|│ │ M1: 额度台账 │ │ M2: 预占管理 │ │ M3: 频控引擎 │ │
|
||||
23|│ │ (Ledger) │→│ (Reservation)│ │ (FreqCtrl) │ │
|
||||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
25|│ │ │ │ │
|
||||
26|│ ▼ ▼ ▼ │
|
||||
27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
28|│ │ M4: 终校服务 │ │ M5: 额度管理 │ │ M6: 对外 API │ │
|
||||
29|│ │ (FinalCheck)│ │ Admin │ │ Gateway │ │
|
||||
30|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
31|│ │
|
||||
32|└─────────────────────────────────────────────────────────────┘
|
||||
33|```
|
||||
34|
|
||||
35|| # | 模块 | 代号 | 职责 |
|
||||
36|| --- | --- | --- | --- |
|
||||
37|| M1 | 额度台账 | `quota-ledger` | 维护真实人三层额度（测评4/免评4/累计12）、已用/进行中/已预占计数 |
|
||||
38|| M2 | 预占管理 | `reservation-mgr` | 额度预占创建、确认占用、超时释放；跨计划重复入选检测 |
|
||||
39|| M3 | 频控引擎 | `freq-control` | 渠道频控（IM/EDM/APP/TEL 最近触达间隔）、单 ASIN 短期触达次数、退订/投诉屏蔽 |
|
||||
40|| M4 | 终校服务 | `final-check` | 发送前合并校验（最新额度 + 最新风险 + 最新未关闭工单），准入/撤出决策 |
|
||||
41|| M5 | 额度管理 Admin | `quota-admin` | 额度手动调整、额度重置、额度审计 |
|
||||
42|| M6 | 对外 API Gateway | `quota-api` | 供 planning（人群生成）、outreach（发送前校验）、review（提交后确认）调用 |
|
||||
43|
|
||||
44|---
|
||||
45|
|
||||
46|## 2. 各模块内外说明
|
||||
47|
|
||||
48|### 2.1 M1: 额度台账
|
||||
49|
|
||||
50|| 维度 | 说明 |
|
||||
51|| --- | --- |
|
||||
52|| **对内** | 按真实人维护三种额度：月度测评（已完成+进行中+已预占）、月度免评（同上）、累计真实提交评价（永久累计）；额度计数时点明确（提交评价立即计数12、不会因 Amazon 未展示回退）；接近上限时预警 |
|
||||
53|| **对外接口** | `GET /api/quota/ledger/{person_id}` — 读取当前台账 |
|
||||
54|| **数据写入** | `person_quota_ledgers` |
|
||||
55|| **依赖** | `GET /api/identity/person` — 获取真实人 ID |
|
||||
56|
|
||||
57|### 2.2 M2: 预占管理
|
||||
58|
|
||||
59|| 维度 | 说明 |
|
||||
60|| --- | --- |
|
||||
61|| **对内** | 人群生成时预占额度（测评/免评）；计算：已用+进行中+已预占+本次拟发送 > 上限 → 拦截；剩余不足但>0 → 预警池 → 发送前人工复核；预占有效期管理，超时自动释放；并发占用控制（同一真实人跨计划重复入选检测） |
|
||||
62|| **对外接口** | `POST /api/quota/reserve` — 创建预占；`POST /api/quota/commit` — 确认占用；`POST /api/quota/release` — 释放预占 |
|
||||
63|| **数据写入** | `quota_reservations` |
|
||||
64|
|
||||
65|### 2.3 M3: 频控引擎
|
||||
66|
|
||||
67|| 维度 | 说明 |
|
||||
68|| --- | --- |
|
||||
69|| **对内** | 四种频控维度：①渠道频控（IM/EDM/APP/TEL 最近触达间隔）②单 ASIN 短期内触达同一用户次数 ③用户反感度（投诉/退订状态）④用户在客服工单中暂不触达；频控规则可配置 |
|
||||
70|| **对外接口** | `GET /api/quota/freq-check/{person_id}?channel=IM&asin=xxx` — 频控检查 |
|
||||
71|| **数据写入** | `frequency_control_records` |
|
||||
72|| **依赖** | 触达历史来自 outreach（`GET /api/outreach/history/{person_id}`） |
|
||||
73|
|
||||
74|### 2.4 M4: 终校服务
|
||||
75|
|
||||
76|| 维度 | 说明 |
|
||||
77|| --- | --- |
|
||||
78|| **对内** | 发送前做最终校验：①重新读取最新额度（防止发送和预占之间额度变化）②重新读取最新风险状态 ③重新读取最新未关闭工单；三者全部通过→准入发送；任一新增超限/风险/工单→撤出本批次 |
|
||||
79|| **对外接口** | `POST /api/quota/final-check` — 批量终校（输入 person_ids + plan_id，返回每个的准入/撤出决策） |
|
||||
80|| **数据写入** | 终校结果写入审计日志 |
|
||||
81|| **依赖** | `GET /api/risk/check/{person_id}`；`GET /api/tickets?person_id=&status=open` |
|
||||
82|
|
||||
83|### 2.5 M5: 额度管理 Admin
|
||||
84|
|
||||
85|| 维度 | 说明 |
|
||||
86|| --- | --- |
|
||||
87|| **对内** | 额度手动调整（运营确认某次测评不计入额度等）；额度重置（新月份额度初始化）；额度审计（谁改了什么额度） |
|
||||
88|| **对外接口** | 管理 API |
|
||||
89|
|
||||
90|### 2.6 M6: 对外 API Gateway
|
||||
91|
|
||||
92|| 维度 | 说明 |
|
||||
93|| --- | --- |
|
||||
94|| **对外接口** | `GET /api/quota/check/{person_id}?type=测评` — 额度查询+可用判断；`POST /api/quota/reserve` — 预占；`POST /api/quota/commit` — 确认；`POST /api/quota/release` — 释放；`POST /api/quota/final-check` — 终校 |
|
||||
95|
|
||||
96|---
|
||||
97|
|
||||
98|## 3. 对外 API 契约（草案）
|
||||
99|
|
||||
100|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
101|| --- | --- | --- | --- | --- |
|
||||
102|| 额度查询 | `GET /api/quota/check/{person_id}?type=REVIEW` | person_id + 额度类型 | `{used, in_progress, reserved, remaining, status(sufficient/warning/exceeded)}` | planning, outreach |
|
||||
103|| 批量预占 | `POST /api/quota/reserve` | `[{person_id, type, plan_id, count}]` | `[{person_id, success, reservation_id}]` | planning（人群生成时） |
|
||||
104|| 确认占用 | `POST /api/quota/commit` | `[{reservation_id}]` | `[{reservation_id, committed}]` | review（用户提交评价后） |
|
||||
105|| 释放预占 | `POST /api/quota/release` | `[{reservation_id}]` | `[{success}]` | planning（计划取消时） |
|
||||
106|| 频控检查 | `GET /api/quota/freq-check/{person_id}?channel=&asin=` | person_id + 渠道 + ASIN | `{allowed, reason, cooldown_until}` | outreach（发送前） |
|
||||
107|| 发送前终校 | `POST /api/quota/final-check` | `[{person_id, plan_id}]` | `[{person_id, decision: APPROVED/WITHDRAWN, reasons}]` | outreach（发送前最后一步） |
|
||||
108|
|
||||
109|---
|
||||
110|
|
||||
111|## 4. 数据对象
|
||||
112|
|
||||
113|| 对象 | 核心字段 | 说明 |
|
||||
114|| --- | --- | --- |
|
||||
115|| `person_quota_ledgers` | ledger_id, person_id, quota_type (MONTHLY_REVIEW/MONTHLY_EXEMPTION/LIFETIME_SUBMISSION), period, used, in_progress, reserved, limit_value, status | 三层额度台账 |
|
||||
116|| `quota_reservations` | reservation_id, person_id, ledger_id, plan_id, count, status (RESERVED/COMMITTED/RELEASED/EXPIRED), reserved_at, expires_at | 额度预占记录 |
|
||||
117|| `frequency_control_records` | freq_id, person_id, channel, asin, last_contact_at, contact_count_period, status | 频控记录 |
|
||||
118|
|
||||
119|---
|
||||
120|
|
||||
121|## 5. 业务澄清问题清单 — quota
|
||||
122|
|
||||
123|### 5.1 额度规则细化（5 项）
|
||||
124|
|
||||
125|| # | 问题 | 优先级 |
|
||||
126|| --- | --- | --- |
|
||||
127|| Q-01 | 月度额度按自然月还是 30 天滚动？如果是自然月：①预占在 1 月 31 日，2 月 1 日释放还是保留？②1 月 31 日晚 23:59 的预占跨月怎么处理？ | **P0** |
|
||||
128|| Q-02 | 「测评 4 次」中的「次」定义：是指参与 4 个不同的测评计划，还是提交 4 条评价？（如果 1 个计划要求用户提交 3 条评价，占 3 次还是 1 次？） | **P0** |
|
||||
129|| Q-03 | 「累计 12 个真实提交评价」是永久上限还是可以动态调整？（例如用户长期优质且评价质量高，是否可以人工放宽？放宽流程？） | P1 |
|
||||
130|| Q-04 | 测评和免评额度是否独立？（测评 4 次 + 免评 4 次 = 同一真实人一月最多参与 8 个计划？）还是测评和免评共享总额度？ | P1 |
|
||||
131|| Q-05 | 额度计算中「进行中」的定义——什么状态才算进行中？（已生成人群？已发送触达？用户已回应？已提交评价待核验？） | P1 |
|
||||
132|
|
||||
133|### 5.2 预占机制（4 项）
|
||||
134|
|
||||
135|| # | 问题 | 优先级 |
|
||||
136|| --- | --- | --- |
|
||||
137|| Q-06 | 预占有效期多长？（预占后用户始终未响应，多久释放？1 天？7 天？计划周期结束？） | **P0** |
|
||||
138|| Q-07 | 预占释放后是否可以自动重新分配给同一计划的其他用户？是否触发重新生成人群？ | P1 |
|
||||
139|| Q-08 | 跨计划并发占用检测——同一真实人在计划 A 和计划 B 同时被入选，谁先预占谁得？还是按计划优先级？ | P1 |
|
||||
140|| Q-09 | 预占是否可手动取消/释放？（运营发现某用户不应计入某计划时） | P2 |
|
||||
141|
|
||||
142|### 5.3 频控规则（4 项）
|
||||
143|
|
||||
144|| # | 问题 | 优先级 |
|
||||
145|| --- | --- | --- |
|
||||
146|| Q-10 | 各渠道频控的具体阈值是什么？（IM 每日最多 X 次？EDM 每周最多 Y 封？APP Push 每日最多 Z 条？TEL 每日最多 N 通？） | **P0** |
|
||||
147|| Q-11 | 频控规则是否区分计划类型？（紧急催评是否可以突破频控？） | P1 |
|
||||
148|| Q-12 | 频控是全局统一配置还是按用户层级可调整？（A 类和 C 类用户频控规则是否不同？） | P1 |
|
||||
149|| Q-13 | 「单 ASIN 短期触达次数」——多少天内触达多少次算超标？ | P2 |
|
||||
150|
|
||||
151|### 5.4 预警与异常（3 项）
|
||||
152|
|
||||
153|| # | 问题 | 优先级 |
|
||||
154|| --- | --- | --- |
|
||||
155|| Q-14 | 预警阈值如何设定？（剩余 1 次时预警？剩余 N% 时预警？不同类型额度预警阈值是否不同？） | P1 |
|
||||
156|| Q-15 | 终校中「新增风险」的判断——距离上次风险检查超过多少时间需重查？还是每次终校都实时查 risk？ | P1 |
|
||||
157|| Q-16 | 额度数据异常时的处理策略？（台账数据与预占记录不一致、预占未释放导致额度泄漏——系统如何自动发现和修复？） | P2 |
|
||||
158|
|
||||
### 5.5 额度异常与纠错（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| Q-17 | 用户反馈「我明明只参与了 3 次测评，系统说我已用 4 次」——申诉流程？谁有权限查台账和修正？ | P1 |
|
||||
| Q-18 | 额度台账的审计追踪——每次额度变更（预占/确认/释放/手动调整）是否记录完整操作人和原因？保留多久？ | P1 |
|
||||
| Q-19 | 数据异常自动检测——台账数据与预占记录之和是否需要对账？系统是否定期自动化对账并报告差异？ | P1 |
|
||||
| Q-20 | 如果发现「额度泄漏」（预占未释放导致额度永久被占），系统如何自动发现和修复？（定时扫描过期预占？手动触发对账？） | P2 |
|
||||
|
||||
### 5.6 紧急/例外处理（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| Q-21 | 大促期间（Prime Day/Black Friday）是否需要临时额度提升？（测评 4→8？）由谁审批？临时额度有效期？ | P1 |
|
||||
| Q-22 | 高价值用户是否可以突破额度限制？（例如 KOC 级别的用户需要超额参与——人工审批流程？） | P1 |
|
||||
| Q-23 | 「紧急计划」是否可以跳过频控？（例如 Listing 评分暴跌至 3.8 需要紧急大量催评——是否豁免部分频控规则？） | P1 |
|
||||
| Q-24 | 额度手动调整是否需要审批？审批权限？（谁可以手动给某人加/减可用额度？） | P2 |
|
||||
|
||||
### 5.7 跨站点/跨平台额度（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| Q-25 | 额度是否跨 Amazon 站点？（.com 参与了 2 次测评 + .co.uk 参与了 3 次 → 全局算 5 次还是各自独立？） | P1 |
|
||||
| Q-26 | 累计 12 个评价是否跨站点统计？（在 .com 提交了 8 个 + .co.uk 提交了 5 个 → 是否算 13 个超限？） | P1 |
|
||||
| Q-27 | 未来扩展到非 Amazon 平台，额度体系是否独立？（eBay 的测评额度与 Amazon 的额度是否共享？） | P2 |
|
||||
|
||||
### 5.8 额度可见性（2 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| Q-28 | 用户是否能看到自己的额度状态？（APP 端显示「本月还可参与 2 次测评」——是否对用户可见？） | P2 |
|
||||
| Q-29 | 运营视角的额度看板——能否看到「全局额度使用率」「各真实人的额度分布」「额度预警用户列表」？ | P1 |
|
||||
|
||||
### 5.9 实施层面（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| Q-30 | 终校服务的性能要求——批量终校（一次可能几百人）需要在多少 ms 内完成？（涉及跨子系统调用 risk + support） | P2 |
|
||||
| Q-31 | 频控规则是否需要热更新（不重启服务即可调整阈值）？配置管理方案？ | P1 |
|
||||
| Q-32 | 额度台账历史数据的初始化——旧系统的数据如何映射到三层额度模型？（无「真实人」概念的老数据如何归入？） | P1 |
|
||||
240
wishfulfilled-wiki/05_需求文档/04-子系统-多渠道触达引擎.md
Normal file
240
wishfulfilled-wiki/05_需求文档/04-子系统-多渠道触达引擎.md
Normal file
@@ -0,0 +1,240 @@
|
||||
1|# 子系统 04 — 多渠道触达引擎 (`outreach`) v1.0
|
||||
2|
|
||||
3|## 子系统概述
|
||||
4|
|
||||
5|| 维度 | 说明 |
|
||||
6|| --- | --- |
|
||||
7|| 代号 | `outreach` |
|
||||
8|| 核心职责 | 渠道路由决策、渠道去重、IM/EDM/APP Push/TEL 渠道调度执行、触达历史管理 |
|
||||
9|| 数据所有权 | `channel_route_decisions`, `channel_dedup_records`, `im_interaction_records`, `im_flow_tags`, `edm_message_events`, `edm_user_behavior_profiles`, `app_touch_events`, `tel_call_records` |
|
||||
10|| 启动依赖 | identity / planning / quota（均为软依赖） |
|
||||
11|| 外部系统依赖 | JOYHUB（IM 通道）、ESP（EDM）、FCM/APNs（APP Push）、电话系统（TEL） |
|
||||
12|
|
||||
13|---
|
||||
14|
|
||||
15|## 1. 模块划分
|
||||
16|
|
||||
17|```
|
||||
18|┌─────────────────────────────────────────────────────────────┐
|
||||
19|│ outreach 子系统 │
|
||||
20|│ │
|
||||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
22|│ │ M1: 渠道路由 │ │ M2: 渠道去重 │ │ M3: IM 执行 │ │
|
||||
23|│ │ + 优先级 │→│ │→│ 引擎 │ │
|
||||
24|│ └──────────────┘ └──────────────┘ └──────┬───────┘ │
|
||||
25|│ │ │
|
||||
26|│ ┌──────────────┐ ┌──────────────┐ ┌──────┴───────┐ │
|
||||
27|│ │ M4: EDM 执行 │ │ M5: APP Push │ │ M6: TEL 执行 │ │
|
||||
28|│ │ 引擎 │ │ 引擎 │ │ 引擎 │ │
|
||||
29|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
30|│ │
|
||||
31|│ ┌──────────────┐ ┌──────────────┐ │
|
||||
32|│ │ M7: 触达历史 │ │ M8: 对外 API │ │
|
||||
33|│ │ 服务 │ │ Gateway │ │
|
||||
34|│ └──────────────┘ └──────────────┘ │
|
||||
35|│ │
|
||||
36|└─────────────────────────────────────────────────────────────┘
|
||||
37|```
|
||||
38|
|
||||
39|| # | 模块 | 职责 |
|
||||
40|| --- | --- | --- |
|
||||
41|| M1 | 渠道路由+优先级 | 按用户状态路由到最优渠道（APP活跃→IM优先 / 未注册→EDM优先 / 高价值无响应→TEL / C类→IM免评卡片） |
|
||||
42|| M2 | 渠道去重 | 同一计划同一用户不重复走多渠道路由；工单中暂停自动触达；已提交待核验暂停催评 |
|
||||
43|| M3 | IM 执行引擎 | IM 推送、用户分层（A未参与/B参与过/C长期测评人）、回评/测评/免评卡片推送、催评、提交核验、返款通知 |
|
||||
44|| M4 | EDM 执行引擎 | EDM 发送、送达/打开/点击追踪、行为画像、节奏控制、退订/硬退信处理 |
|
||||
45|| M5 | APP Push 引擎 | APP 推送、触发源管理（绑定玩具/不活跃/计划到期/Listing紧急/活动）、响应追踪 |
|
||||
46|| M6 | TEL 执行引擎 | 电话任务生成、拨打前准备（用户画像+风险检查+历史沟通）、通话记录、重试策略 |
|
||||
47|| M7 | 触达历史服务 | 统一触达历史查询（跨渠道聚合）、供 quota（频控）、identity（上下文卡）调用 |
|
||||
48|| M8 | 对外 API Gateway | 统一对外 API |
|
||||
49|
|
||||
50|---
|
||||
51|
|
||||
52|## 2. 各模块内外说明
|
||||
53|
|
||||
54|### 2.1 M1: 渠道路由+优先级
|
||||
55|
|
||||
56|| 维度 | 说明 |
|
||||
57|| --- | --- |
|
||||
58|| **对内** | 接收 planning 的已批准计划，按用户状态矩阵决定渠道：APP活跃+已绑定→IM首选；APP低活跃→EDM补充+APP Push召回；未注册→EDM首选→引导注册后转IM；高价值+多次无响应→TEL；C类（累计≥12）→IM免评卡片+KOC/KOL协同 |
|
||||
59|| **对外接口** | `POST /api/outreach/route` — 输入计划+用户，返回路由决策 |
|
||||
60|| **数据写入** | `channel_route_decisions` |
|
||||
61|| **依赖** | `GET /api/identity/context/{person_id}` — 用户状态 |
|
||||
62|
|
||||
63|### 2.2 M2: 渠道去重
|
||||
64|
|
||||
65|| 维度 | 说明 |
|
||||
66|| --- | --- |
|
||||
67|| **对内** | 执行去重规则（同一计划同一用户首选渠道、工单中暂停、已提交评价暂停、退订某渠道永久排除、强关联风险全暂停、弱关联降频+提示） |
|
||||
68|| **对外接口** | `GET /api/outreach/dedup-check?person_id=&plan_id=` |
|
||||
69|| **数据写入** | `channel_dedup_records` |
|
||||
70|| **依赖** | `GET /api/tickets?person_id=&status=open`（support）；`GET /api/risk/check/{person_id}`（risk） |
|
||||
71|
|
||||
72|### 2.3 M3: IM 执行引擎
|
||||
73|
|
||||
74|| 维度 | 说明 |
|
||||
75|| --- | --- |
|
||||
76|| **对内** | 用户分层逻辑（A未参与/B参与过但<12/C≥12长期测评人）；分层推送策略（A推回评卡片/B先催评再二次转化/C仅免评）；提交后的核验与流转（订单号核实→登记→补全信息→返款→二次转化）；标签管理（9 种核心标签如「xx产品已回评用户」「xx产品测评待返款用户」等） |
|
||||
77|| **对外接口** | `POST /api/outreach/im/send` — 发送 IM 消息 |
|
||||
78|| **数据写入** | `im_interaction_records`, `im_flow_tags` |
|
||||
79|| **依赖** | JOYHUB（IM 通道）；`GET /api/quota/check/{person_id}` |
|
||||
80|| **待确认** | IM 是 WhatsApp 还是自研 IM？通道对接方式？ |
|
||||
81|
|
||||
82|### 2.4 M4: EDM 执行引擎
|
||||
83|
|
||||
84|| 维度 | 说明 |
|
||||
85|| --- | --- |
|
||||
86|| **对内** | 推送前检查（身份→风险→退订→资格→国家）；行为筛选（打开/点击/回复/频率）；节奏判断（适合触达/需降频/不适合）；发送后追踪（送达→打开→点击→回复→退订）；转化路径（下载注册APP→转IM / 直接回复邮件→生成客服工单 / 未响应→再触达队列） |
|
||||
87|| **对外接口** | `POST /api/outreach/edm/send` — 发送 EDM |
|
||||
88|| **数据写入** | `edm_message_events`, `edm_user_behavior_profiles` |
|
||||
89|| **依赖** | ESP 邮件服务 |
|
||||
90|| **待确认** | EDM 模板在哪里管理？模板变量（用户名/产品名/链接）如何填充？ |
|
||||
91|
|
||||
92|### 2.5 M5: APP Push 引擎
|
||||
93|
|
||||
94|| 维度 | 说明 |
|
||||
95|| --- | --- |
|
||||
96|| **对内** | 5 种触发源（绑定新玩具/不活跃/计划到期/Listing紧急/活动）；推送前过滤（身份+风险+频控+标签）；响应追踪（点击打开→落地页 / 忽略→短期不重复推 / 卸载→转EDM候选池）；APP 内动作分流（提交回评/测评→IM核验 / 联系客服→工单 / 浏览→更新活跃标签） |
|
||||
97|| **对外接口** | `POST /api/outreach/app/push` — 发送 APP Push |
|
||||
98|| **数据写入** | `app_touch_events` |
|
||||
99|| **依赖** | FCM/APNs |
|
||||
100|| **待确认** | 是否复用 JOYHUB 现有 Push 通道？ |
|
||||
101|
|
||||
102|### 2.6 M6: TEL 执行引擎
|
||||
103|
|
||||
104|| 维度 | 说明 |
|
||||
105|| --- | --- |
|
||||
106|| **对内** | 7 种触发场景（答应配合超时/高价值跟进/复杂售后/多次无响应/紧急Listing/Amazon来电/外呼任务）；拨打前准备 5 步（查用户完整画像→查风险→查历史沟通→准备话术→生成电话工单）；通话结果 5 种（售后问题解决→引导回评 / 直接配合→登记答应配合 / 拒绝→记录 / 疑似诈骗→转风险 / 未接通→重试）；重试策略（<3次重拨 / ≥3次降级EDM或关闭） |
|
||||
107|| **对外接口** | `POST /api/outreach/tel/task` — 创建 TEL 任务 |
|
||||
108|| **数据写入** | `tel_call_records` |
|
||||
109|| **依赖** | 电话系统（外呼/来电） |
|
||||
110|
|
||||
111|### 2.7 M7: 触达历史服务
|
||||
112|
|
||||
113|| 维度 | 说明 |
|
||||
114|| --- | --- |
|
||||
115|| **对内** | 跨渠道聚合触达历史（IM/EDM/APP/TEL）；提供统一查询接口供 quota（频控）和 identity（上下文卡）消费 |
|
||||
116|| **对外接口** | `GET /api/outreach/history/{person_id}` |
|
||||
117|| **数据写入** | 只读聚合 |
|
||||
118|
|
||||
119|---
|
||||
120|
|
||||
121|## 3. 对外 API 契约（草案）
|
||||
122|
|
||||
123|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
124|| --- | --- | --- | --- | --- |
|
||||
125|| 触达历史 | `GET /api/outreach/history/{person_id}` | person_id | `{im[], edm[], app[], tel[]}` | quota（频控）, identity（上下文卡） |
|
||||
126|| 执行触达 | `POST /api/outreach/send` | `{plan_id, person_ids[], channel, content}` | `{task_id, status}` | planning |
|
||||
127|| 渠道路由决策 | `POST /api/outreach/route` | `{person_id, plan_id}` | `{recommended_channel, alternatives[]}` | planning |
|
||||
128|| IM 消息发送 | `POST /api/outreach/im/send` | `{person_id, msg_type, content}` | `{message_id}` | 内部 |
|
||||
129|
|
||||
130|---
|
||||
131|
|
||||
132|## 4. 数据对象
|
||||
133|
|
||||
134|| 对象 | 核心字段 | 说明 |
|
||||
135|| --- | --- | --- |
|
||||
136|| `channel_route_decisions` | decision_id, person_id, plan_id, selected_channel, reason, decided_at | 渠道路由决策 |
|
||||
137|| `channel_dedup_records` | dedup_id, person_id, plan_id, channel, status(BLOCKED/ALLOWED), block_reason | 渠道去重记录 |
|
||||
138|| `im_interaction_records` | interaction_id, person_id, msg_type(PUSH_CARD/REVIEW_CARD/EXEMPTION_CARD/REMINDER/REFUND_NOTICE), direction(OUTBOUND/INBOUND), content, status, created_at | IM 交互记录 |
|
||||
139|| `im_flow_tags` | tag_id, person_id, tag_type, tag_value, tagged_at | IM 流程标签（如 xx产品待返款等） |
|
||||
140|| `edm_message_events` | event_id, person_id, email, event_type(SENT/DELIVERED/OPENED/CLICKED/REPLIED/UNSUBSCRIBED/HARD_BOUNCED), occurred_at | EDM 事件 |
|
||||
141|| `edm_user_behavior_profiles` | profile_id, person_id, email, last_opened_at, total_opens, consecutive_no_open, last_replied_at, monthly_received, status | EDM 用户行为画像 |
|
||||
142|| `app_touch_events` | event_id, person_id, trigger_type, push_status, response, occurred_at | APP Push 事件 |
|
||||
143|| `tel_call_records` | call_id, person_id, ticket_id, direction(OUTBOUND/INBOUND), call_status, duration, outcome, retry_count, recorded_at | TEL 通话记录 |
|
||||
144|
|
||||
145|---
|
||||
146|
|
||||
147|## 5. 业务澄清问题清单 — outreach
|
||||
148|
|
||||
149|### 5.1 渠道优先级路由（4 项）
|
||||
150|
|
||||
151|| # | 问题 | 优先级 |
|
||||
152|| --- | --- | --- |
|
||||
153|| O-01 | 路由规则是否可配置？（例如针对某个站点用户调整 IM > EDM 的优先级）配置界面在 outreach 内还是在独立配置管理？ | **P0** |
|
||||
154|| O-02 | 「APP 低活跃」的判定标准是什么？（N 天未打开？N 天未点击推送？）阈值是否可配置？ | P1 |
|
||||
155|| O-03 | 高优先级渠道发送失败（退信/未送达）后，是否自动降级到下一渠道？降级是否有冷却时间？ | P1 |
|
||||
156|| O-04 | C 类用户（累计≥12）只推免评——如果免评计划也没有，是完全不推还是推品牌/活动内容？ | P2 |
|
||||
157|
|
||||
158|### 5.2 IM 通道（4 项）
|
||||
159|
|
||||
160|| # | 问题 | 优先级 |
|
||||
161|| --- | --- | --- |
|
||||
162|| O-05 | IM 使用的具体平台是什么？（WhatsApp Business API / 自研 JOYHUB IM / Messenger？）不同平台的 API 能力和限制？ | **P0** |
|
||||
163|| O-06 | IM 的「分层」是系统自动判断还是人工可干预？（一个 B 类用户会不会被错误标记为 C 类？如何修正？） | **P0** |
|
||||
164|| O-07 | IM 推送中「测评卡片」的具体形式是什么？（带按钮的消息模板？需要用户填表单？）模板在哪里管理？ | P1 |
|
||||
165|| O-08 | IM 中的「订单号核实」——核实的数据源是什么？（比对内部订单表？Amazon 订单 API？）核实失败的转人工流程？ | P1 |
|
||||
166|
|
||||
167|### 5.3 EDM 通道（4 项）
|
||||
168|
|
||||
169|| # | 问题 | 优先级 |
|
||||
170|| --- | --- | --- |
|
||||
171|| O-09 | 当前使用的邮件服务是什么？（SendGrid/Mailchimp/SES/自建？）有没有现成 API 和 Webhook 追踪？ | **P0** |
|
||||
172|| O-10 | EDM 模板（邮件内容、样式、多语言）在哪里管理？属于 outreach 还是独立内容管理子系统？ | P1 |
|
||||
173|| O-11 | 「EDM 行为画像」中的「最近 3/5 次 0 打开」——3 次和 5 次是两个独立指标还是二选一？各自对应什么策略？ | P1 |
|
||||
174|| O-12 | EDM 发送量和频控——单日最大发送量有限制吗？（ESP 的每日限额？） | P1 |
|
||||
175|
|
||||
176|### 5.4 APP Push（3 项）
|
||||
177|
|
||||
178|| # | 问题 | 优先级 |
|
||||
179|| --- | --- | --- |
|
||||
180|| O-13 | APP Push 是否复用 JOYHUB 的现有推送通道？还是需要独立接入 FCM（Android）和 APNs（iOS）？ | **P0** |
|
||||
181|| O-14 | APP Push 和 IM 消息的分工——文档第 11.2 节给了对照表，但边界是否绝对？（例如"计划到期提醒"是否可能同时走 APP Push 和 IM？） | P1 |
|
||||
182|| O-15 | APP 落地页——推送点击后跳转到哪个页面？（APP 内的测评页？IM 对话页？）落地页由哪个团队/子系统负责？ | P2 |
|
||||
183|
|
||||
184|### 5.5 TEL 通道（3 项）
|
||||
185|
|
||||
186|| # | 问题 | 优先级 |
|
||||
187|| --- | --- | --- |
|
||||
188|| O-16 | 电话系统使用什么方案？（自建 SIP PBX / Twilio / 其他云呼叫中心？）是否已有通话记录？ | **P0** |
|
||||
189|| O-17 | 「拨打前准备」第 2 步「查风险：强关联命中→暂停拨打→先复核」——复核由谁来做？（风险人员？客服组长？）复核时长预期？ | P1 |
|
||||
190|| O-18 | 电话中「尽量确认」的字段（购买平台、订单号、产品型号、购买时间、问题类型、凭证）如果用户不愿意/无法提供——哪些是必须确认的？哪些可以跳过？ | P1 |
|
||||
191|
|
||||
### 5.6 消息内容与合规（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| O-19 | 消息内容是否需要审核？（IM 推送文案、EDM 邮件内容、APP Push——上线前是否需要审核？审核流程？） | P1 |
|
||||
| O-20 | EDM 合规要求——是否遵守 CAN-SPAM Act（美国）、GDPR（欧洲）、CASL（加拿大）？退订机制是否满足法律要求？ | P1 |
|
||||
| O-21 | IM 平台的合规限制——WhatsApp 等平台禁止垃圾消息和特定类型内容（如测评引导）——是否有合规风险？ | P1 |
|
||||
| O-22 | 消息发送的时区感知——美国用户、英国用户、德国用户的推送时间是否需要本地化？（用户当地时间的白天而非半夜） | P1 |
|
||||
|
||||
### 5.7 消息策略与实验（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| O-23 | 是否需要 A/B 测试能力？（同一计划的两组用户收到不同文案/不同发送时间——对比转化率？） | P2 |
|
||||
| O-24 | 消息打开率/点击率/转化率的追踪和报表？是否需要自动优化发送策略（高打开率的文案模板优先使用）？ | P2 |
|
||||
| O-25 | 用户反馈「消息太频繁/内容不相关」——是否有投诉/退订统计和预警？（投诉率超过 X% 暂停该类型推送？） | P1 |
|
||||
|
||||
### 5.8 IM 通道补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| O-26 | IM 消息的「已读」状态是否能获取？（WhatsApp 的蓝色双勾——能否用于判断用户是否看到消息？） | P1 |
|
||||
| O-27 | IM 用户提交的「评论截图/链接」——如何自动验证截图的真实性？（防止用户 PS 假截图？是否需要 OCR 识别截图内容？） | P1 |
|
||||
| O-28 | IM 中的返款通知——返款是系统自动触发还是人工触发？返款状态如何回写到 outreach？ | P1 |
|
||||
|
||||
### 5.9 EDM 通道补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| O-29 | EDM 的「硬退信」和「投诉」是否自动同步到 identity 的风险标记？（硬退信用户是否需要进入风险观察？） | P1 |
|
||||
| O-30 | EDM 引导用户下载 APP——是否在邮件中嵌入归因链接（deferred deep link）以追踪转化来源？ | P2 |
|
||||
| O-31 | EDM 的发送域名和 IP 预热策略？（新域名/IP 直接大批量发送会被 ESP 判定为垃圾邮件——需要渐进式预热？） | P2 |
|
||||
|
||||
### 5.10 TEL 通道补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| O-32 | 电话录音是否需要存储？存储多久？谁有权调取录音？（涉及合规和隐私） | P1 |
|
||||
| O-33 | 不同国家的电话合规要求——美国需提前告知录音、德国的 GDPR 限制——如何处理？ | P1 |
|
||||
| O-34 | TEL 任务的优先级和分配——多个外呼任务同时存在时，客服按什么顺序拨打？（先打高价值用户？先打答应配合超时的？） | P1 |
|
||||
|
||||
### 5.11 实施层面（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| O-35 | 各外部通道的 rate limit 和计费模式？（WhatsApp 按消息数计费？EDM 按发送量计费？）是否需要成本控制？ | P1 |
|
||||
| O-36 | 消息发送是同步还是异步？（用户点「发送」后立即返回还是后台队列处理？失败重试策略？） | P1 |
|
||||
| O-37 | 多渠道消息的发送顺序保证？（「先发 IM 提醒→24h 后无回复再发 EDM」——这种时序依赖如何实现？定时任务？延迟队列？） | P2 |
|
||||
| O-38 | 异常场景——如果某渠道 100% 发送失败（ESP 宕机/WhatsApp API 限流）——是否自动切换备用渠道？ | P2 |
|
||||
214
wishfulfilled-wiki/05_需求文档/05-子系统-客服工单与管理.md
Normal file
214
wishfulfilled-wiki/05_需求文档/05-子系统-客服工单与管理.md
Normal file
@@ -0,0 +1,214 @@
|
||||
1|# 子系统 05 — 客服工单与管理 (`support`) v1.0
|
||||
2|
|
||||
3|## 子系统概述
|
||||
4|
|
||||
5|| 维度 | 说明 |
|
||||
6|| --- | --- |
|
||||
7|| 代号 | `support` |
|
||||
8|| 核心职责 | 工单生命周期管理、自动分配、答应配合状态机、排班出勤管理、绩效统计 |
|
||||
9|| 数据所有权 | `support_tickets`, `support_followups`, `support_assignment_logs`, `attendance_records`, `shift_schedules`, `support_performance_snapshots` |
|
||||
10|| 启动依赖 | identity（软依赖，无上下文卡时可先跑工单） |
|
||||
11|| 外部系统依赖 | 无直接外部依赖（电话记录来自 outreach TEL 模块） |
|
||||
12|
|
||||
13|---
|
||||
14|
|
||||
15|## 1. 模块划分
|
||||
16|
|
||||
17|```
|
||||
18|┌─────────────────────────────────────────────────────────────┐
|
||||
19|│ support 子系统 │
|
||||
20|│ │
|
||||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
22|│ │ M1: 工单管理 │ │ M2: 自动分配 │ │ M3: 答应配合 │ │
|
||||
23|│ │ (Ticket) │→│ (Assign) │ │ 状态机 │ │
|
||||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
25|│ │ │ │ │
|
||||
26|│ ▼ ▼ ▼ │
|
||||
27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
28|│ │ M4: 排班出勤 │ │ M5: 绩效统计 │ │ M6: 对外 API │ │
|
||||
29|│ │ 管理 │ │ │ │ Gateway │ │
|
||||
30|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
31|│ │
|
||||
32|└─────────────────────────────────────────────────────────────┘
|
||||
33|```
|
||||
34|
|
||||
35|| # | 模块 | 职责 |
|
||||
36|| --- | --- | --- |
|
||||
37|| M1 | 工单管理 | 工单创建、分类、状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭） |
|
||||
38|| M2 | 自动分配 | 按班次+在线状态+当前负载+最大工单数自动分配到客服组；组长再分派到组员 |
|
||||
39|| M3 | 答应配合状态机 | 独立的答应配合状态流转（已答应→待分配→待提醒→等待提交→已提交/超时→需再次联系→关闭） |
|
||||
40|| M4 | 排班出勤管理 | 排班设置、出勤记录（应出勤/实际出勤/迟到/早退/请假/缺勤）、在线客服池维护 |
|
||||
41|| M5 | 绩效统计 | 回复效率（回复用户数/处理工单数/首次回复时长分布）；转化统计（RSO回评/RDO测评登记订单数/获取评价数/完成率）；目标完成统计 |
|
||||
42|| M6 | 对外 API Gateway | 供其他子系统创建工单、查询工单状态、查询绩效数据 |
|
||||
43|
|
||||
44|---
|
||||
45|
|
||||
46|## 2. 各模块内外说明
|
||||
47|
|
||||
48|### 2.1 M1: 工单管理
|
||||
49|
|
||||
50|| 维度 | 说明 |
|
||||
51|| --- | --- |
|
||||
52|| **对内** | 5 种入口（用户消息进入/推送转人工/售后触发/风险触发/电话后续）；工单状态流转（待分配→已分配→处理中→等待用户/等待内部→已解决/疑似诈骗→已关闭）；5 种处理结果（等待用户回复/等待内部协同/答应配合/疑似诈骗/已解决） |
|
||||
53|| **对外接口** | `POST /api/tickets` — 创建工单；`PUT /api/tickets/{id}/status` — 更新状态 |
|
||||
54|| **数据写入** | `support_tickets` |
|
||||
55|| **依赖** | `GET /api/identity/context/{person_id}` — 展示用户上下文卡 |
|
||||
56|| **待确认** | 工单类型分类维度？（售后/催评/风险/其他？是否需要自定义分类？） |
|
||||
57|
|
||||
58|### 2.2 M2: 自动分配
|
||||
59|
|
||||
60|| 维度 | 说明 |
|
||||
61|| --- | --- |
|
||||
62|| **对内** | 分配算法（查班次+在线状态+当前负载+最大工单数→自动分配到客服组）；组长可在组内重新分派到具体组员；分配日志记录 |
|
||||
63|| **对外接口** | 内部服务 |
|
||||
64|| **数据写入** | `support_assignment_logs` |
|
||||
65|| **依赖** | M4 排班出勤数据 |
|
||||
66|| **待确认** | 「当前负载」按什么计算？（未关闭工单数？最近 N 小时处理量？两者加权？） |
|
||||
67|
|
||||
68|### 2.3 M3: 答应配合状态机
|
||||
69|
|
||||
70|| 维度 | 说明 |
|
||||
71|| --- | --- |
|
||||
72|| **对内** | 独立于工单状态的状态机（已答应配合→待分配负责人→待提醒→等待提交→已提交评价/已提交反馈→超时→需再次联系→已关闭）；防止承诺用户流失；超时提醒机制 |
|
||||
73|| **对外接口** | `POST /api/support/followups` — 创建跟进任务；`PUT /api/support/followups/{id}` — 更新状态 |
|
||||
74|| **数据写入** | `support_followups` |
|
||||
75|| **待确认** | 答应配合后多少天未提交算超时？超时后提醒频率？多次提醒无果后是否降级？ |
|
||||
76|
|
||||
77|### 2.4 M4: 排班出勤管理
|
||||
78|
|
||||
79|| 维度 | 说明 |
|
||||
80|| --- | --- |
|
||||
81|| **对内** | 排班设置（按日/周的班次安排）；出勤记录（应出勤/实际出勤/出勤率/迟到/早退/请假/缺勤）；在线客服池（排班+在线状态→可用客服列表） |
|
||||
82|| **对外接口** | `GET /api/support/available-agents` — 查询当前可用客服 |
|
||||
83|| **数据写入** | `attendance_records`, `shift_schedules` |
|
||||
84|| **待确认** | 排班是否对接外部 HR 系统还是独立管理？客服手动签入/签出？ |
|
||||
85|
|
||||
86|### 2.5 M5: 绩效统计
|
||||
87|
|
||||
88|| 维度 | 说明 |
|
||||
89|| --- | --- |
|
||||
90|| **对内** | 回复效率（回复用户数、处理工单数、发送消息数、首次回复时长：平均/中位数/最大/最小）；转化统计（RSO 回评登记订单数、RDO 测评登记订单数、获取评价数、评价完成率）；目标完成（月目标、当前完成、完成率、历史趋势）；主管看板 |
|
||||
91|| **对外接口** | `GET /api/support/stats?agent_id=&period=` — 绩效数据查询 |
|
||||
92|| **数据写入** | `support_performance_snapshots`（定时快照） |
|
||||
93|| **待确认** | 绩效统计周期（日/周/月？）主管看板是否需要实时数据还是 T+1 汇总？ |
|
||||
94|
|
||||
95|---
|
||||
96|
|
||||
97|## 3. 对外 API 契约（草案）
|
||||
98|
|
||||
99|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
100|| --- | --- | --- | --- | --- |
|
||||
101|| 创建工单 | `POST /api/tickets` | `{person_id, source, type, description}` | `{ticket_id}` | outreach（TEL→工单/EDM回复→工单）、risk（诈骗→工单） |
|
||||
102|| 工单详情 | `GET /api/tickets/{id}` | ticket_id | 完整工单+上下文卡 | 客服前端 |
|
||||
103|| 查询用户打开工单 | `GET /api/tickets?person_id=&status=open` | person_id | `[{ticket_id, status}]` | outreach（渠道去重）、quota（终校） |
|
||||
104|| 客服可用性 | `GET /api/support/available-agents` | 无 | `[{agent_id, current_load}]` | outreach（分配参考） |
|
||||
105|| 绩效查询 | `GET /api/support/stats?agent_id=&period=` | agent_id + 周期 | 绩效数据 | 客服管理前端 |
|
||||
106|
|
||||
107|---
|
||||
108|
|
||||
109|## 4. 数据对象
|
||||
110|
|
||||
111|| 对象 | 核心字段 | 说明 |
|
||||
112|| --- | --- | --- |
|
||||
113|| `support_tickets` | ticket_id, person_id, source, type, status, assigned_agent, assigned_group, created_at, resolved_at | 工单主表 |
|
||||
114|| `support_followups` | followup_id, ticket_id, person_id, status(PROMISED/ASSIGNED/WAITING/SUBMITTED/TIMEOUT/RECONTACT/CLOSED), promised_at, deadline_at, reminded_at | 答应配合跟进 |
|
||||
115|| `support_assignment_logs` | log_id, ticket_id, from_agent, to_agent, reason, assigned_at | 工单分配日志 |
|
||||
116|| `attendance_records` | record_id, agent_id, date, status(PRESENT/LATE/EARLY/ABSENT/LEAVE), check_in, check_out | 出勤记录 |
|
||||
117|| `shift_schedules` | shift_id, agent_id, date, shift_type, start_time, end_time | 排班表 |
|
||||
118|| `support_performance_snapshots` | snapshot_id, agent_id, period, tickets_handled, messages_sent, avg_first_reply, rso_orders, rdo_orders, reviews_obtained, completion_rate | 绩效快照 |
|
||||
119|
|
||||
120|---
|
||||
121|
|
||||
122|## 5. 业务澄清问题清单 — support
|
||||
123|
|
||||
124|### 5.1 工单管理（5 项）
|
||||
125|
|
||||
126|| # | 问题 | 优先级 |
|
||||
127|| --- | --- | --- |
|
||||
128|| S-01 | 工单的来源分类有哪些？（IM 转人工 / 电话后续 / EDM 回复 / 用户主动联系 / 风险触发 / 其他？）每种来源的优先级是否不同？ | **P0** |
|
||||
129|| S-02 | 工单状态「等待用户」和「等待内部」的超时分别是多少？超时后谁来提醒？提醒方式（IM/系统通知）？ | **P0** |
|
||||
130|| S-03 | 三套并行状态（工单状态/答应配合状态/风险状态）的交互规则？例如：风险状态变为「确认诈骗」时工单是否自动关闭？（目前文档说是独立拆开的） | P1 |
|
||||
131|| S-04 | 工单关闭后是否允许重新打开？什么条件可重开？ | P1 |
|
||||
132|| S-05 | 工单是否有 SLA（服务级别协议）？不同来源/类型的工单 SLA 不同？ | P2 |
|
||||
133|
|
||||
134|### 5.2 自动分配（4 项）
|
||||
135|
|
||||
136|| # | 问题 | 优先级 |
|
||||
137|| --- | --- | --- |
|
||||
138|| S-06 | 「当前负载」如何精确计算？（未关闭工单数 × 权重？最近 N 小时处理量？工单类型权重不同？） | **P0** |
|
||||
139|| S-07 | 「最大工单数」是什么？（每个客服同时最多持有 X 个工单？）这个值是否统一还是按级别不同？ | **P0** |
|
||||
140|| S-08 | 在线状态如何判定？（手动签入/签出？系统自动检测活跃度？N 分钟无操作自动离线？） | P1 |
|
||||
141|| S-09 | 自动分配如果分配给了离线/满载的客服，兜底机制是什么？（自动转移给组长？放入公共池？） | P1 |
|
||||
142|
|
||||
143|### 5.3 答应配合（3 项）
|
||||
144|
|
||||
145|| # | 问题 | 优先级 |
|
||||
146|| --- | --- | --- |
|
||||
147|| S-10 | 答应配合后多少天未提交算超时？超时后的提醒频率？（第 1/3/7 天各提醒一次？）多次提醒无果后关闭还是降级？ | **P0** |
|
||||
148|| S-11 | 用户答应配合但最终提交了错误的 ASIN 评价——算不算配合完成？如何处理？ | P1 |
|
||||
149|| S-12 | 答应配合状态是否只针对客服工单场景？IM 直推中用户答应的算不算？ | P1 |
|
||||
150|
|
||||
151|### 5.4 排班出勤（3 项）
|
||||
152|
|
||||
153|| # | 问题 | 优先级 |
|
||||
154|| --- | --- | --- |
|
||||
155|| S-13 | 排班管理是否对接外部 HR 系统？还是独立在 support 子系统内管理？ | P1 |
|
||||
156|| S-14 | 菲律宾客服团队的工作制度？（班次类型：早班/中班/晚班？每班时长？每周几天？） | P1 |
|
||||
157|| S-15 | 出勤异常（迟到/早退/缺勤）是否需要自动通知主管？通知方式？ | P2 |
|
||||
158|
|
||||
159|### 5.5 绩效统计（3 项）
|
||||
160|
|
||||
161|| # | 问题 | 优先级 |
|
||||
162|| --- | --- | --- |
|
||||
163|| S-16 | 转化统计中 RSO（回评）和 RDO（测评）如何区分？（按工单来源？按关联计划类型？按客服标记？） | P1 |
|
||||
164|| S-17 | 「首次回复时长」从什么时候开始计时？（工单分配给客服的时间？用户消息到达时间？） | P1 |
|
||||
165|| S-18 | 评价完成率的分母是什么？（答应配合数？登记订单数？触达数？） | P2 |
|
||||
166|
|
||||
### 5.6 多语言与国际化（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| S-19 | 客服工作台需要支持哪些语言？（菲律宾客服用英语+Tagalog？面向用户的消息是否需要自动翻译？） | P1 |
|
||||
| S-20 | 用户消息的多语言处理——用户用德语/法语/西语发消息时，客服如何理解？（是否需要集成翻译工具？） | P2 |
|
||||
| S-21 | 系统管理界面（排班/绩效/设置）是否需要多语言？面向中国管理团队的是中文界面？ | P2 |
|
||||
|
||||
### 5.7 知识库与话术（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| S-22 | 是否需要集成知识库/FAQ？（客服在处理售后时快速查找产品信息、常见问题解答？） | P2 |
|
||||
| S-23 | 是否需要「快捷回复」功能？（预设常用回复模板——「请提供你的订单号」「我们将在 24h 内处理你的退款」等） | P1 |
|
||||
| S-24 | 快捷回复模板是否支持按场景/产品分类？（不同产品的售后话术不同——模板管理和权限？） | P2 |
|
||||
|
||||
### 5.8 客服质量管控（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| S-25 | 是否需要客户满意度（CSAT）调查？（工单关闭后推送满意度评分——评分方式？计入绩效？） | P2 |
|
||||
| S-26 | 是否需要质检功能？（组长抽查客服的对话记录进行评分——质检抽样比例？质检标准？） | P2 |
|
||||
| S-27 | 客服技能分组——不同客服擅长不同类型工单（售后/催评/风控）——是否需要基于技能的自动分配？ | P1 |
|
||||
| S-28 | 升级工单的处理流程——什么条件下工单升级到组长/负责人？（超时？用户投诉？疑似诈骗？） | P1 |
|
||||
|
||||
### 5.9 排班与出勤补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| S-29 | 排班是否支持轮班制？（周一到周日每天不同的班次安排）排班变更的通知方式？ | P1 |
|
||||
| S-30 | 临时调班/换班请求——客服之间是否可以自助换班？是否需要审批？ | P2 |
|
||||
| S-31 | 节假日/特殊日期的排班策略？（当地节假日——菲律宾假日 vs 美国假日 vs 中国假日——按哪国日历？） | P1 |
|
||||
|
||||
### 5.10 绩效统计补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| S-32 | 绩效考核周期？（日/周/月/季度？）绩效数据是否需要导出为报表？ | P1 |
|
||||
| S-33 | 绩效目标是否可自定义？（不同组的目标不同？新人目标低于老员工？）目标由谁设置？ | P1 |
|
||||
| S-34 | 绩效看板是否需要实时数据还是 T+1 汇总？（主管需要实时看到当前客服处理了多少工单？） | P2 |
|
||||
|
||||
### 5.11 实施层面（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| S-35 | 客服使用的 IM 工具——是独立于 outreach 的客服专用 IM 还是嵌入在客服工作台内的 Web IM？ | P1 |
|
||||
| S-36 | 工单数据是否需要与 outreach 的交互记录打通？（同一个用户在 IM 的聊天记录是否需要关联到工单？） | P1 |
|
||||
| S-37 | 客服工作台的实时性要求——新工单到达后多少秒内需要在客服界面显示？（WebSocket 推送 vs 轮询？） | P2 |
|
||||
191
wishfulfilled-wiki/05_需求文档/06-子系统-风险与反欺诈.md
Normal file
191
wishfulfilled-wiki/05_需求文档/06-子系统-风险与反欺诈.md
Normal file
@@ -0,0 +1,191 @@
|
||||
1|# 子系统 06 — 风险与反欺诈 (`risk`) v1.0
|
||||
2|
|
||||
3|## 子系统概述
|
||||
4|
|
||||
5|| 维度 | 说明 |
|
||||
6|| --- | --- |
|
||||
7|| 代号 | `risk` |
|
||||
8|| 核心职责 | 强弱关联判断、黑名单实体管理、风险事件管理、双重退款检测 |
|
||||
9|| 数据所有权 | `risk_signals`, `risk_cases`, `blacklist_entities`, `refund_match_results` |
|
||||
10|| 启动依赖 | identity（软依赖） |
|
||||
11|| 外部系统依赖 | Amazon（退款数据）、财务系统（OA 返款数据） |
|
||||
12|
|
||||
13|---
|
||||
14|
|
||||
15|## 1. 模块划分
|
||||
16|
|
||||
17|```
|
||||
18|┌─────────────────────────────────────────────────────────────┐
|
||||
19|│ risk 子系统 │
|
||||
20|│ │
|
||||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
22|│ │ M1: 关联判断 │ │ M2: 黑名单 │ │ M3: 双重退款 │ │
|
||||
23|│ │ 引擎 │→│ 管理 │ │ 检测 │ │
|
||||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
25|│ │ │ │ │
|
||||
26|│ ▼ ▼ ▼ │
|
||||
27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
28|│ │ M4: 风险事件 │ │ M5: 风险审核 │ │ M6: 对外 API │ │
|
||||
29|│ │ 管理 │ │ Admin │ │ Gateway │ │
|
||||
30|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
31|│ │
|
||||
32|└─────────────────────────────────────────────────────────────┘
|
||||
33|```
|
||||
34|
|
||||
35|| # | 模块 | 职责 |
|
||||
36|| --- | --- | --- |
|
||||
37|| M1 | 关联判断引擎 | 对每次风险信号做强弱关联判断（强：邮箱/设备/电话/地址/订单号/ProfileID/收款信息 命中→高风险；弱：IP单独/姓名单独/同址异名→观察+复核） |
|
||||
38|| M2 | 黑名单管理 | 黑名单实体管理（添加/移除/过期）、黑名单同步、命中查询 |
|
||||
39|| M3 | 双重退款检测 | Amazon 退款记录 vs OA 返款记录的自动比对，检测重复退款 |
|
||||
40|| M4 | 风险事件管理 | 风险事件创建、状态流转、关联工单/推送/计划状态回写 |
|
||||
41|| M5 | 风险审核 Admin | 人工复核弱关联风险、确认/排除诈骗、黑名单操作 |
|
||||
42|| M6 | 对外 API Gateway | 供所有子系统查询风险状态、上报风险信号 |
|
||||
43|
|
||||
44|---
|
||||
45|
|
||||
46|## 2. 各模块内外说明
|
||||
47|
|
||||
48|### 2.1 M1: 关联判断引擎
|
||||
49|
|
||||
50|| 维度 | 说明 |
|
||||
51|| --- | --- |
|
||||
52|| **对内** | 每次风险信号进入时执行：8 项强关联维度（邮箱/设备号/电话/收件人姓名+地址/订单号/聊天记录/Profile ID/收款信息）→任一命中→高风险；3 项弱关联维度（IP单独/姓名单独/同址异名）→高风险观察+人工复核；判断结果：强关联/弱关联/无关联 |
|
||||
53|| **对外接口** | `GET /api/risk/check/{person_id}` — 风险查询（含关联判断结果） |
|
||||
54|| **数据写入** | `risk_signals` |
|
||||
55|| **依赖** | `GET /api/identity/context/{person_id}` — 获取身份线索用于关联判断 |
|
||||
56|| **关键规则** | 风险判断不是一次性，每次有效互动都要重做；非 APP 用户缺设备/注册邮箱等维度→风险识别能力下降 |
|
||||
57|
|
||||
58|### 2.2 M2: 黑名单管理
|
||||
59|
|
||||
60|| 维度 | 说明 |
|
||||
61|| --- | --- |
|
||||
62|| **对内** | 黑名单实体 CRUD（邮箱/设备/电话/地址/收款信息）；黑名单命中查询（任何子系统查询用户是否在黑名单）；黑名单同步（确认诈骗后同步到黑名单）；黑名单过期/申诉机制 |
|
||||
63|| **对外接口** | `GET /api/risk/blacklist/check?type=EMAIL&value=xxx` — 黑名单命中检查 |
|
||||
64|| **数据写入** | `blacklist_entities` |
|
||||
65|| **待确认** | 黑名单是否有过期时间？申诉/移除流程？ |
|
||||
66|
|
||||
67|### 2.3 M3: 双重退款检测
|
||||
68|
|
||||
69|| 维度 | 说明 |
|
||||
70|| --- | --- |
|
||||
71|| **对内** | 采集 Amazon 退款记录（外部系统同步）+ OA 返款记录（财务系统同步）；按订单号/用户/金额/时间自动比对；匹配结果：无重复/疑似重复/确认重复；确认重复时强告警+阻止后续返款 |
|
||||
72|| **对外接口** | `GET /api/risk/double-refund-check/{person_id}` — 双重退款检测 |
|
||||
73|| **数据写入** | `refund_match_results` |
|
||||
74|| **依赖** | Amazon 退款数据（外部）、OA 返款数据（外部财务系统） |
|
||||
75|| **待确认** | Amazon 退款数据如何及时获取？OA 返款记录是否已有 API？ |
|
||||
76|
|
||||
77|### 2.4 M4: 风险事件管理
|
||||
78|
|
||||
79|| 维度 | 说明 |
|
||||
80|| --- | --- |
|
||||
81|| **对内** | 风险事件创建（客服上报疑似诈骗 / 双重退款检测 / 关联判断命中）；事件状态流转（待复核→复核中→确认风险/排除风险）；高风险链路动作（拦截继续推送/拦截自动退款/拦截自动放行）；回写关联工单/推送/计划状态 |
|
||||
82|| **对外接口** | `POST /api/risk/report` — 上报风险信号（客服、系统自动均可调用） |
|
||||
83|| **数据写入** | `risk_cases` |
|
||||
84|
|
||||
85|### 2.5 M5: 风险审核 Admin
|
||||
86|
|
||||
87|| 维度 | 说明 |
|
||||
88|| --- | --- |
|
||||
89|| **对内** | 人工复核弱关联风险；确认/排除诈骗判定；黑名单手动操作；风险口径维护 |
|
||||
90|| **对外接口** | 管理 API |
|
||||
91|| **待确认** | 复核时效要求？（N 分钟内必须复核？） |
|
||||
92|
|
||||
93|---
|
||||
94|
|
||||
95|## 3. 对外 API 契约（草案）
|
||||
96|
|
||||
97|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
98|| --- | --- | --- | --- | --- |
|
||||
99|| 风险查询 | `GET /api/risk/check/{person_id}` | person_id | `{risk_level(NONE/WEAK/STRONG), signals[], cases[]}` | 所有子系统（每次互动时调用） |
|
||||
100|| 上报风险信号 | `POST /api/risk/report` | `{person_id, signal_type, evidence, reported_by}` | `{signal_id}` | support（客服上报诈骗）、outreach（异常互动） |
|
||||
101|| 黑名单命中 | `GET /api/risk/blacklist/check?type=&value=` | 维度类型+值 | `{hit, entity}` | outreach（发送前）、identity（身份归并时） |
|
||||
102|| 双重退款检测 | `GET /api/risk/double-refund-check/{person_id}` | person_id | `{status, matched_refunds[]}` | outreach（返款前）、support（退款处理前） |
|
||||
103|
|
||||
104|---
|
||||
105|
|
||||
106|## 4. 数据对象
|
||||
107|
|
||||
108|| 对象 | 核心字段 | 说明 |
|
||||
109|| --- | --- | --- |
|
||||
110|| `risk_signals` | signal_id, person_id, signal_type, hit_dimensions[], risk_level(STRONG/WEAK), detected_at | 风险信号（每次互动生成的判断） |
|
||||
111|| `risk_cases` | case_id, person_id, source, status(PENDING_REVIEW/REVIEWING/CONFIRMED_RISK/RULED_OUT), reviewer, created_at, resolved_at | 风险事件 |
|
||||
112|| `blacklist_entities` | entity_id, entity_type(EMAIL/DEVICE/PHONE/ADDRESS/PAYMENT), entity_value, status(ACTIVE/EXPIRED/APPEALED), added_at, added_by | 黑名单实体 |
|
||||
113|| `refund_match_results` | match_id, person_id, amazon_refund_id, oa_refund_id, match_status(NO_DUPLICATE/SUSPECTED/CONFIRMED), matched_at | 双重退款比对结果 |
|
||||
114|
|
||||
115|---
|
||||
116|
|
||||
117|## 5. 业务澄清问题清单 — risk
|
||||
118|
|
||||
119|### 5.1 强弱关联规则（4 项）
|
||||
120|
|
||||
121|| # | 问题 | 优先级 |
|
||||
122|| --- | --- | --- |
|
||||
123|| R-01 | 8 项强关联维度中，每个维度的命中是独立判断还是组合判断？（例如仅「设备号命中」是否就足够判定强关联？还是需要「设备号 + 电话」同时命中？） | **P0** |
|
||||
124|| R-02 | 「强关联→直接进入高风险或黑名单链路」——这里的「直接」是指全自动化拦截无需人工确认？还是系统先拦截再人工审核？（涉及自动化力度） | **P0** |
|
||||
125|| R-03 | 弱关联的「观察期」多长？观察期过后是自动解除还是必须人工确认？观察期内用户继续参与互动如何处理？ | P1 |
|
||||
126|| R-04 | 风险判断中「IP 单独命中」列为弱关联——IP 从哪里获取？（JOYHUB APP？EDM 邮件头？客服系统？）不同来源的 IP 可靠性不同 | P1 |
|
||||
127|
|
||||
128|### 5.2 双重退款（4 项）
|
||||
129|
|
||||
130|| # | 问题 | 优先级 |
|
||||
131|| --- | --- | --- |
|
||||
132|| R-05 | Amazon 退款数据如何获取？（SP-API 实时拉取？T+1 同步？手动导入 CSV？）同步频率决定检测时效 | **P0** |
|
||||
133|| R-06 | OA 返款系统是哪个？是否有 API？如果没有 API，返款记录怎么录入？（财务手动录入？CSV 导入？） | **P0** |
|
||||
134|| R-07 | 「双重退款」比对的关键字段是什么？（订单号？金额？用户？时间窗口？）匹配精度？（金额完全相等还是 ±X%？时间窗口多宽？） | P1 |
|
||||
135|| R-08 | 确认重复退款后，阻止后续返款——「阻止」是指系统自动拦截返款指令，还是只发告警让人工决定？ | P1 |
|
||||
136|
|
||||
137|### 5.3 黑名单管理（3 项）
|
||||
138|
|
||||
139|| # | 问题 | 优先级 |
|
||||
140|| --- | --- | --- |
|
||||
141|| R-09 | 黑名单是否有过期/申诉/解除机制？（例如用户被误标后如何申诉？谁有权解除？） | P1 |
|
||||
142|| R-10 | 黑名单是否需要与外部系统同步？（例如 JOYHUB 的黑名单？Amazon 的欺诈标记？）同步方向？ | P1 |
|
||||
143|| R-11 | 黑名单的粒度——是标记「真实人」还是「某个维度的值」？（标记的是真实人 ID 还是具体的邮箱/设备？） | P1 |
|
||||
144|
|
||||
145|### 5.4 风险可见性（3 项）
|
||||
146|
|
||||
147|| # | 问题 | 优先级 |
|
||||
148|| --- | --- | --- |
|
||||
149|| R-12 | 文档要求「客服、审核、退款等环节必须都能看到风险提醒」——风险提醒的展现形式是什么？（红色标签？弹窗？工单页顶部横幅？） | P1 |
|
||||
150|| R-13 | 风险状态的「提醒」通过什么通道发送？（audit 通知中心？IM 消息？系统内消息？） | P1 |
|
||||
151|| R-14 | 风险人员角色是否需要独立的风险控制台前端？该前端需要哪些功能？（事件列表/审核工作台/黑名单管理/统计报表？） | P2 |
|
||||
152|
|
||||
### 5.5 高级风险检测能力（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| R-15 | 是否需要行为速度检测？（同一真实人短时间内大量注册/大量申请退款/大量提交评价→触发异常行为告警？） | P1 |
|
||||
| R-16 | 是否需要设备指纹/浏览器指纹？（识别同一设备换账号、模拟器、虚拟机等欺诈行为？） | P2 |
|
||||
| R-17 | 是否需要地理位置异常检测？（同一账号短期内从不同国家/城市登录→触发告警？） | P2 |
|
||||
| R-18 | 风险评分模型——是否需要一个综合风险分数（0-100）而非二元判断（强/弱/无）？评分模型的因子和权重？ | P1 |
|
||||
|
||||
### 5.6 风险事件处理流程（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| R-19 | 风险事件的优先级（P0/P1/P2）如何定义？（双重退款确认→P0？单次弱关联→P2？）不同优先级的响应 SLA？ | P1 |
|
||||
| R-20 | 风险人员的工作台——是否需要「待审核队列」「审核中」「已处理」等看板视图？是否需要分配给具体审核人？ | P1 |
|
||||
| R-21 | 同一个人短时间内触发多次风险信号——是每次生成新事件还是合并到已有事件？合并规则？ | P1 |
|
||||
|
||||
### 5.7 黑名单管理补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| R-22 | 黑名单的生效范围——加入黑名单后是「全系统拦截」还是「只拦截某些操作」？（是否还允许正常购买？只拦截测评参与？） | P1 |
|
||||
| R-23 | 黑名单是否需要分级？（一级黑名单→全拦截 / 二级黑名单→降频+人工审核 / 三级黑名单→仅标记提醒） | P1 |
|
||||
| R-24 | 黑名单是否需要与外部欺诈数据库同步？（如行业共享的欺诈黑名单？Amazon 的 abuse 标记？） | P2 |
|
||||
|
||||
### 5.8 非 APP 用户风险盲区（2 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| R-25 | 文档已明确「非 APP 用户识别能力下降」——是否需要额外的风控措施？（例如非 APP 用户的返款额度降低？首次返款必须人工审核？） | P1 |
|
||||
| R-26 | 是否计划引导非 APP 用户注册 APP 以补全风险画像？（EDM/客服主动引导注册——注册转化跟踪？） | P2 |
|
||||
|
||||
### 5.9 实施层面（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| R-27 | 风险判断的实时性要求——每次互动时实时调用 risk API？（性能 overhead？需要缓存策略？） | P1 |
|
||||
| R-28 | 双重退款检测的时效——Amazon 退款数据（外部）同步延迟 vs OA 返款实时——T+N 的延迟是否可接受？ | P1 |
|
||||
| R-29 | 风险事件的数据保留策略？（已解决的诈骗案件数据保留多久？用于后续模型训练还是定期清理？） | P2 |
|
||||
171
wishfulfilled-wiki/05_需求文档/07-子系统-评价结果追踪.md
Normal file
171
wishfulfilled-wiki/05_需求文档/07-子系统-评价结果追踪.md
Normal file
@@ -0,0 +1,171 @@
|
||||
1|# 子系统 07 — 评价结果追踪 (`review`) v1.0
|
||||
2|
|
||||
3|## 子系统概述
|
||||
4|
|
||||
5|| 维度 | 说明 |
|
||||
6|| --- | --- |
|
||||
7|| 代号 | `review` |
|
||||
8|| 核心职责 | 用户真实提交评价记录、Amazon 展示核验、ASIN 健康/计划完成度更新回流 |
|
||||
9|| 数据所有权 | `review_submission_records`, `review_display_checks`, `review_results` |
|
||||
10|| 启动依赖 | identity / planning（软依赖） |
|
||||
11|| 外部系统依赖 | Amazon（评价展示状态、ASIN 评分数据） |
|
||||
12|
|
||||
13|---
|
||||
14|
|
||||
15|## 1. 模块划分
|
||||
16|
|
||||
17|```
|
||||
18|┌─────────────────────────────────────────────────────────────┐
|
||||
19|│ review 子系统 │
|
||||
20|│ │
|
||||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
22|│ │ M1: 评价提交 │ │ M2: 展示核验 │ │ M3: 结果回流 │ │
|
||||
23|│ │ 记录 │→│ │→│ 引擎 │ │
|
||||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
25|│ │ │ │ │
|
||||
26|│ ▼ ▼ ▼ │
|
||||
27|│ ┌──────────────┐ ┌──────────────┐ │
|
||||
28|│ │ M4: 异常观察 │ │ M5: 对外 API │ │
|
||||
29|│ │ 队列 │ │ Gateway │ │
|
||||
30|│ └──────────────┘ └──────────────┘ │
|
||||
31|│ │
|
||||
32|└─────────────────────────────────────────────────────────────┘
|
||||
33|```
|
||||
34|
|
||||
35|| # | 模块 | 职责 |
|
||||
36|| --- | --- | --- |
|
||||
37|| M1 | 评价提交记录 | 记录用户真实提交评价的事实（提交时点、提交证据、关联计划、关联 ASIN） |
|
||||
38|| M2 | 展示核验 | 核查 Amazon 是否展示该评价 / 是否可核验 |
|
||||
39|| M3 | 结果回流引擎 | 将评价结果反馈给 planning（计划完成度）、identity（用户标签）、audit |
|
||||
40|| M4 | 异常观察队列 | 用户已提交但 Amazon 未展示 / 暂不可核验的评价，进入定期复查队列 |
|
||||
41|| M5 | 对外 API Gateway | 供 outreach、planning 查询评价进度、提交评价 |
|
||||
42|
|
||||
43|---
|
||||
44|
|
||||
45|## 2. 各模块内外说明
|
||||
46|
|
||||
47|### 2.1 M1: 评价提交记录
|
||||
48|
|
||||
49|| 维度 | 说明 |
|
||||
50|| --- | --- |
|
||||
51|| **对内** | 记录两个核心事实：①用户真实提交评价（时间、ASIN、评论内容/截图/链接、关联计划）；②提交后立即更新真实人累计评价额度（调用 quota 子系统 `commit`） |
|
||||
52|| **对外接口** | `POST /api/reviews/submission` — 记录评价提交 |
|
||||
53|| **数据写入** | `review_submission_records` |
|
||||
54|| **依赖** | `POST /api/quota/commit` — 确认额度占用（提交后立即计数12） |
|
||||
55|| **关键规则** | 「用户真实提交评价」和「Amazon 展示确认」是两个独立事实；额度计数按前者，计划完成按后者 |
|
||||
56|
|
||||
57|### 2.2 M2: 展示核验
|
||||
58|
|
||||
59|| 维度 | 说明 |
|
||||
60|| --- | --- |
|
||||
61|| **对内** | 核查 Amazon 是否展示该评价 / 是否可核验；核验方式（待确认：爬取 / 手动 / API / 截图？）；核验结果：①展示或可核验→计入计划完成 ②未展示/暂不可核验→保留已提交事实→进入异常观察 |
|
||||
62|| **对外接口** | `POST /api/reviews/verify` — 触发核验（或定时核验） |
|
||||
63|| **数据写入** | `review_display_checks` |
|
||||
64|| **依赖** | Amazon（评价展示数据） |
|
||||
65|| **待确认** | 核验是自动还是人工？核验频率？ |
|
||||
66|
|
||||
67|### 2.3 M3: 结果回流引擎
|
||||
68|
|
||||
69|| 维度 | 说明 |
|
||||
70|| --- | --- |
|
||||
71|| **对内** | 评价确认展示后：①通知 planning 更新计划完成度 ②通知 identity 更新用户标签（例如标记为「已回评用户」）③写入审计日志；免评结果回流：①更新 ASIN 健康与权重变化 ②更新计划完成度 ③通知 planning |
|
||||
72|| **对外接口** | 内部事件发布 |
|
||||
73|| **数据写入** | `review_results` |
|
||||
74|| **依赖** | `PUT /api/plans/{id}/status`（更新计划状态） |
|
||||
75|
|
||||
76|### 2.4 M4: 异常观察队列
|
||||
77|
|
||||
78|| 维度 | 说明 |
|
||||
79|| --- | --- |
|
||||
80|| **对内** | 用户已提交但 Amazon 未展示/暂不可核验的评价，进入异常观察队列；定期复查（例如每天查一次 Amazon 是否已展示）；超过观察期仍未展示→标记异常→通知运营 |
|
||||
81|| **数据写入** | `review_display_checks`（更新状态） |
|
||||
82|| **待确认** | 观察周期多长？复查频率？观察期满后如何处理？ |
|
||||
83|
|
||||
84|---
|
||||
85|
|
||||
86|## 3. 对外 API 契约（草案）
|
||||
87|
|
||||
88|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
89|| --- | --- | --- | --- | --- |
|
||||
90|| 记录评价提交 | `POST /api/reviews/submission` | `{person_id, asin, plan_id, evidence, submitted_at}` | `{submission_id, quota_updated}` | outreach（IM 核验后/客服确认后） |
|
||||
91|| 查询计划评价进度 | `GET /api/reviews/status/{plan_id}` | plan_id | `{total_submissions, verified, pending, completion_rate}` | planning |
|
||||
92|| 查询用户评价历史 | `GET /api/reviews/history/{person_id}` | person_id | `[{submission_id, asin, status, submitted_at}]` | identity（上下文卡） |
|
||||
93|| ASIN 评价统计 | `GET /api/reviews/asin-stats/{asin}` | asin | `{submission_count, verified_count, pending_count}` | planning |
|
||||
94|
|
||||
95|---
|
||||
96|
|
||||
97|## 4. 数据对象
|
||||
98|
|
||||
99|| 对象 | 核心字段 | 说明 |
|
||||
100|| --- | --- | --- |
|
||||
101|| `review_submission_records` | submission_id, person_id, asin, plan_id, evidence_type, evidence, submitted_at, quota_updated | 评价提交记录（核心事实一） |
|
||||
102|| `review_display_checks` | check_id, submission_id, asin, check_method, check_result(DISPLAYED/NOT_DISPLAYED/UNVERIFIABLE), checked_at, retry_count, status(OBSERVING/CONFIRMED/ABNORMAL) | 展示核验记录（核心事实二） |
|
||||
103|| `review_results` | result_id, plan_id, asin, submission_count, verified_count, completion_rate, asin_health_change, updated_at | 评价结果汇总 |
|
||||
104|
|
||||
105|---
|
||||
106|
|
||||
107|## 5. 业务澄清问题清单 — review
|
||||
108|
|
||||
109|### 5.1 评价提交记录（3 项）
|
||||
110|
|
||||
111|| # | 问题 | 优先级 |
|
||||
112|| --- | --- | --- |
|
||||
113|| V-01 | 「用户真实提交评价」的证据形式是什么？（用户上传的截图？Amazon 评论链接？系统自动检测？）不同形式如何验证真伪？ | **P0** |
|
||||
114|| V-02 | 一个用户为同一个 ASIN 提交多条评价（如果 Amazon 允许）——每一条都独立计入累计12额度吗？ | **P0** |
|
||||
115|| V-03 | 评价提交记录是 outreach（IM/客服）写入还是用户直接提交？（系统内提交 vs 系统外提交的区别）系统外提交如何登记？ | P1 |
|
||||
116|
|
||||
117|### 5.2 展示核验（4 项）
|
||||
118|
|
||||
119|| # | 问题 | 优先级 |
|
||||
120|| --- | --- | --- |
|
||||
121|| V-04 | Amazon 评价展示的核验方式是？（定时爬取 Amazon 产品页？SP-API 拉取评价列表？用户上传截图人工审核？混合方式？） | **P0** |
|
||||
122|| V-05 | 如果通过爬取核验——爬取频率？（小时级？天级？）如何识别「哪条评价是本次计划用户提交的」？（靠评论者名字匹配？靠时间窗口？） | **P0** |
|
||||
123|| V-06 | 「暂不可核验」的常见原因有哪些？（Amazon 审核中/延迟展示/被 Amazon 删除？）每种原因的处理策略是否不同？ | P1 |
|
||||
124|| V-07 | 核验失败的兜底机制——如果 Amazon API 不可用或爬取失败，是否允许人工确认？ | P1 |
|
||||
125|
|
||||
126|### 5.3 异常观察队列（2 项）
|
||||
127|
|
||||
128|| # | 问题 | 优先级 |
|
||||
129|| --- | --- | --- |
|
||||
130|| V-08 | 异常观察队列的观察期多长？（1 天？7 天？30 天？）复查频率？（每天？每周？）观察期满后未展示→如何处理？ | P1 |
|
||||
131|| V-09 | 多少条评价进入异常观察算异常阈值？（单计划 10% 未展示→通知？单用户多次未展示→标记？） | P2 |
|
||||
132|
|
||||
133|### 5.4 结果回流（3 项）
|
||||
134|
|
||||
135|| # | 问题 | 优先级 |
|
||||
136|| --- | --- | --- |
|
||||
137|| V-10 | ASIN 健康「回流」的具体动作是什么？（更新 ASIN 评分/评价数到 planning？触发新一轮需求评估？更新 outreach 的触达策略？） | P1 |
|
||||
138|| V-11 | 计划完成度的计算方式——「评价确认展示」即算完成？还是需要确认展示 + 关联到本计划用户？（如何确保那条展示的评价确实是本计划用户的？） | P1 |
|
||||
139|| V-12 | 免评结果的「权重变化」如何量化？（Amazon 不直接提供权重数据——如何通过间接指标判断？） | P2 |
|
||||
140|
|
||||
### 5.5 评价质量管理（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| V-13 | 是否需要评价内容分析？（好评/中评/差评？评价字数？是否含图片/视频？——这些影响评价质量评分？） | P2 |
|
||||
| V-14 | 差评检测和响应——用户提交了差评（1-2 星）是否需要自动触发售后工单？（「差评补救」流程？） | P1 |
|
||||
| V-15 | 虚假评价检测——用户提交的评价是否可能被 Amazon 判定为虚假评价并删除？（系统是否需要内部质量评分来预测被删风险？） | P2 |
|
||||
| V-16 | 评价的 ASIN 匹配校验——用户声称对 ASIN A 提交了评价但实际是对 ASIN B 提交的——如何检测和处理？ | P1 |
|
||||
|
||||
### 5.6 异常观察队列补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| V-17 | 评价提交后 Amazon 展示的预期时间窗口？（通常 24-48h？最长多久？）超出预期窗口后的自动通知？ | P1 |
|
||||
| V-18 | Amazon 删除评价（违反社区准则）vs 用户删除评价 vs 评价被折叠——是否能区分？分别如何处理？ | P2 |
|
||||
| V-19 | 大量评价同时进入异常观察（例如 Amazon 评价系统故障导致全站延迟）——系统如何处理？（自动暂停观察队列？人工干预？） | P2 |
|
||||
|
||||
### 5.7 ASIN 健康回流补充（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| V-20 | ASIN 健康更新的频率？（每次评价确认展示就更新？每天汇总更新一次？） | P2 |
|
||||
| V-21 | 如果多人同时对同一 ASIN 提交了评价，是否对 ASIN 健康有复合影响？（例如 5 条 5 星好评 vs 1 条 1 星差评——权重不同） | P2 |
|
||||
| V-22 | ASIN 健康数据的来源——是 Amazon 直接提供的数据还是系统内部计算？（Amazon 评分 vs 系统追踪到的评价评分可能有差异） | P1 |
|
||||
|
||||
### 5.8 实施层面（2 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| V-23 | 评价展示核验如果是爬取 Amazon 页面——爬取频率和多 ASIN 并行爬取能力？（需要爬取几百个 ASIN 时的时间和资源开销） | P1 |
|
||||
| V-24 | 评价数据是否需要在系统间同步？（outreach 需要知道「用户已提交」→暂停触达；planning 需要知道「评价已确认」→更新计划完成度）数据一致性的保证？ | P1 |
|
||||
187
wishfulfilled-wiki/05_需求文档/08-子系统-KOC-KOL协作.md
Normal file
187
wishfulfilled-wiki/05_需求文档/08-子系统-KOC-KOL协作.md
Normal file
@@ -0,0 +1,187 @@
|
||||
1|# 子系统 08 — KOC/KOL 协作 (`creator`) v1.0
|
||||
2|
|
||||
3|## 子系统概述
|
||||
4|
|
||||
5|| 维度 | 说明 |
|
||||
6|| --- | --- |
|
||||
7|| 代号 | `creator` |
|
||||
8|| 核心职责 | KOC/KOL 匹配筛选、内容 Brief/Code 分配、内容发布跟踪、带货结果跟踪、JOYCOLLAB 数据同步 |
|
||||
9|| 数据所有权 | `exemption_plan_tasks`, `creator_content_records`, `creator_profiles`, `code_records` |
|
||||
10|| 启动依赖 | planning（软依赖，免评计划入口） |
|
||||
11|| 外部系统依赖 | JOYCOLLAB（KOC/KOL 数据、内容数据、Code 使用、带货订单） |
|
||||
12|
|
||||
13|---
|
||||
14|
|
||||
15|## 1. 模块划分
|
||||
16|
|
||||
17|```
|
||||
18|┌─────────────────────────────────────────────────────────────┐
|
||||
19|│ creator 子系统 │
|
||||
20|│ │
|
||||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
22|│ │ M1: KOC/KOL │ │ M2: 内容/Code│ │ M3: 结果跟踪 │ │
|
||||
23|│ │ 匹配筛选 │→│ 管理 │→│ │ │
|
||||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
25|│ │ │ │ │
|
||||
26|│ ▼ ▼ ▼ │
|
||||
27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
28|│ │ M4: JOYCOLLAB│ │ M5: IM/EDM/ │ │ M6: 对外 API │ │
|
||||
29|│ │ 数据同步 │ │ APP 协同 │ │ Gateway │ │
|
||||
30|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
31|│ │
|
||||
32|└─────────────────────────────────────────────────────────────┘
|
||||
33|```
|
||||
34|
|
||||
35|| # | 模块 | 职责 |
|
||||
36|| --- | --- | --- |
|
||||
37|| M1 | KOC/KOL 匹配筛选 | 按国家/平台/粉丝量/产品类目/历史效果筛选匹配合作对象；检查合作对象风险（历史纠纷/违约） |
|
||||
38|| M2 | 内容/Code 管理 | 分配内容 Brief、分配 Code、管理 Code 使用量、素材管理 |
|
||||
39|| M3 | 结果跟踪 | 跟踪内容发布状态、点击/跳转数据、Code 使用量、带货订单、转化销量、权重变化 |
|
||||
40|| M4 | JOYCOLLAB 数据同步 | 从 JOYCOLLAB 拉取 KOC/KOL 数据、内容数据、Code 使用、带货订单；同步失败告警 |
|
||||
41|| M5 | IM/EDM/APP 协同 | KOC 内容二次分发、免评 Code 触达站内用户、活动引流、结果通知 |
|
||||
42|| M6 | 对外 API Gateway | 供 planning、outreach、review 查询 |
|
||||
43|
|
||||
44|---
|
||||
45|
|
||||
46|## 2. 各模块内外说明
|
||||
47|
|
||||
48|### 2.1 M1: KOC/KOL 匹配筛选
|
||||
49|
|
||||
50|| 维度 | 说明 |
|
||||
51|| --- | --- |
|
||||
52|| **对内** | 免评计划进入后：①按国家/平台/粉丝量/历史效果筛选 KOC/KOL ②按产品类目匹配专长 ③检查合作对象风险（历史纠纷/违约）→有风险记录时提示 |
|
||||
53|| **对外接口** | `GET /api/creators/match?plan_id=` — 获取匹配推荐列表 |
|
||||
54|| **数据写入** | `creator_profiles`（从 JOYCOLLAB 同步的 KOC/KOL 画像缓存） |
|
||||
55|| **待确认** | 匹配是完全自动推荐还是运营人工选择？推荐算法依赖哪些权重？ |
|
||||
56|
|
||||
57|### 2.2 M2: 内容/Code 管理
|
||||
58|
|
||||
59|| 维度 | 说明 |
|
||||
60|| --- | --- |
|
||||
61|| **对内** | 分配内容 Brief（产品信息/要求/素材/发布时间）；Code 分配（每个 KOC 独立 Code 还是一对多？）；Code 使用量监控 |
|
||||
62|| **对外接口** | `POST /api/creators/tasks` — 创建协作任务（含 Brief + Code） |
|
||||
63|| **数据写入** | `exemption_plan_tasks`, `code_records` |
|
||||
64|| **待确认** | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 是优惠码还是追踪码？ |
|
||||
65|
|
||||
66|### 2.3 M3: 结果跟踪
|
||||
67|
|
||||
68|| 维度 | 说明 |
|
||||
69|| --- | --- |
|
||||
70|| **对内** | 跟踪 6 组结果：①内容发布状态/链接/互动数据 ②点击/跳转量 ③Code 使用量 ④带货订单数 ⑤转化销量 ⑥Listing 权重变化；执行评估：达标→结果回流 / 未达标→调整策略（更换KOC/调整素材/追加Code） |
|
||||
71|| **对外接口** | `GET /api/creators/results/{plan_id}` — 免评计划执行结果 |
|
||||
72|| **数据写入** | `creator_content_records` |
|
||||
73|| **依赖** | JOYCOLLAB 数据同步 |
|
||||
74|
|
||||
75|### 2.4 M4: JOYCOLLAB 数据同步
|
||||
76|
|
||||
77|| 维度 | 说明 |
|
||||
78|| --- | --- |
|
||||
79|| **对内** | 从 JOYCOLLAB 同步：KOC/KOL 画像数据、内容发布数据、Code 使用数据、带货订单数据；同步记录（时间/成功/失败）；同步失败告警 |
|
||||
80|| **对外接口** | 内部定时任务 |
|
||||
81|| **数据写入** | 本地缓存表（`creator_profiles`, `creator_content_records`） |
|
||||
82|| **待确认** | 同步方向是单向（COLLAB→USER）还是双向？同步频率？ |
|
||||
83|
|
||||
84|### 2.5 M5: IM/EDM/APP 协同
|
||||
85|
|
||||
86|| 维度 | 说明 |
|
||||
87|| --- | --- |
|
||||
88|| **对内** | 4 种协同动作：①KOC 内容二次分发（IM/APP 推送优质内容）②免评 Code 触达（IM/EDM 分发 Code 给站内用户）③活动引流（APP Push 引导用户进入 KOC 内容页）④结果通知（IM/APP 通知用户 Code 到账/订单确认） |
|
||||
89|| **对外接口** | 调用 outreach API：`POST /api/outreach/im/send` 等 |
|
||||
90|| **数据写入** | 协同记录 |
|
||||
91|
|
||||
92|---
|
||||
93|
|
||||
94|## 3. 对外 API 契约（草案）
|
||||
95|
|
||||
96|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
97|| --- | --- | --- | --- | --- |
|
||||
98|| KOC/KOL 匹配推荐 | `GET /api/creators/match?plan_id=` | plan_id | `[{creator_id, score, match_reason}]` | planner 前端 |
|
||||
99|| 创建协作任务 | `POST /api/creators/tasks` | `{creator_id, plan_id, brief, code, deadline}` | `{task_id}` | planner 前端 |
|
||||
100|| 免评执行结果 | `GET /api/creators/results/{plan_id}` | plan_id | `{content, clicks, codes, orders, sales, weight_change}` | review（结果回流）, planning |
|
||||
101|| KOC/KOL 画像查询 | `GET /api/creators/{creator_id}` | creator_id | KOC/KOL 完整画像 | planner 前端 |
|
||||
102|
|
||||
103|---
|
||||
104|
|
||||
105|## 4. 数据对象
|
||||
106|
|
||||
107|| 对象 | 核心字段 | 说明 |
|
||||
108|| --- | --- | --- |
|
||||
109|| `exemption_plan_tasks` | task_id, plan_id, creator_id, brief, code, status, assigned_at, deadline | 免评计划协作任务 |
|
||||
110|| `creator_content_records` | record_id, task_id, creator_id, content_url, publish_time, engagement_data, synced_at | KOC 内容发布记录 |
|
||||
111|| `creator_profiles` | creator_id, name, platform, country, follower_count, category, historical_performance, risk_notes, synced_at | KOC/KOL 画像（从 JOYCOLLAB 同步的本地缓存） |
|
||||
112|| `code_records` | code_id, task_id, code_value, code_type, usage_count, usage_limit, status | Code 记录 |
|
||||
113|
|
||||
114|---
|
||||
115|
|
||||
116|## 5. 业务澄清问题清单 — creator
|
||||
117|
|
||||
118|### 5.1 JOYCOLLAB 对接（4 项）
|
||||
119|
|
||||
120|| # | 问题 | 优先级 |
|
||||
121|| --- | --- | --- |
|
||||
122|| K-01 | JOYCOLLAB 中 KOC/KOL 的完整数据字段有哪些？（平台/粉丝量/国家/类目/历史合作效果/历史纠纷/违约——文档部分列出，需确认完整字段清单和 API 可用性） | **P0** |
|
||||
123|| K-02 | 数据同步方向是单向（COLLAB→USER）还是双向？（USER 分配的 Brief/Code 是否需要回写到 COLLAB？） | **P0** |
|
||||
124|| K-03 | 同步频率？（实时 Webhook？每小时？每天？）同步失败时谁来处理？重试策略？ | P1 |
|
||||
125|| K-04 | JOYCOLLAB 是否有现成 API？是 REST API 还是需要开发新的同步接口？ | P1 |
|
||||
126|
|
||||
127|### 5.2 KOC/KOL 匹配（3 项）
|
||||
128|
|
||||
129|| # | 问题 | 优先级 |
|
||||
130|| --- | --- | --- |
|
||||
131|| K-05 | 匹配是运营人工选择还是系统自动推荐？推荐算法的权重？（粉丝量 vs 历史效果 vs 类目匹配 vs 报价？） | P1 |
|
||||
132|| K-06 | KOC/KOL 是否有评级/分层体系？（头部/腰部/尾部？）不同层级对应的计划类型是否不同？ | P1 |
|
||||
133|| K-07 | 「合作对象风险（历史纠纷/违约）」——风险数据从哪里来？（JOYCOLLAB？人工标记？）什么程度的风险需要拦截？ | P1 |
|
||||
134|
|
||||
135|### 5.3 Code 与内容（3 项）
|
||||
136|
|
||||
137|| # | 问题 | 优先级 |
|
||||
138|| --- | --- | --- |
|
||||
139|| K-08 | Code 是 JOYCOLLAB 生成还是 USER 系统生成？Code 类型？（优惠码/追踪码/专属链接？）一对一还是可以多人共用？ | P1 |
|
||||
140|| K-09 | KOC 发布的内容是否需要审核？（Brief 交付后→KOC 创作→审核→发布？）审核流程在哪个系统？ | P2 |
|
||||
141|| K-10 | KOC 内容二次分发到 IM/APP——分发策略是什么？（所有优质内容都分发？按产品/地区筛选？） | P2 |
|
||||
142|
|
||||
143|### 5.4 财务结算（2 项）
|
||||
144|
|
||||
145|| # | 问题 | 优先级 |
|
||||
146|| --- | --- | --- |
|
||||
147|| K-11 | KOC/KOL 的提成/返点结算在哪个系统执行？（JOYCOLLAB？财务系统？还是 USER 内触发结算指令？）USER 的责任边界？ | P1 |
|
||||
148|| K-12 | 结算数据（提成计算/返点核算/提款记录）是否需要同步到 USER？权限控制（财务数据独立权限）？ | P2 |
|
||||
149|
|
||||
### 5.5 KOC/KOL 分层与定价（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| K-13 | KOC/KOL 是否有分层体系？（头部/腰部/尾部——按粉丝量划分？按历史带货效果划分？）不同分层的合作价格和权益？ | P1 |
|
||||
| K-14 | KOC/KOL 的报价/定价数据是否在系统中维护？（用于预算计算和 ROI 分析？） | P2 |
|
||||
| K-15 | KOC/KOL 是否有签约/合同管理？排他性协议？（签约期内只能推广本品牌产品？）排他性信息是否需要系统记录？ | P2 |
|
||||
|
||||
### 5.6 内容与权益管理（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| K-16 | KOC/KOL 发布内容的使用权和授权期限？（品牌是否可以二次使用、广告投放、修改？授权条款在系统中管理还是走线下合同？） | P2 |
|
||||
| K-17 | 内容审核流程——KOC/KOL 创作的内容是否需要品牌方审核后才能发布？（审核不通过→修改→重新审核的流程？） | P1 |
|
||||
| K-18 | 内容效果评估——除了点击/Code/订单数据外，是否需要评估内容质量？（互动率、完播率、正向评论比例？） | P2 |
|
||||
|
||||
### 5.7 多平台 KOC/KOL 管理（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| K-19 | KOC/KOL 涉及哪些平台？（YouTube / TikTok / Instagram / Facebook / 博客 / Amazon 站内 Influencer Program？）每个平台的数据来源？ | P1 |
|
||||
| K-20 | 同一 KOC/KOL 在多个平台有账号——是否在系统中关联为同一个人？（类似 identity 的归并逻辑？） | P2 |
|
||||
| K-21 | 不同平台的内容格式和指标不同（YouTube 视频 vs Instagram 帖子 vs TikTok 短视频）——结果跟踪如何统一？ | P2 |
|
||||
|
||||
### 5.8 Code 管理补充（2 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| K-22 | Code 的类型？（一次性折扣码 / 多次使用码 / 追踪链接 / 专属落地页？）不同类型的生成和追踪逻辑？ | P1 |
|
||||
| K-23 | Code 的有效期管理？（计划结束后 Code 自动失效？还是保留一段时间？）Code 是否可重复使用？ | P1 |
|
||||
|
||||
### 5.9 实施层面（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| K-24 | JOYCOLLAB 数据同步失败时的降级策略？（用本地缓存数据？标记为「数据可能过期」？暂停新的协作任务？） | P1 |
|
||||
| K-25 | KOC/KOL 匹配算法的性能——如果 JOYCOLLAB 有几千个 KOC，匹配需要多少时间？是否有预筛选+精排的两阶段设计？ | P2 |
|
||||
| K-26 | KOC/KOL 的任务状态如何与 planning 的计划状态联动？（协作任务完成→计划完成度增加→计划状态更新？） | P1 |
|
||||
186
wishfulfilled-wiki/05_需求文档/09-子系统-审计与通知中心.md
Normal file
186
wishfulfilled-wiki/05_需求文档/09-子系统-审计与通知中心.md
Normal file
@@ -0,0 +1,186 @@
|
||||
1|# 子系统 09 — 审计与通知中心 (`audit`) v1.0
|
||||
2|
|
||||
3|## 子系统概述
|
||||
4|
|
||||
5|| 维度 | 说明 |
|
||||
6|| --- | --- |
|
||||
7|| 代号 | `audit` |
|
||||
8|| 核心职责 | 状态变更审计、敏感字段访问日志、多类型通知/告警 |
|
||||
9|| 数据所有权 | `interaction_audit_logs`, `notification_records`, `manual_review_tasks` |
|
||||
10|| 启动依赖 | 无硬依赖，完全独立 |
|
||||
11|| 外部系统依赖 | 通知可能通过 IM/EDM/APP Push 等通道（可复用 outreach 通道或独立） |
|
||||
12|
|
||||
13|---
|
||||
14|
|
||||
15|## 1. 模块划分
|
||||
16|
|
||||
17|```
|
||||
18|┌─────────────────────────────────────────────────────────────┐
|
||||
19|│ audit 子系统 │
|
||||
20|│ │
|
||||
21|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
22|│ │ M1: 状态变更 │ │ M2: 敏感操作 │ │ M3: 通知分发 │ │
|
||||
23|│ │ 审计 │ │ 审计 │ │ 引擎 │ │
|
||||
24|│ └──────┬───────┘ └──────┬───────┘ └──────┬───────┘ │
|
||||
25|│ │ │ │ │
|
||||
26|│ ▼ ▼ ▼ │
|
||||
27|│ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │
|
||||
28|│ │ M4: 通知模板 │ │ M5: 人工复核 │ │ M6: 对外 API │ │
|
||||
29|│ │ 管理 │ │ 任务 │ │ Gateway │ │
|
||||
30|│ └──────────────┘ └──────────────┘ └──────────────┘ │
|
||||
31|│ │
|
||||
32|└─────────────────────────────────────────────────────────────┘
|
||||
33|```
|
||||
34|
|
||||
35|| # | 模块 | 职责 |
|
||||
36|| --- | --- | --- |
|
||||
37|| M1 | 状态变更审计 | 记录所有业务对象的状态流转（对象ID/旧状态/新状态/操作人/时间/原因） |
|
||||
38|| M2 | 敏感操作审计 | 敏感字段访问记录、数据导出记录、人工复核操作留痕 |
|
||||
39|| M3 | 通知分发引擎 | 按通知类型路由到不同通道（系统内通知/IM/EDM/APP Push）；通知优先级管理 |
|
||||
40|| M4 | 通知模板管理 | 各类通知的模板（额度预警/Listing 预警/超时提醒/审批通知/风险告警） |
|
||||
41|| M5 | 人工复核任务 | 管理需要人工复核的任务（弱关联风险/额度预警池/异常评价），供风险/运营人员消费 |
|
||||
42|| M6 | 对外 API Gateway | 接收所有子系统上报的审计事件和通知请求 |
|
||||
43|
|
||||
44|---
|
||||
45|
|
||||
46|## 2. 各模块内外说明
|
||||
47|
|
||||
48|### 2.1 M1: 状态变更审计
|
||||
49|
|
||||
50|| 维度 | 说明 |
|
||||
51|| --- | --- |
|
||||
52|| **对内** | 接收所有子系统的状态变更事件（fire-and-forget）；记录：对象类型（plan/ticket/risk_case/review…）、对象ID、旧状态、新状态、操作人、操作时间、操作原因；审计日志不可篡改（append-only）；支持按对象ID/操作人/时间范围检索 |
|
||||
53|| **对外接口** | `POST /api/audit/event` — 上报审计事件 |
|
||||
54|| **数据写入** | `interaction_audit_logs` |
|
||||
55|| **典型事件** | 计划状态变更（草稿→审批→执行→完成）、工单分配/关闭、风险事件确认/排除、额度手动调整、审批决策 |
|
||||
56|
|
||||
57|### 2.2 M2: 敏感操作审计
|
||||
58|
|
||||
59|| 维度 | 说明 |
|
||||
60|| --- | --- |
|
||||
61|| **对内** | 三类敏感操作：①敏感字段访问（用户上下文卡中的涉密字段→记录访问人/时间/字段/上下文）②数据导出操作（导出人/时间/范围/原因/是否含敏感字段）③人工复核操作（决策人/决策内容/决策依据/时间） |
|
||||
62|| **对外接口** | `POST /api/audit/sensitive-access` — 上报敏感访问 |
|
||||
63|| **数据写入** | `interaction_audit_logs`（带 sensitivity 标记） |
|
||||
64|
|
||||
65|### 2.3 M3: 通知分发引擎
|
||||
66|
|
||||
67|| 维度 | 说明 |
|
||||
68|| --- | --- |
|
||||
69|| **对内** | 接收通知请求→按通知类型路由：①系统内通知（Web 前端轮询/WebSocket）②IM 通知（通过 outreach）③EDM 通知 ④APP Push；优先级管理（紧急 Listing 预警 > 超时提醒 > 额度预警）；通知去重（同一用户同一类型短时间内不重复发） |
|
||||
70|| **对外接口** | `POST /api/notifications/send` — 发送通知 |
|
||||
71|| **依赖** | outreach（IM/EDM/APP Push 通道） |
|
||||
72|
|
||||
73|### 2.4 M4: 通知模板管理
|
||||
74|
|
||||
75|| 维度 | 说明 |
|
||||
76|| --- | --- |
|
||||
77|| **对内** | 通知类型与模板：①额度预警（「真实人 X 的测评额度仅剩 1 次」）②紧急 Listing 预警（「ASIN X 评分接近 4.2，建议紧急催评」）③客服超时提醒（「工单 #123 已超时 N 小时未回复」）④审批通知（「计划 X 等待您的审批」）⑤规则风控提醒（「ASIN X 频控过高」）⑥风险告警（「用户 X 命中强关联风险」） |
|
||||
78|| **对外接口** | 管理 API |
|
||||
79|| **数据写入** | `notification_records` |
|
||||
80|| **待确认** | 模板是否需要多语言（中文/英文/菲律宾语）？模板管理界面在 audit 内部还是独立？ |
|
||||
81|
|
||||
82|### 2.5 M5: 人工复核任务
|
||||
83|
|
||||
84|| 维度 | 说明 |
|
||||
85|| --- | --- |
|
||||
86|| **对内** | 统一管理需人工复核的任务：弱关联风险复核、额度预警池复核、异常评价复核、诈骗疑似复核；任务分配/认领/完成/超时 |
|
||||
87|| **对外接口** | `POST /api/audit/review-task` — 创建复核任务；`GET /api/audit/review-tasks?assignee=` — 查询待复核任务 |
|
||||
88|| **数据写入** | `manual_review_tasks` |
|
||||
89|
|
||||
90|---
|
||||
91|
|
||||
92|## 3. 对外 API 契约（草案）
|
||||
93|
|
||||
94|| 接口 | 方法 | 输入 | 输出 | 消费者 |
|
||||
95|| --- | --- | --- | --- | --- |
|
||||
96|| 上报审计事件 | `POST /api/audit/event` | `{object_type, object_id, old_status, new_status, operator, reason}` | `{event_id}` | 所有子系统（状态变更时调用） |
|
||||
97|| 上报敏感访问 | `POST /api/audit/sensitive-access` | `{operator, field, context, accessed_at}` | `{event_id}` | identity（上下文卡访问） |
|
||||
98|| 发送通知 | `POST /api/notifications/send` | `{recipient, type, template_id, params}` | `{notification_id}` | 所有子系统 |
|
||||
99|| 创建复核任务 | `POST /api/audit/review-task` | `{task_type, target_id, priority, description}` | `{task_id}` | risk, quota |
|
||||
100|
|
||||
101|---
|
||||
102|
|
||||
103|## 4. 数据对象
|
||||
104|
|
||||
105|| 对象 | 核心字段 | 说明 |
|
||||
106|| --- | --- | --- |
|
||||
107|| `interaction_audit_logs` | log_id, object_type, object_id, old_status, new_status, operator, operation, reason, sensitivity_level, logged_at | 审计日志（append-only） |
|
||||
108|| `notification_records` | notification_id, recipient, type, template_id, channel, sent_at, status(SENT/DELIVERED/READ/FAILED) | 通知记录 |
|
||||
109|| `manual_review_tasks` | task_id, task_type, target_id, status(PENDING/ASSIGNED/IN_REVIEW/RESOLVED/TIMEOUT), assignee, priority, created_at, resolved_at | 人工复核任务 |
|
||||
110|
|
||||
111|---
|
||||
112|
|
||||
113|## 5. 业务澄清问题清单 — audit
|
||||
114|
|
||||
115|### 5.1 审计范围与保留（4 项）
|
||||
116|
|
||||
117|| # | 问题 | 优先级 |
|
||||
118|| --- | --- | --- |
|
||||
119|| A-01 | 审计日志的保留策略？（保留多久？1 年？永久？到期后归档还是删除？） | **P0** |
|
||||
120|| A-02 | 审计日志的存储量预估？（日产生多少条？是否需要分库分表/冷热分离？） | P1 |
|
||||
121|| A-03 | 审计日志是否需要支持导出/报表？（合规审计时需要导出给外部审计？） | P1 |
|
||||
122|| A-04 | 「敏感字段」的定义范围？（订单号、收款信息、设备号——还有哪些？谁来确定完整清单？） | **P0** |
|
||||
123|
|
||||
124|### 5.2 通知策略（4 项）
|
||||
125|
|
||||
126|| # | 问题 | 优先级 |
|
||||
127|| --- | --- | --- |
|
||||
128|| A-05 | 通知发送通道的优先级？（紧急告警用什么通道？IM？系统内通知？邮件？） | P1 |
|
||||
129|| A-06 | 通知去重规则？（同一用户同一类型通知 N 分钟内不重复发？） | P1 |
|
||||
130|| A-07 | 通知是否需要用户偏好设置？（用户可以选择不接收某类通知？公告类通知是否强制发送？） | P2 |
|
||||
131|| A-08 | 通知模板是否需要多语言支持？（中文/英文/菲律宾语？）模板由谁来维护？ | P2 |
|
||||
132|
|
||||
133|### 5.3 人工复核任务（2 项）
|
||||
134|
|
||||
135|| # | 问题 | 优先级 |
|
||||
136|| --- | --- | --- |
|
||||
137|| A-09 | 人工复核任务的时效要求？（不同任务类型 SLA？弱关联风险 N 小时内复核？额度预警池 N 分钟内复核？） | P1 |
|
||||
138|| A-10 | 复核任务超时后的升级机制？（自动分配给上级？通知主管？） | P2 |
|
||||
139|
|
||||
140|### 5.4 与其他子系统的协作（2 项）
|
||||
141|
|
||||
142|| # | 问题 | 优先级 |
|
||||
143|| --- | --- | --- |
|
||||
144|| A-11 | 通知通道是否完全复用 outreach？（IM/EDM/APP Push）还是 audit 独立对接通知通道？（如果 outreach 不可用，audit 仍需要能发告警） | P1 |
|
||||
145|| A-12 | 审计事件是同步上报还是异步？（同步→影响业务链路性能 / 异步→可能丢失事件） | P1 |
|
||||
146|
|
||||
### 5.5 合规与认证（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| A-13 | 系统是否需要通过合规认证？（SOC2 Type II / ISO 27001？）认证对审计日志的完整性、不可篡改性、保留期限有何具体要求？ | P1 |
|
||||
| A-14 | 数据导出请求（DSR）——用户或监管机构要求导出所有个人数据时，系统如何响应？（需要哪些子系统的数据？导出格式？响应时限？） | P1 |
|
||||
| A-15 | 审计日志是否需要对第三方审计开放？（外部审计师需要查看审计日志时——权限控制和数据脱敏？） | P2 |
|
||||
|
||||
### 5.6 日志保留与归档（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| A-16 | 审计日志的分级保留策略？（状态变更日志保留 X 年 / 敏感访问日志保留 Y 年 / 通知记录保留 Z 月？） | P1 |
|
||||
| A-17 | 日志归档方案？（超过保留期的日志是删除还是归档到冷存储？归档后是否仍可检索？） | P2 |
|
||||
| A-18 | 日志存储量预估？（日产生日志条数 × 保留天数 = 需要的存储空间——是否需要分库分表/分区？） | P2 |
|
||||
|
||||
### 5.7 敏感数据脱敏（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| A-19 | 审计日志中是否允许记录敏感字段的明文？（例如「谁在何时查看了用户 X 的收款信息」——收款信息是否脱敏存储？） | P1 |
|
||||
| A-20 | 日志查询权限——谁可以查审计日志？（管理员？审计员？）是否需要限制只能查自己相关的日志？ | P1 |
|
||||
| A-21 | 生产环境的日志是否可以包含 PII（个人可识别信息）？（邮箱/电话/地址——是否在写入日志时自动脱敏？） | P1 |
|
||||
|
||||
### 5.8 通知可靠性（3 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| A-22 | 通知的可靠性保证——紧急告警（如 Listing 评分暴跌）是否需要确保送达？（有送达确认机制吗？发送失败后重试？） | P1 |
|
||||
| A-23 | 通知通道的优先级切换——IM 通知失败后是否自动切换到 EDM 或系统通知？ | P2 |
|
||||
| A-24 | 通知的聚合/摘要——同一个用户短时间收到多条同类通知是否合并？（「您有 3 个待审批计划」而不是 3 条独立通知） | P2 |
|
||||
|
||||
### 5.9 实施层面（4 项）
|
||||
|
||||
| # | 问题 | 优先级 |
|
||||
| --- | --- | --- |
|
||||
| A-25 | 审计事件是同步写入还是异步写入？（同步→影响业务链路 RT / 异步→可能丢失事件——如何取舍？） | P1 |
|
||||
| A-26 | 审计日志的查询性能——是否需要支持全文搜索？（按操作人/对象ID/时间范围检索是否需要在秒级返回？） | P2 |
|
||||
| A-27 | 通知通道的可靠性——如果 audit 子系统本身宕机，其他子系统的通知请求是否丢失？（是否需要消息队列做缓冲？） | P1 |
|
||||
| A-28 | audit 子系统是否需要独立的数据库？（与其他子系统共享数据库会在高峰期互相影响——是否独立部署数据库？） | P2 |
|
||||
3298
wishfulfilled-wiki/05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html
Normal file
3298
wishfulfilled-wiki/05_需求文档/20260504_USER后台ERP_MVP管理员首页高保真原型_v7.html
Normal file
File diff suppressed because it is too large
Load Diff
@@ -0,0 +1,995 @@
|
||||
# USER 评价业务闭环 — 共用能力图与渠道专属流程 v2.2
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 当前版本：`v2.2`
|
||||
- 最近更新：`2026-05-17`
|
||||
- 上游基线：[工作基线 v1.2](20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md)
|
||||
- 前一版本：
|
||||
- `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v1.1.md`
|
||||
- `20260517_USER评价业务闭环点击操作模拟_v2.1.md`
|
||||
- 文件目的：在基线 v1.2 确认的额度规则和真实人体系上，拆出系统级共用能力图与 IM / EDM / APP / TEL / 客服 / KOC-KOL 六条渠道的专属执行流程，每个节点标注 查 / 写 / 状态 / 提醒 / 拦截。
|
||||
- 资料依据：IM 推送业务流脑图、电话业务流程知识库、客服相关模块、后台回评工作流对接事项、状态机 v4、页面设计 v4、原型 HTML。
|
||||
- 使用方式：先读基线 v1.2，再读本文件；第三步数据流设计直接引用本文件的节点规则表和数据对象建议。本文件取代 `v1.1` 与 `v2.1` 作为当前第二步主稿。
|
||||
|
||||
---
|
||||
|
||||
### 1. 总览
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["销售 / ASIN数据形成"] --> B["需求触发"]
|
||||
B --> C["用户运营评估"]
|
||||
C --> D{"计划类型"}
|
||||
D --> E["评价型计划<br/>推新 / 回评"]
|
||||
D --> F["免评计划"]
|
||||
E --> G["执行拆解"]
|
||||
F --> G
|
||||
G --> SHARED["共用能力层"]
|
||||
SHARED --> I1["IM"]
|
||||
SHARED --> I2["EDM"]
|
||||
SHARED --> I3["APP"]
|
||||
SHARED --> I4["TEL"]
|
||||
SHARED --> I5["客服"]
|
||||
SHARED --> I6["KOC / KOL"]
|
||||
I1 & I2 & I3 & I4 & I5 --> J["用户互动 / 服务 / 跟进"]
|
||||
J --> K["用户真实提交评价"]
|
||||
K --> L["计入累计评价额度（12）"]
|
||||
L --> M["Amazon展示确认"]
|
||||
M --> N["ASIN / 计划 / 用户 / 风险结果回流"]
|
||||
I6 --> O["免评结果跟踪"]
|
||||
O --> N
|
||||
N --> C
|
||||
|
||||
style SHARED fill:#f5f5f5,stroke:#333,stroke-width:3px
|
||||
```
|
||||
|
||||
#### 节点审查标准
|
||||
|
||||
每个关键节点按以下 8 问审：
|
||||
|
||||
| ## | 问题 | 标注 |
|
||||
| --- | --- | --- |
|
||||
| 1 | 入口是什么 | 触发条件 |
|
||||
| 2 | 先查什么 | **查** |
|
||||
| 3 | 判断什么 | 分岔条件 |
|
||||
| 4 | 写什么 | **写** |
|
||||
| 5 | 状态怎么变 | **状态** |
|
||||
| 6 | 何时提醒 | **提醒** |
|
||||
| 7 | 何时拦截 | **拦截** |
|
||||
| 8 | 何时转人工 | **转人工** |
|
||||
|
||||
---
|
||||
|
||||
## 第一部分：共用能力图
|
||||
|
||||
### 2. 共用能力一：真实人识别与用户上下文卡
|
||||
|
||||
#### 2.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["新互动 / 新订单 / 新任务"] --> B["读取身份线索"]
|
||||
B --> B1["JOYHUB ID"]
|
||||
B --> B2["邮箱"]
|
||||
B --> B3["电话"]
|
||||
B --> B4["设备号"]
|
||||
B --> B5["订单号"]
|
||||
B --> B6["姓名 + 地址"]
|
||||
|
||||
B1 & B2 & B3 & B4 & B5 & B6 --> C["归并真实人"]
|
||||
C --> D{"匹配结果"}
|
||||
D -->|"标准化姓名+地址一致"| E["强关联 → 同一真实人"]
|
||||
D -->|"地址一致姓名不同"| F["家庭/关联风险 → 不直接合并"]
|
||||
D -->|"多线索交叉"| G["按设备/电话/邮箱/收款信息权重合并"]
|
||||
|
||||
E & F & G --> H["生成 / 更新真实人 ID"]
|
||||
H --> I["拉取用户上下文卡"]
|
||||
|
||||
I --> J["历史交易<br/>订单/购买/退款/返款/ASIN"]
|
||||
I --> K["历史服务<br/>工单/聊天/电话/承诺/提醒"]
|
||||
I --> L["历史风险<br/>黑名单/诈骗/关联/异常"]
|
||||
I --> M["当前设备<br/>型号/版本/换机记录"]
|
||||
I --> N["触达历史<br/>IM/EDM/APP/TEL 近期记录"]
|
||||
|
||||
J & K & L & M & N --> O["上下文卡快照 → 供客服/运营/风险使用"]
|
||||
```
|
||||
|
||||
#### 2.2 用户上下文卡字段组
|
||||
|
||||
| 字段组 | 具体内容 |
|
||||
| --- | --- |
|
||||
| 当前身份 | JOYHUB ID、邮箱、电话、当前订单、真实人 ID |
|
||||
| 真实人归并 | 姓名+地址（标准化）、设备号、电话、邮箱、Profile ID、收款信息、关联账号列表 |
|
||||
| 历史交易 | 历史订单、购买频次、最近购买、历史退款、历史返款、目标 ASIN 购买记录 |
|
||||
| 历史服务 | 历史工单、聊天记录、通话记录、已承诺事项、已发送提醒、工单关闭原因 |
|
||||
| 历史风险 | 黑名单标记、强关联记录、弱关联记录、疑似诈骗、双重退款、异常订单 |
|
||||
| 当前设备 | 设备号摘要、设备型号/类型、系统版本、APP 版本、最近设备变化（换机/多设备） |
|
||||
| 触达历史 | IM 最近触达/回复/退订、EDM 最近打开/点击/退订、APP 最近 Push、TEL 最近拨打 |
|
||||
|
||||
#### 2.3 节点规则
|
||||
|
||||
| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 归并真实人 | JOYHUB、邮箱、电话、设备、订单、地址 | 真实人匹配结果、匹配证据、置信度 | 新真实人 / 已存在 | 标准化姓名+地址一致时强提示 | - |
|
||||
| 拉取上下文卡 | 交易、工单、风险、设备、触达全量记录 | 上下文快照（含快照时间） | 首次生成 / 增量更新 | 命中黑名单/异常时高亮 | 严重风险标记时阻止自动通过 |
|
||||
| 设备变化识别 | 设备号、型号、系统版本、APP版本 | 设备变化记录、变化时间 | 设备正常 / 近期换机 / 多设备 | 近期换机或同设备多账号提示 | - |
|
||||
|
||||
---
|
||||
|
||||
### 3. 共用能力二：人群生成与画像拆解
|
||||
|
||||
#### 3.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["计划进入人群生成"] --> B["基础过滤"]
|
||||
B --> B1["硬排除：国家/站点/可达性/退订/黑名单/未关闭工单"]
|
||||
|
||||
B1 --> C["画像匹配"]
|
||||
C --> C1["基础画像：国家/语言/性别/年龄段/注册时间"]
|
||||
C --> C2["产品关系：绑定玩具/绑定数量/绑定品类/目标产品"]
|
||||
C --> C3["交易画像：历史订单/购买频次/是否买过目标ASIN"]
|
||||
C --> C4["行为画像：活跃度/打开率/点击率/历史回评率/配合率"]
|
||||
C --> C5["触达画像：各渠道可达性/最近触达/退订"]
|
||||
C --> C6["风险画像：黑名单/设备关联/地址关联/退款异常"]
|
||||
C --> C7["计划画像：是否参加过推新/回评/免评/最近结果"]
|
||||
|
||||
C1 & C2 & C3 & C4 & C5 & C6 & C7 --> D["历史行为评分"]
|
||||
|
||||
D --> E["额度与频控校验<br/>（进入 §4 共用能力三）"]
|
||||
E --> F["风险复检<br/>（进入 §6 共用能力五）"]
|
||||
F --> G["生成候选人群快照 + 排除快照"]
|
||||
```
|
||||
|
||||
#### 3.2 画像字段的三类用途
|
||||
|
||||
| 类型 | 作用 | 示例字段 |
|
||||
| --- | --- | --- |
|
||||
| **硬过滤** | 决定能不能进池 | 国家、可达性、黑名单、退订、未关闭工单、额度超限 |
|
||||
| **匹配条件** | 决定是否适合当前计划 | 绑定玩具、目标品类、年龄、性别、是否买过目标 ASIN |
|
||||
| **排序权重** | 决定触达优先级 | 活跃度、历史回评率、历史配合率、最近互动时间 |
|
||||
|
||||
#### 3.3 节点规则
|
||||
|
||||
| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 基础过滤 | 国家、站点、可达性、退订、黑名单、未关闭工单 | 排除原因记录 | 入池 / 排除 | - | 黑名单/退订/强关联直接排除 |
|
||||
| 画像匹配 | 7 组画像字段 | 匹配分组与得分 | 匹配 / 不匹配 / 待补全 | 画像缺失可补全 | - |
|
||||
| 历史行为评分 | 活跃、点击、回复、回评率、配合率、投诉 | 评分结果、排序权重 | 高分 / 中分 / 低分 | 低活跃用户降级提醒 | - |
|
||||
| 生成快照 | 过滤、匹配、评分、额度、风险全量结果 | 人群快照、排除快照、快照时间 | 已生成 | 排除比例异常时提醒 | 快照为空时拦截 |
|
||||
|
||||
---
|
||||
|
||||
### 4. 共用能力三：额度台账与频控控制
|
||||
|
||||
#### 4.1 已确认额度规则
|
||||
|
||||
| 规则 | 统计对象 | 计数口径 | 计数时点 |
|
||||
| --- | --- | --- | --- |
|
||||
| 每月测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |
|
||||
| 每月免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 | - |
|
||||
| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 | 用户真实提交评价时 |
|
||||
|
||||
#### 4.2 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["识别真实人"] --> B["读取额度台账"]
|
||||
B --> B1["本月测评：已完成 / 进行中 / 已预占"]
|
||||
B --> B2["本月免评：已完成 / 进行中 / 已预占"]
|
||||
B --> B3["累计真实提交：当前 / 上限 12"]
|
||||
B --> B4["并发占用：跨计划重复入选检测"]
|
||||
|
||||
B1 & B2 & B3 & B4 --> C{"额度判断"}
|
||||
C -->|"剩余 ≥ 本次拟发送"| D["进入普通候选池<br/>→ 预占额度"]
|
||||
C -->|"剩余不足但 > 0"| E["进入预警池<br/>→ 预占额度 → 发送前人工复核"]
|
||||
C -->|"已用 + 预占 + 本次 ≥ 上限"| F["排除自动推送"]
|
||||
|
||||
D --> G["写入预占记录"]
|
||||
E --> G
|
||||
|
||||
G --> H["频控复核"]
|
||||
H --> H1["渠道频控：IM/EDM/APP/TEL 最近触达间隔"]
|
||||
H --> H2["单 ASIN 短期触达次数"]
|
||||
H --> H3["用户反感度/投诉/退订状态"]
|
||||
|
||||
H1 & H2 & H3 --> I{"频控判断"}
|
||||
I -->|通过| J["进入发送队列"]
|
||||
I -->|不通过| K["延后 / 降频 / 排除"]
|
||||
|
||||
J --> L["发送前再次读取最新额度 + 风险"]
|
||||
L --> M{"最终校验"}
|
||||
M -->|通过| N["发送"]
|
||||
M -->|新增超限/风险| O["撤出本批次"]
|
||||
```
|
||||
|
||||
#### 4.3 额度 vs 频控的区别
|
||||
|
||||
| 类别 | 统计维度 | 周期 | 拦截时机 |
|
||||
| --- | --- | --- | --- |
|
||||
| **渠道频控** | 单渠道触达次数/间隔 | 按日/周/月 | 发送前 |
|
||||
| **月度业务额度** | 真实人测评 4 / 免评 4 | 自然月 | 人群生成 + 发送前 |
|
||||
| **累计评价额度** | 真实人累计 12 | 永久累计 | 用户提交评价时更新、下次人群生成时判断 |
|
||||
| **并发占用控制** | 进行中 + 已预占 + 跨计划重复 | 实时 | 人群生成 + 预占时 |
|
||||
|
||||
#### 4.4 节点规则
|
||||
|
||||
| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 读取额度台账 | 本月测评/免评、累计提交、进行中、已预占 | 当前额度快照 | - | 剩余 ≤ 1 或本批次将打满时预警 | - |
|
||||
| 预占额度 | 候选计划、预计发送量、当前剩余 | 额度预占记录 | 已预占 | - | 预计超限阻止进入自动发送 |
|
||||
| 频控复核 | IM/EDM/APP/TEL 最近触达、ASIN频次、退订/投诉 | 频控校验结果 | 通过 / 降频 / 排除 | 接近频控上限时提醒 | 超频直接排除 |
|
||||
| 发送前终校 | 最新额度、最新风险、最新未关闭工单 | 发送前校验结果 | 准入 / 撤出 | 任何新增异常立即提示 | 新增超限/风险撤出本批次 |
|
||||
|
||||
---
|
||||
|
||||
### 5. 共用能力四：每次有效互动复检
|
||||
|
||||
#### 5.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["触发复检的事件"] --> A1["主动推送后回复"]
|
||||
A --> A2["再次联系"]
|
||||
A --> A3["补充订单号"]
|
||||
A --> A4["客服回访"]
|
||||
A --> A5["电话来电"]
|
||||
A --> A6["退款/返款/继续推送前"]
|
||||
|
||||
A1 & A2 & A3 & A4 & A5 & A6 --> X["重新读取四组数据"]
|
||||
|
||||
X --> X1["身份：真实人/JOYHUB/邮箱/电话/设备/订单/地址"]
|
||||
X --> X2["历史：订单/工单/触达/退款/返款"]
|
||||
X --> X3["额度：本月测评/免评/累计提交/进行中/预占"]
|
||||
X --> X4["风险：黑名单/强弱关联/双重退款/异常订单"]
|
||||
|
||||
X1 & X2 & X3 & X4 --> Y{"判断结果"}
|
||||
Y -->|正常 + 额度充足| Z["继续业务"]
|
||||
Y -->|弱风险 / 接近额度上限| W["继续但显著提示 → 人工关注"]
|
||||
Y -->|强风险 / 额度超限| V["暂停当前动作 → 转风险中心或人工复核"]
|
||||
```
|
||||
|
||||
#### 5.2 节点规则
|
||||
|
||||
| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 身份复检 | JOYHUB、邮箱、电话、设备、订单、地址是否变化 | 身份变化记录 | 未变 / 新增关联 / 冲突 | 设备变化/地址变化提示 | - |
|
||||
| 历史复检 | 是否有新订单、新工单、新触达、新退款 | 历史变化记录 | 无变化 / 有更新 | 新退款/新工单提示 | - |
|
||||
| 额度复检 | 最新测评/免评/累计额度 | 最新额度快照 | 充足 / 预警 / 超限 | 接近上限预警 | 超限拦截 |
|
||||
| 风险复检 | 黑名单、强弱关联、双重退款、异常 | 最新风险结果 | 正常 / 弱风险 / 强风险 | 任何命中高亮提醒 | 强关联暂停自动操作 |
|
||||
|
||||
---
|
||||
|
||||
### 6. 共用能力五：风险判断与黑名单
|
||||
|
||||
#### 6.1 风险分层
|
||||
|
||||
| 风险类型 | 关联项 | 处理原则 |
|
||||
| --- | --- | --- |
|
||||
| **强关联** | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，直接进入高风险或黑名单链路 |
|
||||
| **弱关联** | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察 + 人工复核，不直接认定诈骗 |
|
||||
|
||||
#### 6.2 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["风险信号进入<br/>（新订单同步/触达回应/用户接入/退款申请/再次跟进）"] --> B["强弱关联判断"]
|
||||
|
||||
B --> C{"关联等级"}
|
||||
C -->|强关联| D["高风险 / 黑名单链路"]
|
||||
C -->|弱关联| E["高风险观察 + 人工复核"]
|
||||
C -->|无关联| F["正常继续"]
|
||||
|
||||
D --> D1["拦截继续推送"]
|
||||
D --> D2["拦截自动退款"]
|
||||
D --> D3["拦截自动放行"]
|
||||
D1 & D2 & D3 --> G["回写工单 / 推送 / 计划状态"]
|
||||
G --> H["提醒客服 / 用户运营 / 审核人员"]
|
||||
|
||||
E --> E1["显著风险提醒"]
|
||||
E1 --> E2["人工复核"]
|
||||
E2 --> E3{"复核结论"}
|
||||
E3 -->|确认风险| D
|
||||
E3 -->|排除风险| F
|
||||
```
|
||||
|
||||
#### 6.3 已确认业务问题
|
||||
|
||||
1. **双重退款**：APP/OA 已退款 + 用户又向 Amazon 申请退款 → 需要 Amazon 退款与 OA 返款自动比对
|
||||
2. **高风险用户**：一旦标记，支付/返款需要人工复核
|
||||
3. **风险可见性**：客服、审核、退款等环节必须都能看到风险提醒
|
||||
4. **非 APP 用户盲区**：直接走邮件退款，缺设备/注册邮箱等维度，识别能力下降
|
||||
5. **每次互动重判**：风险判断不是一次性的，每次有效互动都要重新执行
|
||||
|
||||
#### 6.4 节点规则
|
||||
|
||||
| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| 强弱关联判断 | 邮箱/设备/电话/地址/订单/ProfileID/收款信息/IP | 关联结果、命中维度列表 | 强关联 / 弱关联 / 无 | 命中时高亮命中维度 | - |
|
||||
| 高风险链路 | 当前推送/退款/返款状态 | 风险事件、拦截记录 | 已拦截 / 待复核 | 通知所有关联环节 | 拦截继续推送/自动退款/自动放行 |
|
||||
| 双重退款检测 | Amazon退款记录 + OA返款记录 | 匹配结果、差异 | 无重复 / 疑似重复 / 确认重复 | 确认重复时强告警 | 确认重复时阻止后续返款 |
|
||||
|
||||
---
|
||||
|
||||
### 7. 共用能力六：审批工作流
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
PLAN["计划草案"] --> R1{"计划类型"}
|
||||
R1 -->|测评计划| A1["Amazon运营总监审批"]
|
||||
R1 -->|回评计划| A2["Amazon运营总监或指定负责人"]
|
||||
R1 -->|免评计划| A3["Amazon运营总监 + 用户负责人"]
|
||||
R1 -->|紧急计划| A4["Amazon运营负责人 + 用户负责人 + 主管"]
|
||||
|
||||
A1 & A2 & A3 & A4 --> NEXT["周/月推送计划"]
|
||||
NEXT --> N1["用户负责人审批"]
|
||||
N1 --> N2["渠道负责人审批"]
|
||||
N2 --> APPROVED["已批准 → 执行"]
|
||||
```
|
||||
|
||||
#### 7.1 审批节点规则
|
||||
|
||||
| 节点 | 查 | 写 | 状态 | 提醒 | 拦截 |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| Amazon运营总监审批 | 计划详情、ASIN健康、风险提醒 | 审批结果、审批意见 | 通过 / 驳回 / 待补充 | 驳回时通知提交人 | - |
|
||||
| 用户负责人审批 | 人群快照、额度占用、频控结果 | 审批结果 | 通过 / 驳回 | 额度接近上限时预警 | - |
|
||||
| 渠道负责人审批 | 渠道容量、素材、合规 | 审批结果 | 通过 / 驳回 | 素材/文案风险提醒 | 合规风险时拦截 |
|
||||
|
||||
---
|
||||
|
||||
### 8. 共用能力七：审计与通知中心
|
||||
|
||||
| 模块 | 职责 | 关键记录内容 |
|
||||
| --- | --- | --- |
|
||||
| 状态变更审计 | 所有业务对象的状态流转留痕 | 对象ID、旧状态、新状态、操作人、时间、原因 |
|
||||
| 敏感字段访问 | 涉密字段的每次读取记录 | 访问人、访问时间、访问字段、访问上下文 |
|
||||
| 导出操作 | 所有数据导出行为留痕 | 导出人、时间、范围、原因、是否含敏感字段 |
|
||||
| 人工复核操作 | 所有人工干预决策留痕 | 决策人、决策内容、决策依据、决策时间 |
|
||||
| **规则风控提醒** | 触发规则/审核/风控阈值时通知 | 同一ASIN频控过高、同一用户多次推送、设备/邮箱异常、站点任务过密 |
|
||||
| **紧急Listing预警** | 评分接近4.2时通知 | ASIN、当前评分、差评摘要、建议动作 |
|
||||
| **客服超时提醒** | 工单/答应配合超时通知 | 工单ID、超时类型、超时时长、责任人 |
|
||||
| **额度预警** | 额度接近上限时通知 | 真实人、额度类型、已用/上限、受影响计划 |
|
||||
|
||||
---
|
||||
|
||||
## 第二部分：渠道专属流程图
|
||||
|
||||
### 9. 渠道一：IM 推送专属流程
|
||||
|
||||
#### 9.1 用户分层与推送策略
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
U["用户注册 + 绑定玩具"] --> L1{"识别用户分层"}
|
||||
|
||||
L1 -->|"A 未参与过<br/>从未走过回评/测评"| A1["推送前校验"]
|
||||
A1 --> A1a["查：JOYHUB ID、设备ID、黑名单、绑定产品"]
|
||||
A1 --> A1b{"设备ID在黑名单？"}
|
||||
A1b -->|是| A2["写：打标'长期测评人'<br/>拦截：不推回评/测评卡片<br/>推送：免评产品卡片"]
|
||||
A1b -->|否| A3["推送：对应绑定产品的回评卡片<br/>写：推送记录"]
|
||||
|
||||
L1 -->|"B 已参与过<br/>真实人累计真实提交评价 < 12"| B1["优先催评"]
|
||||
B1 --> B1a["查：未回评测评单、真实人累计评价数、标签"]
|
||||
B1 --> B1b["推送：催评卡片/消息"]
|
||||
B1b --> B2{"完成好评提交？"}
|
||||
B2 -->|是| B3["写：重新计算真实人累计评价数"]
|
||||
B3 --> B4{"累计真实提交评价仍 < 12？"}
|
||||
B4 -->|是| B5["推送：当日测评计划对应卡片<br/>写：二次转化记录"]
|
||||
B4 -->|否| B6["写：打标'长期测评人'→ 推送免评产品"]
|
||||
|
||||
L1 -->|"C 长期测评人<br/>真实人累计真实提交评价 ≥ 12"| C1["拦截：不推送普通回评/测评卡片<br/>推送：当日免评补单产品<br/>写：免评推送记录"]
|
||||
|
||||
style A2 fill:#fce4ec
|
||||
style C1 fill:#fff3e0
|
||||
```
|
||||
|
||||
#### 9.2 IM 用户提交后的核验与流转
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
SUBMIT["入口：用户在IM中提交回评/测评信息"] --> ITEMS["提交内容：订单号 + 返款账号 + 评论截图/链接"]
|
||||
|
||||
ITEMS --> AUTO["查：当前用户标签、关联计划<br/>写：系统自动登记提交记录<br/>状态：待核验"]
|
||||
|
||||
AUTO --> VERIFY["订单号核实"]
|
||||
VERIFY --> V1{"查：是否测评单？"}
|
||||
VERIFY --> V2{"查：是否为公司产品？"}
|
||||
VERIFY --> V3{"查：单号格式 xxx-xxxxxxx-xxxxxxx？"}
|
||||
|
||||
V1 & V2 & V3 -->|全部通过| PASS["写：登记进系统<br/>状态：已登记"]
|
||||
V1 & V2 & V3 -->|任一不通过| CS["转人工：推送客服<br/>状态：待客服处理"]
|
||||
|
||||
CS --> CS1["客服沟通用户 → 补充/修正信息"]
|
||||
CS1 --> CS2["写：修正记录 → 回到核验"]
|
||||
|
||||
PASS --> CHECK{"信息完整？"}
|
||||
CHECK -->|完整| FINANCE["写：推送财务返款提醒<br/>状态：待返款"]
|
||||
CHECK -->|缺返款账号| TAG1["写：打标'xx产品待返款'<br/>提醒：自动通知用户补充<br/>状态：信息待补全"]
|
||||
CHECK -->|缺评论截图/链接| TAG2["写：打标'xx产品待回评'<br/>提醒：自动通知用户补充<br/>状态：信息待补全"]
|
||||
|
||||
FINANCE --> PAY["查：付款凭证<br/>写：自动推送返款/礼品卡通知<br/>状态：已返款"]
|
||||
PAY --> DONE["状态：回评流程走完"]
|
||||
DONE --> TAG3["写：打标'xx产品已回评用户'<br/>推送：测评卡片（二次转化）"]
|
||||
|
||||
style SUBMIT fill:#e8f5e9
|
||||
style PASS fill:#c8e6c9
|
||||
style CS fill:#fff3e0
|
||||
style DONE fill:#e3f2fd
|
||||
```
|
||||
|
||||
#### 9.3 IM 新测评流程
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
START["入口：用户收到测评卡片 → 提交测评信息"] --> VFY["查：订单号是否撤销、是否退款<br/>查：真实人月度测评额度与累计真实提交评价"]
|
||||
|
||||
VFY -->|"额度允许 + 订单有效"| REG["写：登记进系统<br/>写：打标'xx产品测评单登记'<br/>状态：已登记"]
|
||||
|
||||
REG --> INFO{"信息完整？"}
|
||||
INFO -->|只有订单号<br/>缺返款账号+截图| TAG_A["写：打标'xx产品测评待返款'<br/>提醒：自动通知用户<br/>状态：待补全"]
|
||||
INFO -->|只有截图+链接<br/>缺订单号+返款账号| TAG_B["写：打标'xx产品测评单待回评'<br/>提醒：自动通知用户<br/>状态：待补全"]
|
||||
INFO -->|完整| COMP["状态：测评流程走完"]
|
||||
|
||||
COMP --> RECALC["查：重新计算 review 数量<br/>写：review 数量更新"]
|
||||
RECALC -->|"累计真实提交评价 ≥ 12"| LC["写：打标'长期测评人'<br/>推送：免评产品卡片"]
|
||||
RECALC -->|"≤ 12 review"| NEXT["推送：当日测评计划对应卡片<br/>写：二次转化记录"]
|
||||
|
||||
style COMP fill:#c8e6c9
|
||||
style LC fill:#fff3e0
|
||||
```
|
||||
|
||||
#### 9.4 IM 核心标签汇总
|
||||
|
||||
| 分类 | 标签 | 触发时机 | 后续动作 |
|
||||
| --- | --- | --- | --- |
|
||||
| **用户层级** | 未参与过用户 (A) | 注册+绑定后首次识别 | 推送回评卡片 |
|
||||
| | 参与过用户 (B) | 已有回评/测评记录，review < 12 | 优先催评 → 二次转化 |
|
||||
| | 长期测评人 (C) | review > 12 | 仅推送免评产品 |
|
||||
| **回评流程** | xx产品已回评用户 | 回评流程走完 | 推送测评卡片 |
|
||||
| | xx产品待回评用户 | 缺截图/链接 | 自动通知补全 |
|
||||
| | xx产品待返款 | 缺返款账号 | 自动通知补全 |
|
||||
| **测评流程** | xx产品测评单登记 | 订单核实通过 | 继续信息补全 |
|
||||
| | xx产品测评待返款用户 | 测评缺返款 | 自动通知补全 |
|
||||
| | xx产品测评单待回评 | 测评缺截图 | 自动通知补全 |
|
||||
| | xx产品测评单 | 测评流程走完 | review重算 |
|
||||
| **免评流程** | xx产品的免评 | 长期测评人参与免评单 | 不再推回评/测评 |
|
||||
|
||||
#### 9.5 IM 推送动作与流转动作
|
||||
|
||||
| 动作类型 | 动作 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| **推送** | 回评卡片 | A类用户首次推送 |
|
||||
| | 测评卡片 | B类二次转化 / A类设备在黑名单 |
|
||||
| | 免评产品卡片 | C类用户 / 黑名单命中用户 |
|
||||
| | 催评消息 | B类优先催评 / 紧急催评 |
|
||||
| | 返款/礼品卡通知 | 财务有凭证后推送 |
|
||||
| **流转** | 推送客服 | 订单号不符合 / 异常 |
|
||||
| | 推送财务 | 订单登记完成后 |
|
||||
| | 自动打标 | 各流程节点完成时 |
|
||||
| | 二次转化 | 回评完成 → 推送测评卡片 |
|
||||
|
||||
---
|
||||
|
||||
### 10. 渠道二：EDM 邮件推送专属流程
|
||||
|
||||
#### 10.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
START["入口：计划已批准，进入EDM执行拆解"] --> POOL["筛选EDM目标用户池"]
|
||||
|
||||
POOL --> COND{"查：用户条件"}
|
||||
COND -->|"非APP用户"| NON["进入EDM队列"]
|
||||
COND -->|"APP低活跃"| LOW["查：IM频控通过后进入EDM队列"]
|
||||
COND -->|"APP活跃"| SKIP["拦截：跳过EDM，走IM/APP"]
|
||||
|
||||
NON --> PRECHK["推送前检查"]
|
||||
LOW --> PRECHK
|
||||
|
||||
PRECHK --> C1["查：身份——是否有有效邮箱"]
|
||||
PRECHK --> C2["查：风险——邮箱是否命中黑名单"]
|
||||
PRECHK --> C3["查：退订——是否已退订/硬退信"]
|
||||
PRECHK --> C4["查：资格——OA是否有资格"]
|
||||
PRECHK --> C5["查：国家——站点与邮箱类型匹配"]
|
||||
|
||||
C1 & C2 & C3 & C4 & C5 -->|全部通过| BEHAVIOR["行为筛选"]
|
||||
C1 & C2 & C3 & C4 & C5 -->|任一不通过| EXCLUDE["写：排除原因<br/>拦截：不发送"]
|
||||
|
||||
BEHAVIOR --> B1["查：最近打开时间、总打开次数"]
|
||||
BEHAVIOR --> B2["查：最近3/5次是否连续0打开"]
|
||||
BEHAVIOR --> B3["查：最近回复时间、回复后又发送数"]
|
||||
BEHAVIOR --> B4["查：是否点击评论链接但未回复"]
|
||||
BEHAVIOR --> B5["查：单月收信次数、各邮件类型发送次数"]
|
||||
|
||||
B1 & B2 & B3 & B4 & B5 --> RHYTHM{"节奏判断"}
|
||||
RHYTHM -->|适合触达| SEND["发送EDM<br/>写：发送记录<br/>状态：已发送"]
|
||||
RHYTHM -->|需降频| DELAY["写：延后标记<br/>状态：观察中"]
|
||||
RHYTHM -->|不适合| SWITCH["切换其他渠道或排除"]
|
||||
|
||||
SEND --> TRACK["追踪回收"]
|
||||
TRACK --> T1["送达 → 写：送达时间"]
|
||||
T1 --> T2["打开 → 写：打开时间、打开次数+1"]
|
||||
T2 --> T3["点击 → 写：点击时间、点击目标"]
|
||||
T3 --> T4["跳转至APP下载页/产品页"]
|
||||
T4 --> RESULT{"用户行为"}
|
||||
RESULT -->|"下载并注册APP"| TO_IM["写：用户渠道升级<br/>后续走IM主流程"]
|
||||
RESULT -->|"直接回复邮件"| TO_CS["写：生成客服工单<br/>走客服执行流程"]
|
||||
RESULT -->|"未响应"| RETRY["写：进入再触达队列<br/>（遵循频控间隔）"]
|
||||
RESULT -->|"退订"| UNSUB["写：退订标记<br/>拦截：该渠道永久排除"]
|
||||
|
||||
SEND --> METRICS["写：EDM指标<br/>发送数/送达率/打开率/点击率/回复率/转化数/退订数"]
|
||||
|
||||
style EXCLUDE fill:#fce4ec
|
||||
style UNSUB fill:#fce4ec
|
||||
style TO_IM fill:#e3f2fd
|
||||
style TO_CS fill:#fff3e0
|
||||
```
|
||||
|
||||
#### 10.2 EDM 专属行为指标
|
||||
|
||||
| 字段组 | 具体指标 | 用途 |
|
||||
| --- | --- | --- |
|
||||
| **打开行为** | 最近打开时间、总打开次数、最近3/5次0打开 | 判断活跃度 → 决定是否继续发 |
|
||||
| **回复行为** | 最近回复时间、回复后又发送封数 | 判断兴趣度 → 决定触达节奏 |
|
||||
| **点击行为** | 是否点击评论链接、点击后未回复时长 | 判断意向 → 决定是否追加触达 |
|
||||
| **触达频率** | 单月收信次数、各邮件类型发送次数 | 频控 → 防止疲劳 |
|
||||
| **邮件属性** | 邮件类型、邮箱后缀标签、国家站点 | 匹配 → 确定发送内容 |
|
||||
| **排除项** | 风险用户、黑名单、退订、硬退信、OA无资格 | 硬过滤 → 不进池 |
|
||||
|
||||
#### 10.3 EDM vs IM 关键差异
|
||||
|
||||
| 维度 | IM | EDM |
|
||||
| --- | --- | --- |
|
||||
| 用户身份强度 | 强（JOYHUB ID + 设备 + 订单绑定） | 弱（仅邮箱，可能无JOYHUB ID） |
|
||||
| 风险识别能力 | 高（多维度交叉） | 低（缺设备/注册邮箱等维度） |
|
||||
| 转化路径 | 直接提交 → 核验 → 返款 | 引导注册APP → 再进入IM链路 |
|
||||
| 退订机制 | 社区屏蔽/消息免打扰 | 邮件退订链接 + 硬退信 |
|
||||
| 频控周期 | 按日/按类目 | 按周/按月 |
|
||||
| 行为信号 | 绑定/活跃/点击/回复/标签 | 打开/点击/回复/退订/连续0打开 |
|
||||
|
||||
---
|
||||
|
||||
### 11. 渠道三：APP Push 专属流程
|
||||
|
||||
#### 11.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
START["触发源"] --> T1["用户绑定新玩具"]
|
||||
START --> T2["用户长期未活跃（7天+）"]
|
||||
START --> T3["测评/回评计划到期"]
|
||||
START --> T4["Listing健康紧急"]
|
||||
START --> T5["活动/促销通知"]
|
||||
|
||||
T1 & T2 & T3 & T4 & T5 --> FILTER["查：共用能力过滤"]
|
||||
|
||||
FILTER --> F1["查：身份——JOYHUB ID + 设备在线"]
|
||||
FILTER --> F2["查：风险——黑名单 + 关联检测"]
|
||||
FILTER --> F3["查：频控——当日Push次数 + 用户通知设置"]
|
||||
FILTER --> F4["查：标签——匹配推送策略"]
|
||||
|
||||
F1 & F2 & F3 & F4 -->|通过| PUSH["发送APP Push<br/>写：推送记录<br/>状态：已发送"]
|
||||
F1 & F2 & F3 & F4 -->|不通过| SKIP["写：跳过原因<br/>状态：已跳过"]
|
||||
|
||||
PUSH --> USER{"用户响应"}
|
||||
USER -->|"点击打开"| IN_APP["进入APP → 落地页"]
|
||||
USER -->|"忽略/关闭"| NOOP["写：曝光记录<br/>拦截：短期内不重复推"]
|
||||
USER -->|"卸载/禁用通知"| UNINSTALL["写：不可再推送标记<br/>降级：转入EDM候选池"]
|
||||
|
||||
IN_APP --> ACT{"APP内动作"}
|
||||
ACT -->|"提交回评/测评"| IM_FLOW["走IM提交核验流程（§9.2）"]
|
||||
ACT -->|"联系客服"| CS_FLOW["生成客服工单（§12）"]
|
||||
ACT -->|"仅浏览"| TAG["写：记录行为，更新活跃标签"]
|
||||
|
||||
style IN_APP fill:#e3f2fd
|
||||
style UNINSTALL fill:#fce4ec
|
||||
```
|
||||
|
||||
#### 11.2 APP Push 与 IM 的分工
|
||||
|
||||
| 场景 | 用 APP Push | 用 IM |
|
||||
| --- | --- | --- |
|
||||
| 新绑定玩具 → 引导测评 | - | 推送回评/测评卡片 |
|
||||
| 用户7天未活跃 | 推送召回通知 | - |
|
||||
| 测评计划到期提醒 | - | 推送催评消息 |
|
||||
| Listing 紧急 | 推送紧急通知 | 推送紧急催评卡片 |
|
||||
| 返款已到账 | 推送到账通知 | - |
|
||||
| 活动/促销 | 推送活动通知 | - |
|
||||
|
||||
#### 11.3 APP 必查字段
|
||||
|
||||
| 字段组 | 内容 |
|
||||
| --- | --- |
|
||||
| 用户资料 | 注册邮箱、JOYHUB ID、国家、语言 |
|
||||
| 设备上下文 | 设备号、设备型号/类型、APP版本、系统版本 |
|
||||
| 产品关系 | 绑定玩具、绑定时间、目标产品关系 |
|
||||
| 行为数据 | 活跃、打开、点击、回复、站内浏览、广告互动 |
|
||||
|
||||
---
|
||||
|
||||
### 12. 渠道四：TEL 电话专属流程
|
||||
|
||||
#### 12.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
START["触发电话任务"] --> S1["用户答应配合但超时未提交"]
|
||||
START --> S2["高价值用户需深度跟进"]
|
||||
START --> S3["复杂售后无法文字解决"]
|
||||
START --> S4["IM/EDM多次触达无响应"]
|
||||
START --> S5["紧急Listing需人工沟通"]
|
||||
START --> S6["Amazon页面/说明书来电"]
|
||||
START --> S7["计划生成的外呼任务"]
|
||||
|
||||
S1 & S2 & S3 & S4 & S5 & S6 & S7 --> TICKET["写：生成电话类客服工单<br/>状态：待分配"]
|
||||
|
||||
TICKET --> PREPARE["拨打前准备（必须）"]
|
||||
PREPARE --> P1["查：用户完整画像<br/>（身份/订单/历史/标签/风险）"]
|
||||
PREPARE --> P2["查：风险状态<br/>拦截：强关联命中 → 暂停拨打 → 先复核"]
|
||||
PREPARE --> P3["查：历史沟通记录<br/>（避免重复询问）"]
|
||||
PREPARE --> P4["写：准备话术和问题清单"]
|
||||
|
||||
P1 & P2 & P3 & P4 --> CONTACT["客服电话联系用户<br/>写：拨打记录<br/>状态：处理中"]
|
||||
|
||||
CONTACT --> RESULT{"通话结果"}
|
||||
RESULT -->|"接通-售后问题"| AFTERSALE["先解决售后<br/>查：订单/产品/凭证<br/>写：处理方案<br/>状态：售后处理中"]
|
||||
RESULT -->|"接通-直接配合"| COOP["确认评价提交时间<br/>写：登记答应配合<br/>状态：答应配合"]
|
||||
RESULT -->|"接通-拒绝"| REJECT["写：记录拒绝原因<br/>状态：已关闭"]
|
||||
RESULT -->|"接通-疑似诈骗"| FRAUD["创建诈骗事件<br/>写：诈骗记录<br/>转风险链路（§6）"]
|
||||
RESULT -->|"未接通"| RETRY["写：拨打次数+1<br/>提醒：安排重试"]
|
||||
|
||||
AFTERSALE --> SAT{"是否解决/满意？"}
|
||||
SAT -->|是| INVITE["引导回评/邀请测评"]
|
||||
SAT -->|否| ESCALATE["升级处理 → 转组长/负责人"]
|
||||
|
||||
INVITE --> FOLLOW["写：进入答应配合跟进<br/>状态：待提醒"]
|
||||
COOP --> FOLLOW
|
||||
FOLLOW --> UPDATE["写：更新工单 + 用户标签"]
|
||||
|
||||
RETRY --> DECIDE{"重试策略"}
|
||||
DECIDE -->|"< 3次"| CONTACT
|
||||
DECIDE -->|"≥ 3次未接通"| DOWNGRADE["写：降级至EDM/放弃<br/>状态：待关闭"]
|
||||
|
||||
CONTACT --> RECORD["写：通话记录<br/>来电时间/来源/联系方式/订单号<br/>问题类型/描述/处理方案<br/>是否解决/是否邀请测评/用户是否接受"]
|
||||
|
||||
style CONTACT fill:#fff3e0,stroke:#ef6c00
|
||||
style FRAUD fill:#fce4ec,stroke:#c62828
|
||||
style AFTERSALE fill:#e3f2fd
|
||||
```
|
||||
|
||||
#### 12.2 TEL 必填记录字段
|
||||
|
||||
| 类别 | 字段 | 涉密 |
|
||||
| --- | --- | --- |
|
||||
| 来电基础 | 来电时间、来源（Amazon页/说明书/外呼）、客服、联系方式 | - |
|
||||
| 订单信息 | Amazon订单号、产品型号/款式/颜色、购买时间 | 订单号涉密 |
|
||||
| 问题信息 | 问题类型、问题描述、图片/视频凭证 | - |
|
||||
| 处理信息 | 处理方案、是否解决、是否需要后续跟进 | - |
|
||||
| 评价相关 | 是否邀请回评/测评、用户是否接受、是否涉及差评 | - |
|
||||
| 拨打统计 | 拨打次数、通话时长、接通状态 | - |
|
||||
|
||||
---
|
||||
|
||||
### 13. 渠道五：客服工单执行流程
|
||||
|
||||
#### 13.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["入口：用户消息 / 推送转人工 / 电话后续 / 风险触发"] --> B["写：生成工单<br/>状态：待分配"]
|
||||
|
||||
B --> C["查：班次、在线状态、当前负载、最大工单数<br/>写：自动分配到客服组<br/>状态：已分配"]
|
||||
|
||||
C --> D["客服组长分派到组员<br/>状态：处理中"]
|
||||
|
||||
D --> E["查：展示用户上下文卡<br/>（身份/历史/风险/设备/触达）"]
|
||||
|
||||
E --> F["客服开始处理"]
|
||||
|
||||
F --> G{"处理结果"}
|
||||
G -->|"等待用户回复"| H["状态：等待用户<br/>提醒：超时提醒机制"]
|
||||
G -->|"等待内部协同"| I["状态：等待内部<br/>提醒：超时升级"]
|
||||
G -->|"用户答应配合"| J["写：生成跟进任务<br/>状态：答应配合<br/>进入答应配合状态机"]
|
||||
G -->|"疑似诈骗"| K["写：诈骗疑似标记<br/>提醒：组长/负责人复核<br/>转风险链路（§6）"]
|
||||
G -->|"问题已解决"| L["写：解决记录<br/>状态：已解决"]
|
||||
|
||||
H --> F
|
||||
I --> F
|
||||
|
||||
J --> M["提醒/再联系/等待提交"]
|
||||
M --> N["用户提交评价或反馈<br/>状态：已提交评价/已提交反馈"]
|
||||
|
||||
K --> P["组长/负责人复核"]
|
||||
P --> Q{"复核结论"}
|
||||
Q -->|确认诈骗| R["转风险链路 → 同步黑名单"]
|
||||
Q -->|退回继续处理| F
|
||||
|
||||
L --> S["写：关闭工单<br/>状态：已关闭"]
|
||||
```
|
||||
|
||||
#### 13.2 三套并行状态
|
||||
|
||||
| 状态体系 | 典型状态 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| **工单状态** | 待分配 → 已分配 → 处理中 → 等待用户/等待内部 → 已解决 / 疑似诈骗 → 已关闭 | 工单生命周期 |
|
||||
| **答应配合状态** | 已答应配合 → 待分配负责人 → 待提醒 → 等待提交 → 已提交评价/已提交反馈 → 超时 → 需再次联系 → 已关闭 | 防止承诺用户流失 |
|
||||
| **风险状态** | 无异常 → 弱关联高风险 → 强关联高风险 → 疑似诈骗 → 已确认诈骗 → 已同步黑名单 | 风险独立跟踪 |
|
||||
|
||||
---
|
||||
|
||||
### 14. 客服管理支撑流程
|
||||
|
||||
#### 14.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["排班设置"] --> B["在线客服池"]
|
||||
C["出勤记录"] --> B
|
||||
B --> D["工单自动分配<br/>查：在线状态/排班/当前负载/最大工单数"]
|
||||
D --> E["回复效率统计"]
|
||||
D --> F["转化统计"]
|
||||
F --> G["目标完成统计"]
|
||||
E --> H["主管看板"]
|
||||
F --> H
|
||||
G --> H
|
||||
```
|
||||
|
||||
#### 14.2 管理指标
|
||||
|
||||
| 模块 | 指标 |
|
||||
| --- | --- |
|
||||
| **出勤** | 应出勤、实际出勤、出勤率、迟到、早退、请假、缺勤 |
|
||||
| **回复效率** | 回复用户数、处理工单数、发送消息数、首次回复时长（平均/中位数/最大/最小） |
|
||||
| **转化** | RSO回评登记订单数、RDO测评登记订单数、获取评价数、评价完成率 |
|
||||
| **目标** | 月目标、当前完成、完成率、历史趋势 |
|
||||
|
||||
---
|
||||
|
||||
### 15. 评价完成流程
|
||||
|
||||
#### 15.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
A["用户提交评价"] --> B["写：记录真实提交事实<br/>状态：已提交待核验"]
|
||||
B --> C["写：更新真实人累计评价额度（+1）<br/>提醒：接近12时预警"]
|
||||
|
||||
C --> D{"查：Amazon是否展示 / 是否可核验"}
|
||||
D -->|"展示或可核验"| E["写：计入计划完成<br/>状态：已确认展示"]
|
||||
D -->|"未展示 / 暂不可核验"| F["写：保留已提交事实<br/>状态：未展示待观察"]
|
||||
|
||||
E --> G["写：更新ASIN健康与计划完成度"]
|
||||
F --> H["进入异常观察队列<br/>提醒：定期复查"]
|
||||
|
||||
G --> I["结果回流：更新经营层数据"]
|
||||
```
|
||||
|
||||
#### 15.2 必须拆开的两个事实
|
||||
|
||||
| 事实 | 是否计入累计12额度 | 是否计入计划完成 | 计数时点 |
|
||||
| --- | --- | --- | --- |
|
||||
| 用户真实提交评价 | **是** | 还不一定 | 提交时立即计数 |
|
||||
| Amazon 展示确认 | 已在上一步计过 | **是** | 展示确认时 |
|
||||
|
||||
---
|
||||
|
||||
### 16. 渠道六：KOC/KOL 协作专属流程（免评核心通道）
|
||||
|
||||
#### 16.1 流程图
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
START["入口：免评计划 / 推新计划已批准"] --> PLAN["查：计划参数<br/>写：拆解KOC/KOL执行方案"]
|
||||
|
||||
PLAN --> STEP1["匹配合作对象"]
|
||||
STEP1 --> S1A["查：按国家/平台/粉丝量/历史效果筛选"]
|
||||
STEP1 --> S1B["查：按产品类目匹配KOC/KOL专长"]
|
||||
STEP1 --> S1C["查：合作对象风险（历史纠纷/违约）<br/>提醒：有风险记录时提示"]
|
||||
|
||||
S1A & S1B & S1C --> STEP2["写：分配Code/素材/内容Brief"]
|
||||
STEP2 --> STEP3["KOC/KOL内容发布"]
|
||||
|
||||
STEP3 --> TRACK["跟踪执行结果"]
|
||||
TRACK --> T1["查：内容发布链接"]
|
||||
TRACK --> T2["查：点击/跳转数据"]
|
||||
TRACK --> T3["查：Code使用量"]
|
||||
TRACK --> T4["查：带货订单"]
|
||||
TRACK --> T5["查：转化销量"]
|
||||
TRACK --> T6["查：Listing权重变化"]
|
||||
|
||||
T1 & T2 & T3 & T4 & T5 & T6 --> SYNC["从JOYCOLLAB同步数据至USER<br/>写：同步记录<br/>提醒：同步失败时告警"]
|
||||
|
||||
SYNC --> EVAL{"执行评估"}
|
||||
EVAL -->|"达标"| DONE["写：结果回流<br/>更新ASIN健康/计划完成度<br/>状态：已完成"]
|
||||
EVAL -->|"未达标"| ADJUST["调整策略<br/>写：调整记录<br/>更换KOC/调整素材/追加Code"]
|
||||
|
||||
SYNC --> FINANCE["财务侧<br/>查：提成计算/返点核算/提款记录<br/>提醒：财务数据独立权限"]
|
||||
```
|
||||
|
||||
#### 16.2 KOC/KOL 与评价型渠道的本质差异
|
||||
|
||||
| 维度 | 评价型（IM/EDM/APP/TEL） | KOC/KOL |
|
||||
| --- | --- | --- |
|
||||
| 执行主体 | 系统 + 客服 | 外部KOC/KOL + 运营协同 |
|
||||
| 终点 | 用户提交评价 | 内容发布/Code使用/带货销量/权重 |
|
||||
| 用户关系 | 平台 ↔ 买家 | 品牌 ↔ 达人 ↔ 达人粉丝 |
|
||||
| 数据源 | USER系统内部 | JOYCOLLAB同步 |
|
||||
| 财务 | 返款（固定金额） | 提成+返点（按效果） |
|
||||
| 风险关注 | 诈骗/双重退款 | 合作纠纷/违约/虚假流量 |
|
||||
|
||||
#### 16.3 IM/EDM/APP 在免评中的协同角色
|
||||
|
||||
| 协同动作 | 渠道 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| KOC内容二次分发 | IM/APP | 将KOC发布的优质内容推送给站内用户 |
|
||||
| 免评Code触达 | IM/EDM | 将免评Code分发给符合条件的站内用户 |
|
||||
| 活动引流 | APP Push | 推送活动通知引导用户进入KOC内容页 |
|
||||
| 结果通知 | IM/APP | 通知用户Code到账、订单确认 |
|
||||
|
||||
#### 16.4 免评核心结果组
|
||||
|
||||
| 结果组 | 跟踪内容 |
|
||||
| --- | --- |
|
||||
| 内容 | 发布状态、链接、发布时间、互动数据 |
|
||||
| 引流 | 点击量、跳转量、Code使用量 |
|
||||
| 成交 | 订单数、转化量、销量 |
|
||||
| 经营 | 权重变化、ASIN健康变化、品牌搜索变化 |
|
||||
|
||||
---
|
||||
|
||||
### 17. 店铺紧急催评流程（IM渠道专属子流程）
|
||||
|
||||
```mermaid
|
||||
flowchart TB
|
||||
TRIGGER["触发条件<br/>查：店铺当日掉评/差评/需紧急拿好评稳评分<br/>状态：紧急触发"] --> CALC["计算推送量<br/>目标好评数 ÷ 2% = 需触达用户数<br/>写：推送方案"]
|
||||
|
||||
CALC --> EXEC["执行"]
|
||||
EXEC --> E1["查：筛选可触达用户<br/>写：推送紧急催评消息"]
|
||||
EXEC --> E2["查：优先触达高完成率用户"]
|
||||
EXEC --> E3["查：持续跟踪回评提交状态"]
|
||||
|
||||
E1 & E2 & E3 --> RESULT{"结果"}
|
||||
RESULT -->|"已提交好评"| R1["写：更新已回评/测评完成<br/>状态：已完成"]
|
||||
RESULT -->|"未提交"| R2["写：保留在待催评池<br/>状态：待催评"]
|
||||
RESULT -->|"异常"| R3["转人工：推送客服跟进<br/>状态：转客服"]
|
||||
|
||||
style TRIGGER fill:#fce4ec,stroke:#c62828
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 第三部分：渠道交叉与协同规则
|
||||
|
||||
### 18. 渠道优先级路由
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
USER_IN["同一个用户"] --> D1{"查：用户状态"}
|
||||
D1 -->|"APP注册 + 活跃 + 已绑定"| IM["IM 优先"]
|
||||
D1 -->|"APP注册 + 低活跃"| APP_PUSH["APP Push优先 + IM补充"]
|
||||
D1 -->|"未注册APP"| EDM["EDM优先 → 引导注册后转IM"]
|
||||
D1 -->|"高价值 + 多次无响应"| TEL["TEL人工"]
|
||||
D1 -->|"长期测评人（C类）"| IM_FREE["IM免评卡片 + KOC/KOL协同"]
|
||||
|
||||
style IM fill:#e3f2fd
|
||||
style EDM fill:#fff3e0
|
||||
style TEL fill:#fce4ec
|
||||
```
|
||||
|
||||
### 19. 渠道间去重规则
|
||||
|
||||
| 规则 | 说明 |
|
||||
| --- | --- |
|
||||
| 同一计划同一用户 | 不重复通过多渠道路由，优先走最高优先级渠道 |
|
||||
| 用户已在客服工单中 | 暂停自动触达，等待工单关闭后再判断 |
|
||||
| 用户已提交评价（待核验） | 所有渠道暂停催评，等待核验结果 |
|
||||
| 用户已退订某渠道 | 该渠道永久排除，不影响其他渠道 |
|
||||
| 用户命中强关联风险 | **所有渠道暂停自动触达**，进入人工复核 |
|
||||
| 用户命中弱关联风险 | 降频 + 提示后继续，但需人工关注 |
|
||||
|
||||
### 20. 用户状态 × 渠道可用性矩阵
|
||||
|
||||
| 用户状态 | IM | EDM | APP Push | TEL | KOC/KOL |
|
||||
| --- | --- | --- | --- | --- | --- |
|
||||
| APP活跃 + 已绑定 | **首选** | 不送 | 补充 | - | - |
|
||||
| APP活跃 + 未绑定 | 引导绑定 | - | 活动通知 | - | - |
|
||||
| APP低活跃 | 降频 | 补充 | **召回** | - | - |
|
||||
| 未注册APP | - | **首选** | - | 高价值时 | - |
|
||||
| 已答应配合 | 提醒 | - | 到期提醒 | **超时拨打** | - |
|
||||
| 长期测评人 (C) | **仅免评** | - | - | - | 可协同 |
|
||||
| 黑名单/强关联 | **全暂停** | **全暂停** | **全暂停** | **需复核** | **暂停** |
|
||||
| 弱关联风险 | 降频+提示 | 降频+提示 | 降频+提示 | 提示后执行 | 提示 |
|
||||
| 累计接近12 | 预警+人工 | 预警+人工 | 预警+人工 | 可正常服务；涉及普通测评邀请时需人工复核 | - |
|
||||
| 累计已满12 | 仅免评 | 仅免评 | 仅免评 | 可正常服务；不得绕过普通测评限制 | 可协同 |
|
||||
|
||||
---
|
||||
|
||||
## 第四部分：第三步数据对象建议
|
||||
|
||||
### 21. 第三步建议优先产出的数据对象
|
||||
|
||||
| 优先级 | 对象 | 来源能力/渠道 |
|
||||
| --- | --- | --- |
|
||||
| **P0** | `person_profiles`（真实人） | §2 真实人识别 |
|
||||
| **P0** | `person_identity_links`（身份关联） | §2 真实人识别 |
|
||||
| **P0** | `contact_context_snapshots`（用户上下文快照） | §2 用户上下文卡 |
|
||||
| **P0** | `person_quota_ledgers`（额度台账） | §4 额度台账 |
|
||||
| **P0** | `quota_reservations`（额度预占） | §4 额度台账 |
|
||||
| **P0** | `risk_signals`（风险信号） | §6 风险判断 |
|
||||
| **P0** | `risk_cases`（风险事件） | §6 风险判断 |
|
||||
| **P0** | `blacklist_entities`（黑名单实体） | §6 风险判断 |
|
||||
| **P0** | `audience_snapshots`（人群快照） | §3 人群生成 |
|
||||
| **P0** | `audience_exclusions`（人群排除记录） | §3 人群生成 |
|
||||
| **P0** | `channel_route_decisions`（渠道路由决策） | §18 渠道优先级 |
|
||||
| **P0** | `channel_dedup_records`（渠道去重记录） | §19 渠道间去重 |
|
||||
| **P1** | `im_interaction_records`（IM交互记录） | §9 IM |
|
||||
| **P1** | `im_flow_tags`（IM流程标签） | §9 IM |
|
||||
| **P1** | `edm_message_events`（EDM事件） | §10 EDM |
|
||||
| **P1** | `edm_user_behavior_profiles`（EDM用户行为画像） | §10 EDM |
|
||||
| **P1** | `app_touch_events`（APP触达事件） | §11 APP |
|
||||
| **P1** | `tel_call_records`（TEL通话记录） | §12 TEL |
|
||||
| **P1** | `support_tickets`（客服工单） | §13 客服 |
|
||||
| **P1** | `support_followups`（答应配合跟进） | §13 客服 |
|
||||
| **P1** | `support_assignment_logs`（工单分配日志） | §13 客服 |
|
||||
| **P1** | `review_submission_records`（评价提交记录） | §15 评价完成 |
|
||||
| **P1** | `review_display_checks`（评价展示核验） | §15 评价完成 |
|
||||
| **P1** | `exemption_plan_tasks`（免评计划任务） | §16 KOC/KOL |
|
||||
| **P1** | `creator_content_records`（KOC内容记录） | §16 KOC/KOL |
|
||||
| **P1** | `amazon_refund_records`（Amazon退款记录） | §6 双重退款 |
|
||||
| **P1** | `oa_refund_records`（OA返款记录） | §6 双重退款 |
|
||||
| **P1** | `refund_match_results`（退款比对结果） | §6 双重退款 |
|
||||
| **P2** | `attendance_records`（出勤记录） | §14 客服管理 |
|
||||
| **P2** | `shift_schedules`（排班表） | §14 客服管理 |
|
||||
| **P2** | `support_goal_records`（客服目标） | §14 客服管理 |
|
||||
| **P2** | `support_performance_snapshots`（绩效快照） | §14 客服管理 |
|
||||
| **P2** | `interaction_audit_logs`（互动审计日志） | §8 审计 |
|
||||
| **P2** | `manual_review_tasks`（人工复核任务） | §5/§6 复检与风险 |
|
||||
|
||||
---
|
||||
|
||||
### 22. 与基线 v1.2 的关系
|
||||
|
||||
本文件是基线 v1.2 的下游细化产物：
|
||||
|
||||
| 基线 v1.2 章节 | 本文件对应 |
|
||||
| --- | --- |
|
||||
| §6.1 主动触达支线 | §9 IM、§10 EDM、§11 APP Push |
|
||||
| §6.2 免评执行支线 | §16 KOC/KOL + §16.3 协同角色 |
|
||||
| §6.3 被动售后与TEL支线 | §12 TEL |
|
||||
| §6.4 风险/诈骗拦截支线 | §6 风险判断与黑名单 |
|
||||
| §6.5 客服工单与客服管理支线 | §13 客服工单、§14 客服管理 |
|
||||
| §7 真实人识别、用户上下文与额度规则 | §2 真实人识别、§4 额度台账 |
|
||||
| §8 渠道专属补充事实 | §9-§16 各渠道专属流程 |
|
||||
| §11 第二步新入口 | 本文件整体 |
|
||||
|
||||
---
|
||||
|
||||
### 23. 本版结论
|
||||
|
||||
v2.2 吸收了前序文档中的以下优势：
|
||||
|
||||
1. **额度体系**（测评4/免评4/累计12）作为独立共用能力，含台账/预占/预警/拦截
|
||||
2. **画像拆解**为 7 组字段 × 3 类用途
|
||||
3. **节点规则表**统一用 查/写/状态/提醒/拦截/转人工 格式
|
||||
4. **EDM 专属行为指标**（3/5次0打开、点击未回复时长、单月收信次数）
|
||||
5. **客服管理支撑流**（排班/出勤/绩效/目标）
|
||||
6. **评价完成流程**中拆开"提交即计12"vs"展示才计完成"
|
||||
7. **P0/P1/P2 数据对象**优先级
|
||||
|
||||
同时保留了我版的核心优势：
|
||||
|
||||
1. **IM A/B/C 三层用户完整流转**（提交核验、测评流程、标签汇总、推送/流转动作表）
|
||||
2. **渠道交叉与协同规则**（优先级路由、去重规则、用户状态 × 渠道可用性矩阵）
|
||||
3. **KOC/KOL JOYCOLLAB 同步链路**及免评协同角色表
|
||||
4. **TEL 拨打前准备五步 + 重试策略**
|
||||
5. **店铺紧急催评**独立子流程
|
||||
6. **三套并行客服状态**（工单/答应配合/风险）
|
||||
|
||||
并完成以下收口：
|
||||
|
||||
1. 将 IM 里残留的 `Amazon 账号 < / > 12 review` 全部改为 `真实人累计真实提交评价` 口径
|
||||
2. 明确 TEL 可继续服务，但不能绕开普通测评额度限制
|
||||
3. 补齐渠道路由、渠道去重、IM 流程标签和 EDM 行为画像对应的数据对象
|
||||
1030
wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md
Normal file
1030
wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环_第三步_数据流与中间对象设计_v3.md
Normal file
File diff suppressed because it is too large
Load Diff
577
wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md
Normal file
577
wishfulfilled-wiki/05_需求文档/20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md
Normal file
@@ -0,0 +1,577 @@
|
||||
# USER 评价业务闭环主流程与后续工作基线 v1.2
|
||||
|
||||
## 文件信息
|
||||
|
||||
- 文件名称：`20260517_USER评价业务闭环主流程与后续工作基线_v1.2.md`
|
||||
- 项目路径：`C:\XCODE\USER`
|
||||
- 当前版本：`v1.2`
|
||||
- 最近更新：`2026-05-17`
|
||||
- 前一版本：`20260517_USER评价业务闭环主流程与后续工作基线_v1.1.md`
|
||||
- 文件目的：在既有销售到评价闭环基线上，补入真实人识别、测评 / 免评额度、用户历史上下文、IM / EDM / TEL / 客服细化口径，作为新版第二步和后续数据流设计的统一依据。
|
||||
- 适用范围：当前阶段的 Amazon 业务闭环设计；如后续扩展到独立站或非 Amazon 评价体系，需要在本文件基础上另行增补。
|
||||
- 使用方式：下一次继续本项目时，先读取本文件，再读取 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`，不要再从旧版页面链路重新推导业务主干。
|
||||
|
||||
---
|
||||
|
||||
## 版本记录
|
||||
|
||||
| 版本 | 日期 | 说明 |
|
||||
| --- | --- | --- |
|
||||
| v1 | 2026-05-17 | 首次固化销售到评价完成的 USER 业务闭环主流程 |
|
||||
| v1.1 | 2026-05-17 | 将免评改为独立闭环；明确每次有效互动都要重新做身份与风险判断；明确当前版本不单列商家角色 |
|
||||
| v1.2 | 2026-05-17 | 补入用户历史与设备上下文、真实人级 `测评4 / 免评4 / 累计真实提交评价12` 规则、IM / EDM / TEL / 客服新增细节，并把第二步入口改为“共用能力 + 渠道专属流程” |
|
||||
|
||||
---
|
||||
|
||||
## 1. 已确认目标
|
||||
|
||||
1. 系统要支持 USER 部门工作，而不是只做一个回评记录工具。
|
||||
2. 业务流必须从“销售发生 / 需求形成”开始，而不是从“推送”开始。
|
||||
3. Amazon 运营既可以人工提需求，系统也可以因 Listing 健康或评价缺口自动触发需求。
|
||||
4. 用户运营是“需求评估 + 计划调度中心”，负责把需求转成可执行计划并跟踪结果。
|
||||
5. 计划类型必须正式保留：
|
||||
- 推新计划
|
||||
- 回评计划
|
||||
- 免评计划
|
||||
6. `免评计划` 不是边缘例外，而是需要正式保留的关键业务类型；其与 KOC / KOL、社媒带货、站外流量和 Amazon 权重有关。
|
||||
7. 用户提交评价与系统确认评价完成必须拆成两个节点：
|
||||
- 用户已真实提交评价
|
||||
- Amazon 已展示 / 系统已确认计入计划完成
|
||||
8. `真实人` 是后续额度、风险、历史和用户画像的核心对象，不应只围绕某个 JOYHUB ID、邮箱或 Amazon 账号看用户。
|
||||
9. 已确认的额度规则为：
|
||||
- 同一真实人每月最多参与 `4 次测评`
|
||||
- 同一真实人每月最多参与 `4 次免评`
|
||||
- 同一真实人累计最多计入 `12 个真实提交的评价`
|
||||
10. `12` 的计数时点是 `用户真实提交评价`，不是 `Amazon 展示评价`。
|
||||
11. 每次有效互动都要重新做身份、历史、额度和风险判断；主动推送后的回复也不例外。
|
||||
12. 客服接入时必须能快速看到用户历史、订单历史、设备上下文、既往风险和当前提醒，而不是只看到当前对话。
|
||||
13. 后续系统设计顺序已经确定：
|
||||
1. 先定业务流
|
||||
2. 再做点击操作模拟
|
||||
3. 最后根据业务需求整合现有数据，形成新的数据流和中间表需求
|
||||
|
||||
---
|
||||
|
||||
## 2. 当前边界与资料依据
|
||||
|
||||
### 2.1 当前纳入范围
|
||||
|
||||
- Amazon 业务
|
||||
- 销售到评价闭环
|
||||
- 推新、回评、免评
|
||||
- IM、EDM、APP、TEL、KOC / KOL
|
||||
- 售后接入
|
||||
- 客服执行与客服管理支撑
|
||||
- 黑名单与诈骗风险
|
||||
- ASIN 健康回流
|
||||
|
||||
### 2.2 当前不作为本版主流程展开的内容
|
||||
|
||||
- 独立站全链路
|
||||
- 完整 BI / 财务 / ROI 系统
|
||||
- 完整 KOC / KOL 结算系统
|
||||
- 所有历史后台页面逐页重构
|
||||
- 数据库最终物理设计
|
||||
|
||||
### 2.3 资料依据
|
||||
|
||||
本文件基于以下材料整理：
|
||||
|
||||
1. `C:\XCODE\USER\评价业务流闭环项目架构文档_v0.8.docx`
|
||||
2. `C:\XCODE\USER\docs\evaluation-business-architecture.md`
|
||||
3. `C:\XCODE\USER\docs\project-phase-one-plan.md`
|
||||
4. `C:\XCODE\USER\output\docs\20260503_USER后台ERP一期功能与页面设计_v4.md`
|
||||
5. `C:\XCODE\USER\output\docs\20260503_USER后台ERP自动推送与计划状态机_v4.md`
|
||||
6. `C:\XCODE\USER\output\docs\20260503_USER后台ERP一期页面原型说明_v4.md`
|
||||
7. `C:\XCODE\USER\output\docs\20260503_USER后台ERP_MVP角色首页UI规划_v1.md`
|
||||
8. `C:\tcode\飞书\飞书聊天记录库\cloud_files` 中当前主原型 HTML 与 `客服执行.html`
|
||||
9. `C:\Users\wu_zh\Downloads\20260407-法国诈骗问题（已扩散美国）.docx`
|
||||
10. `C:\Users\wu_zh\Desktop\表头.xlsx`
|
||||
11. `C:\Users\wu_zh\Downloads\IM 推送业务流.mm`
|
||||
12. `C:\Users\wu_zh\Downloads\后台回评工作流对接事项.docx`
|
||||
13. `C:\Users\wu_zh\Downloads\客服相关模块.docx`
|
||||
14. `C:\Users\wu_zh\Downloads\电话业务流程知识库.docx`
|
||||
15. 用户在当前对话中补充确认的业务规则
|
||||
|
||||
若历史资料与当前对话确认口径冲突，以当前对话中最新确认口径为准。
|
||||
|
||||
---
|
||||
|
||||
## 3. 角色与职责
|
||||
|
||||
| 角色 | 核心职责 |
|
||||
| --- | --- |
|
||||
| Amazon 运营 | 依据销售、ASIN、评价目标提出推新 / 回评 / 免评需求 |
|
||||
| Amazon 运营总监 | 审批相关计划，确认优先级与业务必要性 |
|
||||
| 品牌运营 | 负责品牌推广、站外节奏和与用户运营 / 内容运营协同 |
|
||||
| 内容运营 | 承接社区广告、APP 广告位、内容流量等侧向支持 |
|
||||
| 用户运营 | 评估需求、生成计划、分配资源、协调渠道、跟踪结果 |
|
||||
| 用户运营负责人 / 组长 | 复核计划、分配组员、处理重点风险和异常 |
|
||||
| 菲律宾客服负责人 | 关注工单压力、分配客服组、处理升级工单、查看绩效 |
|
||||
| 菲律宾客服组长 | 分配组内工单、复核升级、控制逾期和重点工单 |
|
||||
| 菲律宾客服组员 | 实际接待、电话沟通、记录、回复、回访、提交疑似诈骗 |
|
||||
| 风险 / 黑名单相关人员 | 接收诈骗疑似、复核、同步黑名单、维护风险口径 |
|
||||
| KOC / KOL 运营 | 承接站外带货、合作关系、内容和导购协同 |
|
||||
|
||||
当前版本不单列“商家 / 商家运营”角色。这里的“商家”如出现，均按 Amazon 卖家侧语义理解，由 Amazon 运营承接；品牌商当前也只纳入 Amazon 内评价相关协同。
|
||||
|
||||
---
|
||||
|
||||
## 4. 总体业务结构
|
||||
|
||||
### 4.1 主流程
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["销售发生 / ASIN销售数据形成"] --> B["需求触发"]
|
||||
B --> B1["Amazon运营人工提需求"]
|
||||
B --> B2["系统按评价缺口或Listing健康自动触发"]
|
||||
B1 --> C["用户运营评估需求"]
|
||||
B2 --> C
|
||||
C --> D["形成业务计划"]
|
||||
D --> D1["推新计划"]
|
||||
D --> D2["回评计划"]
|
||||
D --> D3["免评计划"]
|
||||
D1 --> E["规则 / 风险 / 额度复核"]
|
||||
D2 --> E
|
||||
D3 --> E
|
||||
E --> F["审批通过"]
|
||||
F --> G["执行拆解"]
|
||||
G --> H1["评价型执行闭环"]
|
||||
G --> H2["免评型执行闭环"]
|
||||
H1 --> I1["IM / EDM / APP / TEL / 客服协同"]
|
||||
I1 --> J1["用户被触达或主动进入"]
|
||||
J1 --> K1["每次有效互动均重做身份 / 历史 / 额度 / 风险核验"]
|
||||
K1 --> L1["服务 / 售后 / 跟进"]
|
||||
L1 --> M1["用户真实提交评价"]
|
||||
M1 --> N1["计入真实人累计评价额度"]
|
||||
N1 --> O1["Amazon是否展示 / 系统是否确认完成"]
|
||||
O1 --> P["结果回流"]
|
||||
H2 --> I2["KOC / KOL为核心，IM / EDM / APP等协同参与"]
|
||||
I2 --> J2["内容发布 / 站外引流 / 带货执行"]
|
||||
J2 --> K2["跟踪点击、Code、订单、转化与权重结果"]
|
||||
K2 --> P
|
||||
P --> Q["更新ASIN健康、计划完成度、用户画像、流量结果、风险记录"]
|
||||
Q --> C
|
||||
```
|
||||
|
||||
### 4.2 五个业务层
|
||||
|
||||
| 业务层 | 说明 |
|
||||
| --- | --- |
|
||||
| 经营层 | 销售、ASIN、需求、品牌 / 内容 / KOC-KOL 侧影响 |
|
||||
| 计划层 | 推新、回评、免评、审批、规则、额度、风险 |
|
||||
| 执行层 | IM、EDM、APP、TEL、客服工单、KOC / KOL 协作 |
|
||||
| 服务与身份层 | 用户接入、真实人归并、订单核验、用户上下文、售后处理 |
|
||||
| 结果与风险层 | 用户真实提交评价、Amazon 展示确认、免评结果、黑名单、诈骗、结果回流 |
|
||||
|
||||
---
|
||||
|
||||
## 5. 主流程详细说明
|
||||
|
||||
| 阶段 | 业务说明 | 必须检查 | 主要输出 |
|
||||
| --- | --- | --- | --- |
|
||||
| 1. 销售与需求形成 | 销售发生后，Amazon 运营根据目标或系统根据健康度触发需求 | 销售、ASIN、评分、评价缺口、历史计划 | 新需求 |
|
||||
| 2. 用户运营评估 | 判断需求是否成立、是否可做、优先级如何 | ASIN 健康、目标数量、历史完成、当前资源、风险 | 已确认需求 / 待补充 / 驳回 |
|
||||
| 3. 计划生成 | 将需求转为推新、回评或免评计划 | 用户池、渠道容量、目标、周期 | 计划草案 |
|
||||
| 4. 计划复核与审批 | 对计划做规则、额度和风险复核，再进入审批 | 黑名单、频控、渠道风险、真实人额度、审批权限 | 已批准计划 |
|
||||
| 5. 执行拆解 | 把计划拆成渠道任务和人工任务 | 可触达用户、素材、客服负载、KOC / KOL协作 | 推送任务 / TEL任务 / 客服工单 / 协作任务 |
|
||||
| 6A. 评价型执行 | 推新、回评进入用户触达、服务与评价链路 | 真实人、订单、历史、额度、风险、售后情况 | 当前处理路径 |
|
||||
| 6B. 免评型执行 | 免评以 KOC / KOL 与站外流量为核心，同时可由 IM / EDM / APP 等协同参与 | 合作对象、内容、Code、渠道、素材、节奏、免评额度 | 内容任务 / 引流任务 / 带货任务 |
|
||||
| 7A. 用户真实提交评价 | 记录用户是否已经实际提交评价 | 用户反馈、提交证据、对应计划、真实人累计额度 | 已提交评价事实 |
|
||||
| 7B. 免评结果跟踪 | 记录免评计划的执行结果 | 内容发布、点击、Code、订单、转化、销量、权重变化 | 免评执行结果 |
|
||||
| 8. 评价确认 | 区分用户提交与 Amazon 展示结果 | Amazon 是否展示、是否能核验、是否属本计划 | 计入完成 / 待确认 |
|
||||
| 9. 结果回流 | 把评价结果与免评结果重新反馈给经营与计划层 | 计划完成、ASIN 健康、流量结果、风险变化、用户标签 | 新一轮决策输入 |
|
||||
|
||||
---
|
||||
|
||||
## 6. 关键业务支线
|
||||
|
||||
### 6.1 主动触达支线
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["计划通过"] --> B["筛选可触达用户池"]
|
||||
B --> C["真实人识别 + 人群画像 + 额度校验"]
|
||||
C --> D["渠道分配"]
|
||||
D --> D1["IM"]
|
||||
D --> D2["EDM"]
|
||||
D --> D3["APP"]
|
||||
D --> D4["TEL"]
|
||||
D1 --> E["用户回应"]
|
||||
D2 --> E
|
||||
D3 --> E
|
||||
D4 --> E
|
||||
E --> F["每次回应都重做身份 / 历史 / 额度 / 风险核验"]
|
||||
F --> G["订单核验"]
|
||||
G --> H["服务 / 跟进"]
|
||||
H --> I["用户真实提交评价"]
|
||||
```
|
||||
|
||||
#### 关键规则
|
||||
|
||||
1. IM、EDM、APP 可自动化；TEL 属于人工执行渠道。
|
||||
2. `IM` 需要识别用户分层、绑定玩具、设备、测评 / 免评额度和标签流转。
|
||||
3. `EDM` 需要识别最近打开、最近回复、点击评论链接但未回复、月度收信次数、最近 3 / 5 次 0 打开、邮箱类型、退订和硬退信。
|
||||
4. 计划生成前必须先检查：
|
||||
- 用户是否可触达
|
||||
- 是否命中风险
|
||||
- 是否超频
|
||||
- 是否符合站点 / 国家 / 产品目标
|
||||
- 是否接近或达到真实人额度上限
|
||||
5. 用户回应后，不能沿用上一次判断结果，必须重新检查当前身份、订单、设备、地址、历史、额度与风险状态。
|
||||
|
||||
### 6.2 免评执行支线
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["免评计划通过"] --> B["拆解执行方案"]
|
||||
B --> C1["KOC / KOL协作"]
|
||||
B --> C2["IM / EDM / APP辅助触达"]
|
||||
B --> C3["内容 / 运营协同"]
|
||||
C1 --> D["内容发布 / Code使用 / 站外引流"]
|
||||
C2 --> D
|
||||
C3 --> D
|
||||
D --> E["跟踪点击、跳转、Code、订单、转化、销量与权重变化"]
|
||||
E --> F["结果回流到ASIN健康与后续计划"]
|
||||
```
|
||||
|
||||
#### 关键规则1
|
||||
|
||||
1. 免评计划不是评价型计划的弱化版本，而是以站外流量、带货、销量和权重结果为终点的独立闭环。
|
||||
2. KOC / KOL 是免评计划的核心执行通道，但 IM、EDM、APP 等也可以参与协同。
|
||||
3. 同一真实人每月最多参与 `4 次免评`；免评额度也要做预警、预占和拦截。
|
||||
4. 免评计划不以“用户提交评价”作为完成条件，必须另行跟踪内容发布、Code、点击、订单、转化、销量和权重变化。
|
||||
5. 如果免评执行过程中发生用户互动、售后或返款等行为，仍须进入统一的身份与风险判断机制。
|
||||
|
||||
### 6.3 被动售后与 TEL 支线
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["用户主动联系 / 电话呼入"] --> B["接入即预查"]
|
||||
B --> C["识别来源、身份、订单、历史、风险"]
|
||||
C --> D{"是否有售后问题"}
|
||||
D -->|有| E["问题分类与解决方案"]
|
||||
E --> F["确认是否解决 / 是否满意"]
|
||||
F --> G["满意后进入回评 / 测评邀请"]
|
||||
D -->|无| H["确认无其他需求"]
|
||||
H --> I["可进入测评邀请"]
|
||||
G --> J["记录电话 / 工单 / 后续跟进"]
|
||||
I --> J
|
||||
```
|
||||
|
||||
#### 关键规则2
|
||||
|
||||
1. TEL 当前至少包含两类入口：
|
||||
- 计划生成后的人工外呼任务
|
||||
- 用户从 Amazon 页面或说明书主动呼入
|
||||
2. 有售后问题时，必须先解决售后，再谈评价或测评邀请。
|
||||
3. 电话中需要尽量确认：
|
||||
- 购买平台
|
||||
- 订单号
|
||||
- 产品型号 / 款式 / 颜色
|
||||
- 购买时间
|
||||
- 问题类型
|
||||
- 是否有图片、视频或其他凭证
|
||||
4. 每通电话结束后，至少要记录：
|
||||
- 来电时间
|
||||
- 来源
|
||||
- 联系方式
|
||||
- 订单号
|
||||
- 问题类型和描述
|
||||
- 处理方案
|
||||
- 是否已解决
|
||||
- 是否需要后续跟进
|
||||
- 是否邀请测评 / 回评
|
||||
- 用户是否接受
|
||||
5. 当前电话业务的核心是：
|
||||
- 自然单回评转化
|
||||
- 充分利用电话用户的测评资源
|
||||
|
||||
### 6.4 风险 / 诈骗拦截支线
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["新订单同步 / 主动触达回应 / 用户接入 / 退款申请 / 再次跟进"] --> B["重新做风险识别"]
|
||||
B --> C{"是否命中强关联"}
|
||||
C -->|是| D["直接进入高风险或黑名单链路"]
|
||||
C -->|否| E{"是否命中弱关联"}
|
||||
E -->|是| F["进入高风险观察 + 人工复核"]
|
||||
E -->|否| G["继续正常流程"]
|
||||
D --> H["拦截自动退款、继续推送、自动放行"]
|
||||
F --> H
|
||||
H --> I["提醒客服 / 用户运营 / 审核人员"]
|
||||
```
|
||||
|
||||
#### 已确认风险口径
|
||||
|
||||
| 风险类型 | 关联项 | 处理原则 |
|
||||
| --- | --- | --- |
|
||||
| 强关联 | 邮箱、设备号、电话、收件人姓名+地址、订单号、聊天记录、Profile ID、收款信息 | 一旦命中，可直接进入高风险或黑名单链路 |
|
||||
| 弱关联 | IP 单独命中、姓名单独命中、同址异名 | 进入高风险观察，不直接认定诈骗 |
|
||||
|
||||
#### 已确认业务问题
|
||||
|
||||
1. 当前真实事故中存在“双重退款”风险：
|
||||
- APP / OA 已退款
|
||||
- 用户又向 Amazon 申请退款
|
||||
2. 需要把 Amazon 退款与 OA 返款自动比对。
|
||||
3. 高风险用户一旦标记，支付 / 返款需要人工复核。
|
||||
4. 客服、审核、退款等环节必须都能看到风险提醒。
|
||||
5. 非 APP 用户如果直接走邮件退款，因缺少设备、注册邮箱等维度，风险识别能力明显下降。
|
||||
6. 风险判断不是一次性的接入动作，而是每次有效互动都要重新执行。
|
||||
|
||||
### 6.5 客服工单与客服管理支线
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["用户消息进入 / 推送转人工 / 售后触发 / 风险触发"] --> B["生成工单"]
|
||||
B --> C["按班次、在线状态、当前负载自动分配"]
|
||||
C --> D["客服处理"]
|
||||
D --> E{"处理结果"}
|
||||
E -->|等待用户| F["等待用户回复"]
|
||||
E -->|等待内部| G["等待内部协同"]
|
||||
E -->|答应配合| H["生成后续跟进"]
|
||||
E -->|疑似诈骗| I["转风险链路"]
|
||||
E -->|已解决| J["关闭工单"]
|
||||
D --> K["回复效率 / 转化 / 目标完成统计"]
|
||||
```
|
||||
|
||||
#### 工单与管理事实
|
||||
|
||||
1. 客服相关模块不只包括工单，还包括：
|
||||
- 出勤管理
|
||||
- 排班管理
|
||||
- 回复效率统计
|
||||
- 转化统计
|
||||
- 目标管理
|
||||
2. `排班` 与 `在线状态` 会直接影响自动分配。
|
||||
3. `工单状态`、`答应配合状态`、`风险状态` 必须拆开存。
|
||||
4. 客服转化要区分：
|
||||
- RSO 回评
|
||||
- RDO 测评
|
||||
5. 回复效率至少要统计：
|
||||
- 回复用户数
|
||||
- 处理工单数
|
||||
- 发送消息数
|
||||
- 平均 / 中位数 / 最大 / 最小首次回复时长
|
||||
6. 转化统计至少要看：
|
||||
- 登记订单数
|
||||
- 获取评价数
|
||||
- 评价完成率
|
||||
7. 主管需要看到出勤、排班、绩效、目标完成和工单分配，而不是只看单个会话。
|
||||
|
||||
---
|
||||
|
||||
## 7. 真实人识别、用户上下文与额度规则
|
||||
|
||||
### 7.1 真实人识别原则
|
||||
|
||||
1. 当前系统不应只围绕 `JOYHUB ID` 看用户，而应同时围绕：
|
||||
- 账号
|
||||
- 订单
|
||||
- 实际收件人
|
||||
- 设备
|
||||
- 联系方式
|
||||
- 风险关系
|
||||
2. 如果用户在 JOYHUB 内提交订单，则订单可直接关联到当前 JOYHUB ID。
|
||||
3. 如果用户通过邮件联系：
|
||||
- 先问是否有 JOYHUB ID
|
||||
- 再用注册邮箱与 JOYHUB ID 做关系查询
|
||||
4. 如果用户通过电话联系：
|
||||
- 先确认是否注册 APP
|
||||
- 结合电话、订单、收件人、地址、设备、邮箱继续识别
|
||||
5. 非 APP 用户如需继续参与相关流程，应优先引导注册 APP，再继续后续动作。
|
||||
|
||||
### 7.2 实际收件人判定
|
||||
|
||||
| 情况 | 处理原则 |
|
||||
| --- | --- |
|
||||
| 标准化后姓名 + 地址完全一致 | 直接认为是同一实际收件人 |
|
||||
| 地址一致但姓名不同 | 只认为存在家庭 / 关联风险，不直接判定同一人 |
|
||||
| 邮箱不同、JOYHUB ID 不同 | 不能单独否定“同一实际人” |
|
||||
| 订单号命中历史异常 | 应立即拉出历史上下文和风险记录 |
|
||||
|
||||
### 7.3 用户上下文卡
|
||||
|
||||
客服和用户运营在必要节点应能看到：
|
||||
|
||||
| 字段组 | 例子 |
|
||||
| --- | --- |
|
||||
| 当前身份 | JOYHUB ID、邮箱、电话、真实人 ID、当前订单 |
|
||||
| 历史交易 | 历史订单、最近购买、退款 / 返款、目标 ASIN 购买情况 |
|
||||
| 历史服务 | 历史工单、聊天、电话、承诺、提醒、关闭原因 |
|
||||
| 历史风险 | 黑名单、关联账号、疑似诈骗、双重退款、异常订单 |
|
||||
| 当前设备 | 设备号摘要、设备型号 / 类型、系统版本、APP 版本、最近设备变化 |
|
||||
| 触达历史 | IM / EDM / APP / TEL 最近触达、回复、退订、投诉 |
|
||||
|
||||
### 7.4 额度规则
|
||||
|
||||
| 规则 | 统计对象 | 计数口径 |
|
||||
| --- | --- | --- |
|
||||
| 月度测评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |
|
||||
| 月度免评最多 4 次 | 真实人 | 已完成 + 进行中 + 已预占 |
|
||||
| 累计真实提交评价最多 12 个 | 真实人 | 用户真实提交评价后立即计数 |
|
||||
|
||||
### 7.5 额度控制原则
|
||||
|
||||
1. 额度判断必须放在 `真实人识别` 之后，而不是只看单一账号。
|
||||
2. 系统不能等到真正超限才提示，必须在接近上限时提前预警。
|
||||
3. 一旦 `已用 + 进行中 + 已预占 + 本次拟发送` 会导致超限，就不能进入自动推送。
|
||||
4. `Amazon 未展示` 不影响 12 次累计额度，因为口径已经确认按 `真实提交` 计数。
|
||||
|
||||
---
|
||||
|
||||
## 8. 渠道专属补充事实
|
||||
|
||||
### 8.1 IM
|
||||
|
||||
- 用户需要分层：未参与过、参与过、长期测评人。
|
||||
- 触发条件包括注册 App、绑定玩具、识别绑定产品。
|
||||
- 需要校验设备 ID、黑名单、绑定产品、额度与标签。
|
||||
- 用户提交订单号、返款账号、评论截图 / 链接后，要继续做订单核验和资格登记。
|
||||
|
||||
### 8.2 EDM
|
||||
|
||||
- EDM 不是简单“发邮件”，而是独立的筛选与节奏引擎。
|
||||
- 需要支持：
|
||||
- 最近打开时间
|
||||
- 最近回复时间
|
||||
- 打开次数
|
||||
- 最近 3 / 5 次推送 0 打开
|
||||
- 点击评论链接但未回复时长
|
||||
- 单月收信次数
|
||||
- 各邮件类型发送次数
|
||||
- 邮箱后缀标签
|
||||
- 国家站点
|
||||
- 退订、硬退信、风险用户、黑名单、OA 无资格用户排除
|
||||
|
||||
### 8.3 APP
|
||||
|
||||
- APP 侧至少要纳入：
|
||||
- 注册邮箱
|
||||
- 设备号
|
||||
- 设备型号 / 类型
|
||||
- APP 版本
|
||||
- 系统版本
|
||||
- 用户行为数据
|
||||
- 绑定玩具
|
||||
- 活跃与点击行为
|
||||
- APP 不只是触达渠道，也是身份识别、设备变化和行为画像的重要来源。
|
||||
|
||||
### 8.4 TEL
|
||||
|
||||
- TEL 同时承担主动外呼和被动来电。
|
||||
- 其价值不只是“打电话”，而是：
|
||||
- 解决售后
|
||||
- 捕捉自然单回评机会
|
||||
- 充分利用电话用户的测评资源
|
||||
|
||||
---
|
||||
|
||||
## 9. 评价结果规则
|
||||
|
||||
### 9.1 必须拆开的两个节点
|
||||
|
||||
```mermaid
|
||||
flowchart LR
|
||||
A["用户已真实提交评价"] --> B["计入真实人累计评价额度"]
|
||||
B --> C{"Amazon是否展示 / 是否可核验"}
|
||||
C -->|展示或可核验| D["计入计划完成"]
|
||||
C -->|未展示 / 暂不可核验| E["保留用户已提交事实"]
|
||||
E --> F["进入待确认 / 异常观察"]
|
||||
D --> G["更新ASIN健康与计划完成度"]
|
||||
```
|
||||
|
||||
### 9.2 原因
|
||||
|
||||
1. 用户可能确实已经提交评价。
|
||||
2. Amazon 可能因为其他原因不展示该评价。
|
||||
3. `额度计数` 与 `计划完成确认` 不是同一个业务事实。
|
||||
4. 如果系统只保留一个“评价完成”状态，会把平台展示问题错误归因给执行人员或用户。
|
||||
|
||||
---
|
||||
|
||||
## 10. 贯穿全程的数据检查点
|
||||
|
||||
| 检查点 | 发生时机 | 核心检查 |
|
||||
| --- | --- | --- |
|
||||
| 经营检查 | 需求形成前 | 销售、ASIN、评分、评价缺口、历史计划 |
|
||||
| 计划检查 | 生成计划前 | 人群、渠道、容量、规则、黑名单 |
|
||||
| 画像检查 | 生成人群时 | 国家、站点、性别、年龄、绑定玩具、产品关系、活跃、历史行为 |
|
||||
| 额度检查 | 生成人群、发送前、继续推进前 | 测评 4、免评 4、累计真实提交 12、进行中与已预占 |
|
||||
| 身份检查 | 首次接入与每次有效互动时 | JOYHUB、邮箱、电话、设备、订单、地址、历史记录 |
|
||||
| 互动复检 | 主动触达回应、再次联系、补充订单号、客服回访时 | 关键属性是否变化，是否出现新订单、新地址、新设备、新返款记录 |
|
||||
| 风险检查 | 每次有效互动、退款、返款、继续推送前 | 双重退款、强弱关联、黑名单、历史异常 |
|
||||
| 结果检查 | 评价提交与确认后 | 首评 / 回评、是否属本计划、是否展示、ASIN 健康变化 |
|
||||
|
||||
---
|
||||
|
||||
## 11. 第二步的新入口
|
||||
|
||||
第二步不再按旧版页面链路推进，而改成：
|
||||
|
||||
### 11.1 共用能力图
|
||||
|
||||
1. 真实人识别与用户上下文卡
|
||||
2. 人群生成与画像拆解
|
||||
3. 额度与频控控制
|
||||
4. 每次有效互动复检
|
||||
5. 风险与黑名单
|
||||
|
||||
### 11.2 渠道 / 模块专属流程图
|
||||
|
||||
1. IM
|
||||
2. EDM
|
||||
3. APP
|
||||
4. TEL
|
||||
5. 客服工单
|
||||
6. 客服管理支撑
|
||||
7. 评价完成
|
||||
8. 免评执行
|
||||
|
||||
### 11.3 每张图都必须回答
|
||||
|
||||
- 进入条件是什么
|
||||
- 要先查什么
|
||||
- 如何判断
|
||||
- 写入什么
|
||||
- 状态怎么变
|
||||
- 何时提醒
|
||||
- 何时拦截
|
||||
- 何时转人工
|
||||
|
||||
---
|
||||
|
||||
## 12. 下一次继续工作时的直接提示
|
||||
|
||||
1. 先读取本文件。
|
||||
2. 不要重新讨论“是否从销售开始”“是否保留免评”“评价提交与展示是否拆开”，这些已确认。
|
||||
3. 额度口径按当前版本执行：
|
||||
- 测评每月最多 4
|
||||
- 免评每月最多 4
|
||||
- 同一真实人累计真实提交评价最多 12
|
||||
4. 不要再把风险判断理解成“首次接入才做一次”；每次有效互动都需要重做判断。
|
||||
5. 不要再把第二步按页面链路拆；直接进入 `20260517_USER评价业务闭环_共用能力图与渠道专属流程_v2.2.md`。
|
||||
6. 旧版 `v1` / `v1.1` 保留为历史版本，不再作为后续主口径。
|
||||
|
||||
---
|
||||
|
||||
## 13. 本版结论
|
||||
|
||||
USER 部门未来系统的核心，不是单独记录“谁评价了”，而是把以下内容放进同一条可追踪闭环中：
|
||||
|
||||
1. 销售与需求
|
||||
2. 计划生成与审批
|
||||
3. 真实人识别与用户上下文
|
||||
4. 测评 / 免评 / 累计评价额度控制
|
||||
5. IM / EDM / APP / TEL / 客服协同
|
||||
6. 用户身份与订单核验
|
||||
7. 售后服务与评价引导
|
||||
8. 免评执行与站外流量结果
|
||||
9. 用户真实提交评价
|
||||
10. Amazon 展示与系统确认
|
||||
11. ASIN 健康回流
|
||||
12. 风险与黑名单拦截
|
||||
|
||||
只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。
|
||||
78
wishfulfilled-wiki/05_需求文档/README.md
Normal file
78
wishfulfilled-wiki/05_需求文档/README.md
Normal file
@@ -0,0 +1,78 @@
|
||||
---
|
||||
type: requirement_inbox
|
||||
tags: [需求文档, 需求收集, 知识库更新, Agent]
|
||||
aliases: [需求文档目录, 需求收集目录, 需求入口]
|
||||
source: manual
|
||||
status: active
|
||||
owner: 产品经理 / 业务主管
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 需求文档
|
||||
|
||||
本目录用于集中存放后续持续补充的业务需求文档、业务规则文档、流程补充文档和需求变更文档。
|
||||
|
||||
## 使用方式
|
||||
|
||||
1. 所有新增需求文档优先放入本目录。
|
||||
2. 建议使用 `03_规范与模板/需求说明模板.md` 或 `03_规范与模板/业务规则与需求补充模板.md` 创建文档。
|
||||
3. 文档确认有效后，同步更新业务流程索引和 Agent 检索索引。
|
||||
4. Agent 回答具体业务需求时，应优先检索本目录。
|
||||
|
||||
## 推荐命名
|
||||
|
||||
```text
|
||||
业务域_需求或规则名称_YYYYMMDD.md
|
||||
```
|
||||
|
||||
示例：
|
||||
|
||||
```text
|
||||
采购_供应商准入规则_20260526.md
|
||||
库存_出入库审批规则_20260526.md
|
||||
销售_客户授信额度需求_20260526.md
|
||||
```
|
||||
|
||||
## 文档状态
|
||||
|
||||
每个需求文档建议在 Frontmatter 中维护 `status`：
|
||||
|
||||
| 状态 | 含义 |
|
||||
|---|---|
|
||||
| draft | 草稿，尚未确认 |
|
||||
| reviewing | 评审中 |
|
||||
| active | 已确认，可作为 Agent 回答依据 |
|
||||
| deprecated | 已废弃，仅归档参考 |
|
||||
|
||||
## 必填内容
|
||||
|
||||
每个需求文档至少包含：
|
||||
|
||||
- 需求背景
|
||||
- 适用范围
|
||||
- 涉及角色
|
||||
- 业务规则
|
||||
- 业务流程
|
||||
- 异常处理
|
||||
- 权限要求
|
||||
- 验收口径
|
||||
- Agent 检索字段
|
||||
- 变更记录
|
||||
|
||||
## 索引维护
|
||||
|
||||
新增或修改需求文档后，需要同步更新：
|
||||
|
||||
- `05_需求文档/需求文档索引.md`
|
||||
- `01_业务流程/业务规则索引.md`
|
||||
- `01_业务流程/业务对象字典.md`
|
||||
- `04_Agent检索/关键词索引.md`
|
||||
- `04_Agent检索/同义词表.md`
|
||||
- `04_Agent检索/来源文件索引.md`
|
||||
|
||||
## 验证流程
|
||||
|
||||
新增需求文档后，按 `04_Agent检索/知识库持续更新与验证流程.md` 执行验证，并将验证结果记录到：
|
||||
|
||||
- `05_需求文档/需求文档索引.md`
|
||||
- `01_业务流程/业务补充验证记录.md`
|
||||
1280
wishfulfilled-wiki/05_需求文档/evaluation-business-architecture.md
Normal file
1280
wishfulfilled-wiki/05_需求文档/evaluation-business-architecture.md
Normal file
File diff suppressed because it is too large
Load Diff
3878
wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10(1).html
Normal file
3878
wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10(1).html
Normal file
File diff suppressed because it is too large
Load Diff
7623
wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10.html
Normal file
7623
wishfulfilled-wiki/05_需求文档/user_erp_mvp_admin_prototype_v10.html
Normal file
File diff suppressed because it is too large
Load Diff
67
wishfulfilled-wiki/05_需求文档/客服执行.html
Normal file
67
wishfulfilled-wiki/05_需求文档/客服执行.html
Normal file
File diff suppressed because one or more lines are too long
738
wishfulfilled-wiki/05_需求文档/用户运营系统-单文件.html
Normal file
738
wishfulfilled-wiki/05_需求文档/用户运营系统-单文件.html
Normal file
File diff suppressed because one or more lines are too long
39
wishfulfilled-wiki/05_需求文档/需求文档索引.md
Normal file
39
wishfulfilled-wiki/05_需求文档/需求文档索引.md
Normal file
@@ -0,0 +1,39 @@
|
||||
---
|
||||
type: requirement_index
|
||||
tags: [需求文档, 索引, Agent检索]
|
||||
aliases: [需求索引, 需求文档清单, 需求清单]
|
||||
source: manual
|
||||
status: active
|
||||
owner: 产品经理 / 业务主管
|
||||
updated: 2026-05
|
||||
---
|
||||
|
||||
# 需求文档索引
|
||||
|
||||
本文件记录 `05_需求文档/` 下所有正式需求文档，供人工维护和 Agent 检索定位。
|
||||
|
||||
## 需求文档清单
|
||||
|
||||
| 编号 | 业务域 | 需求/规则名称 | 文件 | 状态 | 负责人 | 更新时间 | 验证状态 |
|
||||
|---|---|---|---|---|---|---|---|
|
||||
| | | | | | | | 未验证 |
|
||||
|
||||
## Agent 检索关键词
|
||||
|
||||
| 关键词/问法 | 标准术语 | 命中文件 | 答案要点 |
|
||||
|---|---|---|---|
|
||||
| | | | |
|
||||
|
||||
## 维护规则
|
||||
|
||||
1. 新增需求文档后，必须在“需求文档清单”新增一行。
|
||||
2. 每个需求文档至少维护 3 个可检索问法。
|
||||
3. `状态=active` 的文档可作为 Agent 回答依据。
|
||||
4. `status=draft/reviewing` 的文档只能作为草稿参考，Agent 回答时需说明尚未确认。
|
||||
5. `status=deprecated` 的文档不得作为当前规则依据，只能说明历史背景。
|
||||
|
||||
## 验证记录摘要
|
||||
|
||||
| 日期 | 文件 | 验证问题数 | 通过数 | 失败数 | 结论 |
|
||||
|---|---|---:|---:|---:|---|
|
||||
| | | | | | |
|
||||
Reference in New Issue
Block a user