578 lines
24 KiB
Markdown
578 lines
24 KiB
Markdown
# 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. 风险与黑名单拦截
|
||
|
||
只有这条闭环建立起来，后续的点击设计、页面设计和数据设计才不会彼此脱节。
|